Bug 1126819 - [RFE] Allow users to make a change to a published content view
Summary: [RFE] Allow users to make a change to a published content view
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Content Views
Version: 6.0.4
Hardware: Unspecified
OS: Unspecified
medium vote
Target Milestone: Unspecified
Assignee: Katello Bug Bin
QA Contact: Katello QA List
Depends On:
TreeView+ depends on / blocked
Reported: 2014-08-05 11:25 UTC by David Davis
Modified: 2015-12-03 17:00 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2015-10-13 12:49:15 UTC

Attachments (Terms of Use)

Description David Davis 2014-08-05 11:25:33 UTC
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.

Possible solutions:

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.

Comment 1 RHEL Product and Program Management 2014-08-05 11:33:48 UTC
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.

Comment 3 Ivan Necas 2014-08-05 11:49:31 UTC
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.

Comment 4 David Davis 2014-08-18 19:51:35 UTC
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
composite view.

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.

Comment 6 Bryan Kearney 2015-10-13 12:49:15 UTC
Incremental errata, which were delivered with Satellite 6.1, addresses this bug. Closing this out.

Note You need to log in before you can comment on or make changes to this bug.