Bug 1177766 - [RFE] Republish composite content views on republished component content view
Summary: [RFE] Republish composite content views on republished component content view
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Content Views
Version: 6.0.6
Hardware: Unspecified
OS: Unspecified
high
high vote
Target Milestone: 6.4.0
Assignee: Partha Aji
QA Contact: Ales Dujicek
URL:
Whiteboard:
: 1167688 1375192 (view as bug list)
Depends On:
Blocks: 1122832 260381 GSS_Sat6Beta_Tracker, GSS_Sat6_Tracker 1296845 1411074 1573402
TreeView+ depends on / blocked
 
Reported: 2014-12-30 10:45 UTC by Peter Vreman
Modified: 2019-12-16 04:36 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-16 15:25:56 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:0336 normal SHIPPED_LIVE Important: Satellite 6.3 security, bug fix, and enhancement update 2018-02-21 22:43:42 UTC
Red Hat Product Errata RHSA-2018:2927 None None None 2018-10-16 15:27:08 UTC
Foreman Issue Tracker 15950 None None None 2016-09-16 13:35:20 UTC
Red Hat Knowledge Base (Solution) 2619581 None None None 2016-11-13 17:10:02 UTC

Description Peter Vreman 2014-12-30 10:45:33 UTC
Description of problem:
After updating a standard content view i have to "refresh" also all composite content views. This is a complex and time consuming process at the moment.
- Republish (or promote) the regular content view
- Query all content views (filtering on only composite content views is not possible)
- Check each content views if it is a composite content views and if yes, it one of the components is the updated regular content view
- Republish the composite content view
- In case of promotion, promote the composite content view to the corresponding stage


It would be helpful to have a more simple process that can support here.
- Having a "latest" published/promoted version (just like the puppet modules) in the composite content view that will autorefresh in case the content view versions of the attached lifecycle environment stage is updated.
- If attached to "latest" the underlying standard content view is then published/promoted the composite content view will also be "refreshed"
- Additionally the refreshing of the composite content views can be done in parallel, that will also reduce the time needed.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Create regular CV
2. Create composite CV
3. Republish regular CV

Actual results:
Composite CV is not updated

Expected results:
Composite CV is updated with the latest content of the regular CV


Additional info:

Comment 1 RHEL Product and Program Management 2014-12-30 10:54:09 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 4 Michael Heldebrant 2015-03-13 19:44:00 UTC
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.

Comment 5 Tim van Dijk 2016-03-09 15:59:52 UTC
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 ;-)

Comment 6 Pat Riehecky 2016-06-10 17:50:20 UTC
+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.....

Comment 8 Bryan Kearney 2016-08-04 20:15:54 UTC
Moving 6.2 bugs out to sat-backlog.

Comment 9 Brad Buckingham 2016-09-16 13:35:20 UTC
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.

Comment 10 Brad Buckingham 2016-09-16 13:36:38 UTC
*** Bug 1167688 has been marked as a duplicate of this bug. ***

Comment 12 Brad Buckingham 2016-11-11 19:58:53 UTC
*** Bug 1375192 has been marked as a duplicate of this bug. ***

Comment 13 Peter Vreman 2016-11-12 13:00:07 UTC
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.

Comment 14 Bryan Kearney 2016-12-07 09:09:54 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/15950 has been resolved.

Comment 18 Djebran Lezzoum 2017-10-06 07:33:13 UTC
qe_test_coverage PR: https://github.com/SatelliteQE/robottelo/pull/5323

Comment 19 Jitendra Yejare 2017-11-24 09:54:33 UTC
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.

Comment 20 Peter Vreman 2017-11-24 10:06:10 UTC
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.

Comment 21 Jitendra Yejare 2017-12-11 12:37:05 UTC
@Peter,

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

Comment 25 errata-xmlrpc 2018-02-21 12:29:34 UTC
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

Comment 26 Peter Vreman 2018-02-23 11:23:41 UTC
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?

Comment 27 Peter Vreman 2018-02-23 11:27:29 UTC
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'

Comment 28 Peter Vreman 2018-02-23 11:30:06 UTC
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.

Comment 29 pm-sat@redhat.com 2018-02-23 13:13:29 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/15950 has been resolved.

Comment 30 Bryan Kearney 2018-02-24 18:58:00 UTC
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.

Comment 31 Partha Aji 2018-02-25 16:51:45 UTC
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.

Comment 32 Peter Vreman 2018-02-26 16:09:56 UTC
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.

Comment 34 Partha Aji 2018-06-26 14:38:25 UTC
Hey Pete,
Updated the description on BZ 1536194. Check https://bugzilla.redhat.com/show_bug.cgi?id=1536194#c8

Comment 37 errata-xmlrpc 2018-10-16 15:25:56 UTC
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


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