-
Notifications
You must be signed in to change notification settings - Fork 297
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixes #38048 - Add rolling content views #11240
base: master
Are you sure you want to change the base?
Conversation
Here is a question to @jeremylenz I guess. |
A content view environment should be created for each rolling content view. The label would be I would expect that rabl to work "for free" - so |
I went and double checked. We are currently doing this by calling
I am getting |
We have decided to split out the top commit on this PR into a separate PR and issue:
The reasons for doing so are as follows:
|
We believe this PR is now "ready for review". To summarize:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking great!
Tested and working pretty much as expected.
Tested with
- host assigned to multiple content view environments
- attempting to disable RH repo included in rolling CV
- attempting to remove repo from product included in rolling CV
- hammer content-view-environment list
Some outstanding UI things:
On the Red Hat Repositories page when you go to disable a repository, there's a tooltip that says "cannot be disabled because it is a part of a published content view." Should that be updated to say something like "..part of a content view" or "..part of a published or rolling content view"?
I like the icon you chose to denote rolling type (vs. CV/CCV). That should also be updated
- in new All Hosts page (ForemanColumnExtensions)
- on host details ContentViewDetails card
Some more wording (cc @maximiliankolb) and other suggestions below
@jeremylenz The following should now be the only remaining ToDo from the things you mentioned:
I will continue with this on Monday. Once that is done, I will re-base and squish everything together. It would also be great if we could get #11253 reviewed and merged soonish, since this PR depends on it (and maintaining multiple branches is annoying). |
The latest push fixes several UI things including the things mentioned by @jeremylenz. In particular:
|
Looks like I now broke some UI tests. I don't expect to get around to fixing them before Monday. |
Co-authored-by: Markus Bucher <[email protected]> Co-authored-by: Nadja Heitmann <[email protected]> Co-authored-by: Quirin Pamp <[email protected]> Co-authored-by: Bernhard Suttner <[email protected]>
Tests are green, and everything is squished and rebased. My understanding is that the plan is to postpone merging until after Katello 4.16 has branched. So far, and now that #11253 has been merged, this branch has been relatively easy to maintain (no VCR recordings), so I am fine with finalizing review now, and then just occasionally rebasing the branch on top of master as we approach the next Katello branching. |
isSelected={component} | ||
> | ||
{__('Single content view consisting of e.g. repositories')} | ||
{__(contentViewDescriptions.CV)} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure this translation will work..Better to translate strings in contentViewDescriptions directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It won't work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Marking a review on this so we don't forget.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initial testing is generally looking good, some questions:
isSelected={component} | ||
> | ||
{__('Single content view consisting of e.g. repositories')} | ||
{__(contentViewDescriptions.CV)} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Marking a review on this so we don't forget.
...ack/components/extensions/HostDetails/Cards/ContentViewDetailsCard/ContentViewDetailsCard.js
Outdated
Show resolved
Hide resolved
|
||
const dropDownItems = []; | ||
if (!rolling) { | ||
dropDownItems.push(<DropdownItem key="copy" ouiaId="cv-copy" onClick={() => { setCopying(true); }} > {__('Copy')}</DropdownItem>); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be honest, I guess we considered it as a follow-up feature (if needed).
@@ -56,6 +57,7 @@ def plan(repo, options = {}) | |||
end | |||
plan_self(:id => repo.id, :sync_result => output, :skip_metadata_check => skip_metadata_check, :validate_contents => validate_contents, | |||
:contents_changed => output[:contents_changed]) | |||
update_rolling_content_views(repo) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was having the rolling CV update be asynchronous considered? I suppose it's likely that users won't have many rolling content views, so the sync/upload shouldn't likely be blocked too long, but I'm curious if it was a consideration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we did, but since there is currently no progress bar for "Add repository", it would not be visible for the user that this runs in background.
As you said, it was sufficiently fast (at least in the tests I did), so blocking has not been an issue, yet.
If we want to do it asynchronously, we definitely will need an indication in the UI that it is running in the background.
Issue: https://projects.theforeman.org/issues/38048
Community discussion: https://community.theforeman.org/t/transparent-content-view-for-limiting-repository-access-in-katello/39389
Hammer changes to go with this feature: Katello/hammer-cli-katello#974