Bug 1620079 - [RFE] Performing external capsule sync needs version consistency
Summary: [RFE] Performing external capsule sync needs version consistency
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Documentation
Version: 6.4
Hardware: x86_64
OS: Linux
low
low
Target Milestone: Unspecified
Assignee: Melanie Corr
QA Contact: Sergei Petrosian
URL:
Whiteboard:
Depends On:
Blocks: 1122832 1619394
TreeView+ depends on / blocked
 
Reported: 2018-08-22 12:25 UTC by Mihir Lele
Modified: 2023-09-07 19:19 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-09-18 08:49:21 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1305040 0 high CLOSED [RFE] User control of Capsule sync policy and other traffic from Satellite to capsule 2022-03-13 14:00:25 UTC

Internal Links: 1305040

Description Mihir Lele 2018-08-22 12:25:25 UTC
Document URL: Red_Hat_Satellite-6.4-Beta-Content_Management_Guide-en-US.pdf

Section Number and Name: NA

Describe the issue:  Satellite docs should clearly mention that capsule sync between inconsistent Satellite and capsule versions is not supported or it can lead into issues.

For example: Satellite is on 6.4 and external capsule is still at 6.3.1

Additional information: 

We have had cases in the past where we have asked the customer to upgrade their capsule to the latest to bring the version consistency among the satellite and the capsule.

