Bug 1177766

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.

This will be usefull for docker container hosts to match both RHEL6 and RHEL7 content changes for physical/virtual servers and containers building from the composite content view repositories as an example.

This feature should also be configurable as a feature of the composite content view to auto promote or not.

To "+1" the original poster: Peter Vreman and also referring to the support case number of a college within another company (case number: 01597635), I too would like to request some simplification/automation and scheduling of the publish an promote processes.

Currently we're working with a fairly straight forward configuration: DEV, TST, ACC and PRD as the Life-cycle Environments and four Composite Content Views (CCV's) which contain several content views (CV's). Every week I need to manually update the CV's and CCV's and promote them to a Life-cycle Environment. As Peter Vreman mentioned a long while ago, this is a very time consuming task.

It would be very much appreciated if these tasks could scheduled within the Satellite WebUI / CLI. Maybe a custom workflow designer within DynFlow.

For example: (In a perfect world)
When it's known that every week all hosts within one of the Life-cycle environments are updated, then it would be (VERY) helpful to be able to schedule the following (time consuming) tasks:
1. Update the repositories (which can already be automated)
2. Update relevant CV's
3. Update relevant CCV's
4. Promote the latest relevant CCV version to the first Life-cycle Environment

One week later the CCV versions within first Life-cycle Environment can then be promoted to the next Life-cycle Environment and so on.

Hope to hear from you soon ;-)

+1 for comments from Tim

That would be super awesome!!!

As part of my paranoid workflow it would handy if:
 for CCV-A, I could automate steps 1-4
 for CCV-B, I could automate steps 1-3

I may not always need the new view right away, but I wouldn't mind cleaning up old CVs that are "obsolete" once step #2 happens.....

Moving 6.2 bugs out to sat-backlog.

Some work has begun in the upstream to support this for a future release.  Based on that activity, I am moving the bugzilla to 'assigned' with the developer that has begun the work.  In addition, linking to the upstream redmine.

*** Bug 1167688 has been marked as a duplicate of this bug. ***

*** Bug 1375192 has been marked as a duplicate of this bug. ***

When implementing the feature also make sure to it is for the the end-user of the API/CLI clear that a new version has to be published because one of the Component is updated.

Possible implementations:
- Publish does nothing if the Components are not changed. Have an additional paramter force to force alrways publishing
- Have a status check to call that returns the status of the Components. Alternative this status can be enhanced with other features like errata status and counters

As an power end-user of the API/CLI i would like to see both implementations included.

Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/15950 has been resolved.

qe_test_coverage PR: https://github.com/SatelliteQE/robottelo/pull/5323

Verified !

@ Satellite 6.3 snap 25

As per comments 18, the entire bug scenario is automated as a test to get the result pass or Fail.

And as per latest Automation test run on Snap 25, the bug test passes.


The steps and expected result as per automation tests are:

```
Steps:
1. Create a non composite content view and publish it
2. Create a composite content view
3. Add the non composite content view to composite one components
  with latest option
4. Ensure that the published non composite content view version 1
  is in composite content view components
5. Publish a second time the non composite content view

Expected Result:
The composite content view component was updated to version 2 of the non composite one.
```

Changing the state to verified.

In the verification description above i miss the check that the the composite content view is also republished. Because that step was also part of my request. Not jut that the 'latest' is included.

Maybe it is implemented already and just missing in the verificiation steps.

@Peter,

Yes that is also been taken care in the automated test case for this bug at step no 4.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:0336

Re-open. Because from test case review the unattended re-publishing is nto verified.

The auto-publishing of composite content views code is https://github.com/Katello/katello/pull/7117 and merged to master at 21.Feb. Is this really part of the 6.3.0 release?

I am referring to the sentence '- Additionally the refreshing of the composite content views can be done in parallel, that will also reduce the time needed.' that was also part of the description, maybe the word refreshing was confusing, it should be read as 'implicit unattended republishing'

The Title of this BZ '[RFE] Republish composite content views on republished component content view' is even more clear explicit about my use case:

It has explicitly the word re-publishing in it twice, once for the component content view and a second one for the composite content view.

Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/15950 has been resolved.

I have asked Parth and Jitendra to take a look. We will need to re-close this due to internal processes but I would like them to weigh in first.

2 parts to this bug (treated as 2 different bugs)
1) Facilitate the publishing of the "latest" component when composite content view is published. This is taken care of by http://projects.theforeman.org/issues/15950 . This should be in 6.3

2) Given the setup in step 1 (i.e A composite cv with a component marked 'latest') automatically trigger the publish of the composite when a new version of the component gets published. That is being tackled by https://bugzilla.redhat.com/show_bug.cgi?id=1536194. This is not in 6.3 because it relies on the new composite publish speed up code to work effectively.

How should i know if i am unable to access https://bugzilla.redhat.com/show_bug.cgi?id=1536194? Please make it public visible so that the users of this BZ know that there is a follow-up BZ that will implement part 2.

Hey Pete,
Updated the description on BZ 1536194. Check https://bugzilla.redhat.com/show_bug.cgi?id=1536194#c8

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:2927