-
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.
@@ -61,13 +61,13 @@ export const ContentViewEnvironmentDisplay = ({ | |||
> | |||
<Label isTruncated color="purple" href={`/lifecycle_environments/${lifecycleEnvironment.id}`}>{lifecycleEnvironment.name}</Label> | |||
</Tooltip> | |||
<ContentViewIcon composite={contentView.composite} style={{ marginRight: '2px' }} position="left" /> | |||
<ContentViewIcon composite={contentView.composite} rolling={contentViewDefault || contentView.rolling} style={{ marginRight: '2px' }} position="left" /> |
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.
Why does the default content view show up as rolling? I think I can understand the idea since the default CV acts like a rolling CV, however it is a mismatch with ::Katello::ContentView.first.rolling?
.
Since the backend mechanisms are different, I'd prefer to continue having the default content view live as a special, separate CV.
|
||
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.
@@ -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.
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