Comment 1 Melanie Corr 2018-08-23 09:29:45 UTC
(In reply to Mihir Lele from comment #0)

Hi Mihir, 

Thank you for raising this bug. 
> Document URL: Red_Hat_Satellite-6.4-Beta-Content_Management_Guide-en-US.pdf
> 
> Section Number and Name: NA

Can you be more specific about the section number and name, so that we can identify where the customers are having challenges? It is best to place it in the context that the customer will encounter it.


Thank you, 

Melanie

Comment 2 Andrew Dahms 2018-08-27 04:12:30 UTC
Setting release flags.

Comment 3 Mihir Lele 2018-09-10 10:24:29 UTC
Melanie,

I think that we can put this in the upgrade guide at the end of the satellite upgrade section. I initially thought that content management guide would be the best place to put this. But again, customers will not be referring to the content management guide every time they perform an upgrade.

Comment 4 Melanie Corr 2018-09-10 10:32:50 UTC
There is a note in 

https://access.redhat.com/documentation/en-us/red_hat_satellite/6.4-beta/html/upgrading_and_updating_red_hat_satellite/upgrading_process_overview

that captures what you're looking for. 

I am closing this bug as not a bug, if more details, specific section numbers, etc are provided, you can reopen. 

For now I think we are OK.

Comment 5 Peter Vreman 2018-09-12 15:55:33 UTC
Please re-open, this was not a Documentation issue.

As the original trigger for the RFE is that the Sat6 should prevent me from doing it in the Application.

There can be time betwene the Sat6 srever upgrade and the Capsule upgrades!
E.g. in Section 3.2 there is:

'If you use Content Views to control updates to a Capsule Server’s base operating system, or for the Capsule Server repository, you must publish updated versions of those Content Views. '

This CV publishing step will trigger a Capsule Sync!


Peter

Comment 6 Mike McCune 2018-09-14 16:10:31 UTC
Peter, 

we are tracking your desired behavior in this RFE here:

https://bugzilla.redhat.com/show_bug.cgi?id=1305040

this is purely a documentation bug and am going to re-close it.

Feel free to add additional information to the above bug.

Comment 7 Peter Vreman 2018-09-15 07:30:06 UTC
Melanie,

How about my remark about the ContentView publishing step in the Capsule upgrade section? Is this really correct and wished from process point of view to upgrade the server first and then updte and re-publish ContentViews before doing the Capsule upgrades?

Peter

Comment 8 Stephen Wadeley 2018-09-15 15:57:36 UTC
Hello Peter

Re comment 7

If the Capsule's base system is subscribed to a Content View then that CV needs to be updated with the new packages to be able to update or upgrade the OS and Capsule Server itself (the application).

Re comment 5

Until a way to toggle on and off, or otherwise control, the Capsule sync is added[1], would removing the  Library help reduce the traffic? This should stop the Capsules automatically syncing after each CV is published as it will only sync after an environment has been promoted.

But note that if you have custom products that are not in Content Views they would no longer be pushed to the Capsules as a side effect.

Thank you

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1305040#c14

Comment 9 Stephen Wadeley 2018-09-15 16:09:11 UTC
Craig Donnelly explained to me:

The Capsule will always work to match all content that is on the Satellite for the configured Lifecycle Environments that the Capsule is configured in.

Following examples:
1. Capsule is configured to 'Library' -> Capsule will sync ALL repositories every time Satellite does, plus any CV's that get published - since they all start in Library.

2. Capsule is configured to 'Random LC' -> Capsule will sync every time a CV is promoted into Random LC.

The capsule should not be triggering any sync jobs for any content that falls outside of the Lifecycle Environments it is configured for.

Comment 10 Peter Vreman 2018-09-15 16:37:59 UTC
My feedback is about the step in the upgrade guide to update the CV for the capsules. This looks like for me to be a chicken-and-egg problem.

It has nothing to do with which LC are associated with a Capsule. I am aware of that and do not use have the Library associated for that reason.

Comment 11 Stephen Wadeley 2018-09-15 16:49:38 UTC
(In reply to Peter Vreman from comment #10)
> My feedback is about the step in the upgrade guide to update the CV for the
> capsules. This looks like for me to be a chicken-and-egg problem.
> 
I agree, but if you do not update the CV that has the Capsule package repo, how will you get the new packages to update the Capsule?

Thank you

Comment 12 Peter Vreman 2018-09-17 06:55:53 UTC
Stephan,

THat is the upgrade process that must be more clear about this. E.g. that you need to prepare all CVs including the Capsule CVs in the first step even before doing the Sat6 servre upgrade.

The current process is simply incorrect because you upgrade Sat6Server to 6.4 and then a step is there to do an update of the Capsule CVs that also triggers a CapsuleSync when the capsules are still on 6.3

In my opinion the sync from 6.4 to a 6.3 capsule should be not allowed if it is not supported to prevent failure during a capsule upgrade.
Only if Sat6 supports running capsules on relase N-1 then it is ok.

Have you tried the upgrade process with the steps in the manual? Then you must have noticed it that is does a capsule sync with the capsule sstill on 6.3.

Comment 13 Stephen Wadeley 2018-09-17 08:39:55 UTC
(In reply to Peter Vreman from comment #12)
> Stephan,
> 
> THat is the upgrade process that must be more clear about this. E.g. that
> you need to prepare all CVs including the Capsule CVs in the first step even
> before doing the Sat6 servre upgrade.
Ok, Docs can do that, thank you for making that clear.
(I was also wondering if putting the Capsules in their own LC environment or setting "On Demand" only in the repo would solve the problem but your suggestion sounds much better.)
> 
> The current process is simply incorrect because you upgrade Sat6Server to
> 6.4 and then a step is there to do an update of the Capsule CVs that also
> triggers a CapsuleSync when the capsules are still on 6.3
I am very sorry about that.
> 
> In my opinion the sync from 6.4 to a 6.3 capsule should be not allowed if it
> is not supported to prevent failure during a capsule upgrade.
> Only if Sat6 supports running capsules on relase N-1 then it is ok.
I think that is something for Engineering to solve, in:
Bug 1305040 - [RFE] User control of Capsule sync policy and other traffic from Satellite to capsule 
> 
> Have you tried the upgrade process with the steps in the manual? Then you
> must have noticed it that is does a capsule sync with the capsule sstill on
> 6.3.
I have tested upgrade procedures but not with those exacts steps and a Capsule attached.
Docs team does not normally do such extensive tests (until last Friday, I worked in docs.)

I'll have a look at the guide now and make a new post for Melanie, this bugs assignee


Thank you

Comment 14 Stephen Wadeley 2018-09-17 08:55:09 UTC
Hello Melanie

Peter in comment 12 suggests we can solve this issue if tell the user to update the repos before upgrading Satellite so that a Capsule sync can take place.


Looking in "3.2. Upgrading Capsule Servers"[1]

I see these two steps:

Ensure the Red Hat Satellite Capsule 6.4-Beta repository is enabled in Satellite Server and synchronized. 

If you use Content Views to control updates to a Capsule Server’s base operating system, or for the Capsule Server repository, you must publish updated versions of those Content Views. 

I think we should copy those steps to "Upgrading Red Hat Satellite" chapter, in "3.1. Upgrading Satellite Server" as it applies to connected and disconnected use cases.

As this will take a while, we should put these steps first. We should add that you must allow time for the Capsules to synchronize these changes before starting the upgrade of Satellite Server. We could say "Until Red Hat bug 1305040 is resolved, allow time for the Capsules to synchronize these changes"

Thank you


[1] https://access.redhat.com/documentation/en-us/red_hat_satellite/6.4-beta/html/upgrading_and_updating_red_hat_satellite/upgrading_red_hat_satellite#upgrading_capsule_server

[2] https://access.redhat.com/documentation/en-us/red_hat_satellite/6.4-beta/html/upgrading_and_updating_red_hat_satellite/upgrading_red_hat_satellite#upgrading_satellite_server_parent

Comment 15 Melanie Corr 2018-09-17 09:42:33 UTC
Thanks Stephen and Peter. I'll take a look.


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