ISS "I want everything!" user stories

@beav and I tried to gather as many user stories as we could to cover ISS (a spacewalk/Sat-5 concept of Inter-Satellite Sync). These were pulled from both the work done so far as well as trello cards, katello wiki, and meetings. Please comment on individual user stories or add additional ones. Comments and questions inline with each story (or trim replies to a single story) would be great. The outcome of this effort, I think, will be a trello board with tasks that are prioritized with story points for effort.

"I want everything!" User Stories
Terminology

  • upstream - the source Sat-6 from which the export happens
  • downstream - the destination Sat-6 which imports
  • ISS - describes mirroring between upstream and downstream

As a user, I want to import from disk or directly from upstream.

  • As a user, I want to link a downstream content view to an upstream content view.
  • As a user, I want to link a downstream product to an upstream product.
    As a user, I want to schedule export on the upstream.
  • Set any number of schedules on anything ISSable
  • Multiple downstreams
    As a user, I want to schedule the import from the downstream.
  • Set any number of schedules on anything ISSable
  • Multiple upstreams
    As a user, I want to set the CDN to an upstream location.
  • I'd like file:/// urls to be supported here, but its not a blocking requirement
    As a user, I want to set the upstream location on a per content view basis.
  • I'm not sure how this concept works, in relation to lines 20 and 22. Which is the "canonical" copy of the CDN location, if the CV and repo/product locations don't agree?
    As a user, i want to set the upstream location on a per repository basis.
  • Is this wise or necessary? Perhaps the lowest granularity should be per product? Would I ever want two repos in a Red Hat product to come from different upstream (eg. a 6.1 repo from upstream A and a 7Server repo from upstream B)?
    As a user, I want to set the upstream location on a per product basis.
    As a user, I want to ISS incremental content
  • not sure if we need/want to track the date of the last export. This likely will be tricky if there are multiple downstreams, or if we dont want to "leak" patchset info about the higher-security Sat into the lower-security one.
    As a user, I want to ISS a repository.
  • As a user, I want to ISS repository sync plans.
    As a user, I want to ISS a content view definition.
  • As a user, I want the imported content view to have the same version as it was exported as.
  • As a user, I want to ISS content view filters.
  • As a user, I want to ISS composite content views.
    As a user, I want to lock a content view so that downstream user cannot modify it.
  • Would still need to allow an ISS to happen, though.
    As a user, I want all content view details versioned (filters, repositories, puppet, docker).
  • If I promote version 2, making it now the latest version, it should be exactly defined as it was then.
    As a user, I want to ISS a host group.
  • As a user, I want to ISS all references for a host group (puppet classes, etc.).
    As a user, I want to ISS RPMs content.
  • packages, errata, kickstart, ISOs
    As a user, I want to ISS docker content.
    As a user, I want to ISS puppet content.
    As a user, I want to ISS ostree content
    As a security person, I would like to be able to hand-inspect an export's data before importing it.
    As a security person, I want RBAC on export and import.
    As a user, I want to ISS a content view from Satellite A to B, and also ISS a content view from B to A (think of A containing the gold copy of a RHEL CSB, but B containing the gold copy of a particular application to deploy)
    As a user, I want to ISS a CV from one upstream to multiple downstreams
    As a user, I want to ISS a CV from one upstream to multiple downstreams, and downstreams kick off the ISS (i.e., upstream on a lower-security network and is not aware of the existance of downstreams)
    As a user, I want to export a CV into one or more ISO files of a size I choose.
    As a user, I want an audit history of exports and imports.
  • How detailed?
    As a user, I want Red Hat content imports to be limited by subscription.
  • How hard do we try to prevent a Red Hat export of a product from becoming a custom product downstream?
    As a user, I want a meta file with the content exports that describe the other resources necessary to import.
  • For example, a repo for a custom product should have a products.csv to define/update the product definition the repos live in.
··· -- @thomasmckay


“The leader must aim high, see big, judge widely, thus setting himself apart form the ordinary people who debate in narrow confines.” ~ Charles De Gaulle

“Leadership is about making others better as a result of your presence and making sure that impact lasts in your absence.” ~ Harvard Business School


@thomasmckay


“The leader must aim high, see big, judge widely, thus setting himself apart form the ordinary people who debate in narrow confines.” ~ Charles De Gaulle

“Leadership is about making others better as a result of your presence and making sure that impact lasts in your absence.” ~ Harvard Business School