Consider a pipelined ContentView Version structure:
Every week a new CV-Version is created, which is then running through various LifecycleEnvironments. 1st week in DEV, 2nd week in TEST and 3rd week in PROD.
Critical Errata will be added to PROD immediately.
Challenge
A new critical Erratum is immediately added to the CV-Version currently in PROD. The Erratum is not automatically added to the CV-Version currently in TEST and DEV. So, once these two are promoted to PROD, PROD will no longer provide the Erratum(-fix).
This is OK for Hosts that already got the Fix, but not for Hosts that were installed from Synced-Content at a later time.
Library 0w (with Erratum)
DEV -1w ()
TEST -2w ()
PROD -3w (with Erratum)
next week:
Library +1w (with Erratum)
DEV 0w (with Erratum)
TEST -1w ()
PROD -2w ()
The issue especially shows if for any reason at the point of the release of the Erratum no Hosts are subscribed to TEST and/or DEV, because in this case the Incremental Update will not be offered to the user.
Proposal
Add a possibility to apply an Erratum not only to specific Hosts, but also creating Incremental CVs to more recent Lifecycle Environments.
Things to consider
Users might want to do this on a case-by-case basis, so it should probably be a Setting within the apply Errata workflow rather than only a Global Setting.
Consider creating a CV/LCEnv-centric Apply-Errata (UI-)workflow, rather than Apply to Hosts and only as a result to specific CVs and LCEnvs.
I believe Hammer already has a way to create an incremental update even in the absence of a non-installable erratum. It’s an interesting proposal though, and I hope more people from @katello will weigh in.
We have been thinking about getting incremental updates into the CV UI..This is essentially the core of it:
The way it is currently, only the Composite CVs with Update to latest will get the incremental updates and they’ll be updated to the latest version of component CV. I imagine we’ll need the ability to define component versioning with something like (>=3.0, <4.0) to support this for composite views.
As Jeremy mentioned, the way to do this today is via hammer. For composites even you can use --propagate-all-composites.
This is where I stand on it today too, the old UI really needs to be updated to React, and we should consider adding more incremental features at the same time, or at least soon after. There is a lot you can do with hammer that you cannot do via the UI.
@m-bucher to better understand, can you perform what you need alone via hammer? Or is there new logic that you would like there too? From the description I think it has what you need, but I want to make sure we’re on the same page first.
It is mainly about having a (nice) UI-workflow for that case. I acknowledge this is possible via hammer already, but that needs multiple requests and also looking at (or having knowledge about) the structure.
In the UI this could be done nicely by showing the used Lifecycle and which of the environments should also be updated. It should be considered when that UI will be migrated.
Okay, glad to hear the backend logic is good enough then. I’m seeing two improvements then:
Brand-new UI for incrementally updating content view versions from the content views UI. This is for people who want to perform their incremental update separately from applying the content to hosts.
Like mentioned above, we could allow users to select other lifecycle environments to receive the patches when incrementally updating host content. This can be part of the considerations when the errata application UI is rewritten. @MariSvirik might be interested in hearing about this
