Bug 1620079
Summary: | [RFE] Performing external capsule sync needs version consistency | ||
---|---|---|---|
Product: | Red Hat Satellite | Reporter: | Mihir Lele <mlele> |
Component: | Documentation | Assignee: | Melanie Corr <mcorr> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Sergei Petrosian <spetrosi> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 6.4 | CC: | adahms, mcorr, mlele, mmccune, peter.vreman |
Target Milestone: | Unspecified | Keywords: | FutureFeature, Reopened |
Target Release: | Unused | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-09-18 08:49:21 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1122832, 1619394 |
Description
Mihir Lele
2018-08-22 12:25:25 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 Setting release flags. 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. 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. 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 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. 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 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 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. 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. (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 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. (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 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 Thanks Stephen and Peter. I'll take a look. These changes are now live on the Customer Portal. 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 |