Description of problem:
Users want to make a change to an existing content view. It could be to add a couple puppet modules or update some packages or in the case of composite views, it could be to change a component version. They want to then publish and re-promote that new version directly to the environment the published content view was in, bypassing current restrictions on lifecycle environment promotions.
There are two pieces that we need to solve: first allowing users to make a change to published view. Secondly, giving users the ability to bypass current restrictions on having to promote through environments.
Example use case:
I have a composite view called "composite" which is composed of two views (os and puppet). In my environments, I have:
Dev - composite v2 (os v2 and puppet v1)
Test - composite v2 (os v2 and puppet v1)
Prod - composite v1 (os v1 and puppet v1)
I want to publish and promote a new component puppet v2 to all environments without changing the existing version of os.
For problem 1, we could allow users to make revisions or branch the existing views. So in our example use case the user would publish a composite v3 for Dev and Test, and perhaps a composite v2.1 or v3.1 which would contain os v1 and puppet v2 for Prod. The user would then have to promote the view somehow to Prod (see below).
For problem 2, there are a few solutions:
1. One would be to allow promotion of the new composite revision directly to Prod.
2. Another would be to allow multiple environments to point to Prod so essentially the user could create a "Patch" environment which they could promote through to Prod.
3. Lastly, we could allow multiple versions per environment so the users would use the same environment path but the environments Dev and Test would contain version 3 and 2.1.
Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.
The option 2 seems reasonable to me. Also, it would be nice to not require the version to be promoted to library before going to the next environment: it would be useful for todays world, where there are multiple paths from the library available and I can choose different version to be promote to the next env without need to publish it to library.
Another possible solution from Erik mentions being able to promote components of a composite individually.
By default, promote should take whatever is in the current environment
and push it to the right (eg: test -> prod).
However, maybe we need to offer the ability to override that promotion
and allow someone to select the underlying versions of the views in the
This is similar to what I think Eric said about the API letting you
place an arbitrary version of a CV into any arbitrary environment.
By being able to selectively create a combination of arbitrary
underlying components in a composite and place it into an environment,
you could easily create a "hotfix" view (or update an existing view with
the hotfix) and then modify existing environments to use the specific
version of the underlying component view.
Incremental errata, which were delivered with Satellite 6.1, addresses this bug. Closing this out.