Extension mechanism bff #1935
Extension mechanism bff #1935
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
lucferbux
force-pushed
the
extension-mechanism-bff
branch
from
0fcd46f to
85570ca
Compare
lucferbux
force-pushed
the
extension-mechanism-bff
branch
from
85570ca to
58fb37a
Compare
- Added a new function `NewKubernetesClientFactory` to handle client creation based on authentication method. - Introduced a new markdown file for documenting BFF handler extensions for downstream builds. - Implemented handler overrides for Model Registry Settings to support Red Hat-specific behavior. - Created a new repository for Model Registry Settings with Kubernetes integration. - Added methods for CRUD operations on Model Registry settings, including handling database secrets. - Implemented conversion functions for unstructured Kubernetes objects to strongly typed models. - Ensured that all new functionality adheres to existing interfaces and maintains backward compatibility. feat: adapt the code to upstream Signed-off-by: lucferbux <[email protected]>
lucferbux
force-pushed
the
extension-mechanism-bff
branch
from
58fb37a to
1a10968
Compare
| "program": "${workspaceFolder}/bin/bff", | ||
| "args": [ | ||
| "--port=4000", | ||
| "--auth-method=user_token_red_hat", |
There was a problem hiding this comment.
should this red hat specific arg be present upstream?
There was a problem hiding this comment.
nah, I guess I can drop this entirely to be honest, and we no longer have that, great catch.
| - **Downstream-only artifacts** live under `clients/ui/bff/internal/<override-folder>` (and sibling vendor folders, if they are ever added). Any logic that assumes Red Hat credentials, namespaces, or controllers must stay here so other distributions do not pick it up accidentally. | ||
| - **Shared interfaces** (for example repository interfaces or the handler override registry itself) stay upstream. Only implementers that are specific to a vendor move downstream. | ||
|
|
||
| Use this rule of thumb: if a change requires Red Hat-only RBAC, Kubernetes resources, or APIs that are invisible to open-source users, keep it downstream. Everything else should be proposed upstream. |
There was a problem hiding this comment.
References to Red Hat and the downstream here as well, should these not be in upstream?
There was a problem hiding this comment.
agh, yup, not sure what I was thinking here, thanks again.
3 participants
Description
Implement extension mechanism in bff so we can override code in other codebases.
How Has This Been Tested?
Add a new extension folder with docs to know how to enable it.
Merge criteria:
DCOcheck)ok-to-testhas been added to the PR.If you have UI changes