-
Notifications
You must be signed in to change notification settings - Fork 474
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
Add Customize Developer Catalog Categories enhancement #508
Add Customize Developer Catalog Categories enhancement #508
Conversation
34f3431
to
95ebf0a
Compare
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.
Is this planned for 4.7? I ask because if dev console becomes a dynamic plugin in 4.8, we might want this to be part of the dev console operator config.
|
||
### Goals | ||
|
||
- Extract the Developer Catalog categories into a CRD to allow cluster admins to customize them. |
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.
This makes it sound like we're creating a new CRD instead of just updating the console config. I'd probably phrase it just to say we're adding a configuration option for customizing the categories.
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.
Updated this to
- Add configuration options to allow cluster admins to customize catalog categories.
- Provide a list of default values to the admin
|
||
* `id: string`, identifier used in the URL to enable deeplinking in console | ||
* `label: string`, category display label | ||
* `disabled: boolean`, flag to hide this category from the sidebar so that the admin is not required to remove a complete section to hide an unused category |
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.
We typically don't have this flag in our APIs. The presence of an item indicates whether something is enabled or not.
I'd assume if a category doesn't have any items it's already hidden in the UI. If this is what you mean by unused, it might be taken care of already.
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 removed this disabled flag. The overall proposal changed a little bit to simplify things.
We can keep the existing default categories in the dev console code and will use them as fallback if there is no customization available. This makes upgrades / downgrades easier, as well we don't need to keep disabled categories in the CRD.
Christian comes with the idea of providing a code snippet to restore the current defaults when editing the Console
CRD. Wdyt?
|
||
* `subcategories:` a list of Categories | ||
|
||
If a category has subcategories the dev console will show all tags from a selected category and all subcategories. |
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.
If an item has a tag from the top-level categories, but doesn't match any tags from the subcategories, what is the behavior?
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.
The idea is that a (top level) category shows all items which are shown when you go through all subcategories.
For example:
├── Languages
│ ├── Java (tags: java)
│ └── Go (tags: go)
If you select languages we want show both languages without the need to add both tags also to "Languages". Wdyt?
spec: | ||
customization: | ||
brand: online | ||
devcatalog: |
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.
devcatalog: | |
developerCatalog: |
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.
Changed. Did you think we should keep developerCatalog.categories
?
Or maybe more structured developer.catalog.categories
?
Or in a case when thinking about one catalog for both sides maybe only catalog.categories
?
But changed this to your recommendation for now. Thanks
|
||
### Upgrade / Downgrade Strategy | ||
|
||
When updating to 4.7 we need to ensure that the default types was automatically added to the existing Console CR. |
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's probably simpler to just hard code the defaults in the console code and use those if the stanza isn't present in the config CR. This is better as well if we add new default categories later, which would be hard if we add the defaults to the config CR.
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.
Yep, your rigtht. I changed the proposal to keep the hard coded default values in console and "just" allow the admin to override this default so that we use the CR or static version. No merging. No migrating.
customization: | ||
brand: online | ||
devcatalog: | ||
categories: |
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.
Does this completely replace the categories or just add new categories?
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.
Updated the document that we use the hard coded version OR the customization version. Ok?
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.
This will completely replace the dev catalog categories.
|
||
## Drawbacks | ||
|
||
- A bigger `Console` CR must fetches by the console before the Developer Catalog is opened. |
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.
We wouldn't be fetching the CR in the frontend code. The operator will watch the config, and then wire through the values to the console backend through its config map in the openshift-console namespace.
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.
Thanks 👍 Changed the document to make it clear that the frontend reads the data from the ConfigMap.
95ebf0a
to
ef7b774
Compare
ef7b774
to
3d62395
Compare
customization: | ||
brand: online | ||
devcatalog: | ||
categories: |
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.
This will completely replace the dev catalog categories.
3d62395
to
5eb7479
Compare
Wow, thanks @christianvogt. 👍 Applied all changes from you and marked your changes as resolved for the next round. 😏 |
5eb7479
to
669cb3f
Compare
@spadgett @christianvogt Dropped the section "Fetching data from ConfigMap" completely because it suggests a wrong approach.
Anything else to-do here? |
669cb3f
to
ffb854d
Compare
/assign @spadgett @christianvogt @rohitkrai03 |
lgtm @spadgett could you please have a look |
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.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jerolimov, spadgett The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Issue: https://issues.redhat.com/browse/ODC-5033
Rendered preview: https://github.com/jerolimov/openshift-enhancements/blob/catalog-categories/enhancements/console/catalog-categories.md
API CRD change PR (also WIP): openshift/api#763
/cc @spadgett @christianvogt @rohitkrai03