[EPIC] Nebari Extension Mechanism #865
Labels
needs: discussion 💬
Needs discussion with the rest of the team
needs: investigation 🔍
Someone in the team needs to find the root cause and replicate this bug
type: enhancement 💅🏼
New feature or request
Comments
|
Let me talk in detail a bit more about these pieces. OAuth2 ProvisioningWe should provision an OAuth2 client per service with keycloak this is possible an encouraged. Should take as inputs:
This should return:
This is complex ... not sure how to expose to the helm chart. Possibly have some way to reference these variables within the overrides? Ideas welcome. Ingress ProvisioningTypically helm charts already have ingress hooks. How do we make sure that we are integrating this properly. I'd prefer if we hook into the existing chart for this. Since traefik will do the work for provisioning certs. Need to think about this more. Monitoring IntegrationWe should apply annotations that allow prometheus monitoring to easily connect. |
costrouc
added
the
needs: discussion 💬
|
As a first crack at this, I'd like to implement the simple bits below. Any problem with merging something like what's below in as a first step? @costrouc extensions:
- name: <helm-deployment-name>
chart: <path-to-chart-url>
version: <chart-version>
overrides:
... |
|
I like it @Adam-D-Lewis and nice in that it is definitely the minimum that would be useful and would not introduce complex dependencies on QHub bits. |
|
Please note I already have an It doesn't accept helm charts, and in any case needs some consideration for its design, but it would definitely conflict given the proposal above! |
|
I have a working basic version (not pushed yet). I'm playing around trying to deploy some helm charts with the proposed changes. Made some progress on deploying a prefect server helm chart. It seems I'm experiencing and issue similar to https://stackoverflow.com/questions/53752270/traefik-path-based-routing. It appears that when I try to go to http://github-actions.qhub.dev/prefect-ui, all the sublinks in I've also included the index.html from the prefect-ui pod below |
|
It seems that prefect is set up to host prefect ui at a subdomain rather than a subpath. Not sure if we can get around this and still use a subpath. I tried setting the prefect.endpoint from https://github.com/PrefectHQ/prefect/blob/master/src/prefect/config.toml in the prefectConfig section of https://github.com/PrefectHQ/server/blob/master/helm/prefect-server/values.yaml, but it didn't seem to help. This might be useful, https://community.traefik.io/t/serve-relative-paths-behind-traefik-pathprefix/2654 Alternatively, setting PREFECT_SERVER__BASE_URL to /prefect-ui/ may work. |
|
For prefect we'll definitely need to set PREFECT_SERVER__BASE_URL. That's the only way for a we server to truly support a base url. With traefic we can rewrite urls but that won't handle everything. |
|
After trying for a while unsuccesfully on Prefect, I've reached out to the Prefect team via a github issue to see if they have any feedback. |
|
Hi @Adam-D-Lewis, any updates from the Prefect team on this? |
Closed
|
From the development of the stages in PR #1003 I would like to propose a general "extension" mechanism that makes all parts of Qhub an extension. Take for example the following from Later when we look at
Right now this imformation is written redundantly in The structure I am suggesting. A minimal QHub
The optional functions within def input_vars(qhub_config, stage_outputs):
return {
'name': qhub_config['project_name']
}
def state_imports(qhub_config, stage_outputs):
return [(
"module.terraform-state.module.spaces.digitalocean_spaces_bucket.main",
f"{qhub_config['digital_ocean']['region']},{qhub_config['project_name']}-{qhub_config['namespace']}-terraform-state",
)]
def terraform_ouputs(qhub_config):
from qhub.render.terraform import QHubGCPProvider
return [
QHubGCPProvider(config),
]
Questions
extensions:
- path: github.com/path/to/repo
config:
a: "value"
- path: ./my/custom/qhub/extension
config:
another: 1
value: [1, 2, 3]We would add an The main reason I suggest this approach is that it allows for easy abstraction and making qhub-enterprise just another extension to qhub. |
|
I also would like to suggest another incremental option to qhub deployment, following the same idea as above. I think it might be interesting (for testing and CI purposes) to enable the qhub deployment to be split into phases, e.g This would allow qhub to be deployed from any stage, e.g. if an error occurs during deployment we can target that stage onward post fix... But the great benefit in my opinion, would be within CI testing, as we could have: runs:
using: ...
steps:
- name: Qhub 01-terraform-state provision
shell: bash
run: |
qhub deploy -c config.yaml --stages 01-terraform-state
(Do something in between, like checking if state group exists..)
- name: Qhub 02-infraestructure provision
shell: bash
run: |
qhub deploy -c config.yaml --stages 02-...
(kubectl to check current resources, test LB..., inspect vars...)The benefit in doing so would be that we could:
|
trallard
added
the
needs: investigation 🔍
costrouc
changed the title
|
Added an RFD nebari-dev/governance#35 |
github-project-automation
bot
moved this from Needs Triage 🔍
to Done 💪🏾
in QHub Project Mangement 🚀
github-project-automation
bot
moved this from New 📬
to Done 💪🏾
in 🪴 Nebari Project Management
18 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
The are many projects that we would like to integrate into Neabri and additionally other projects that we may not have the time/resources to support in Nebari. We need an extension mechanism to integrate projects that a loosely connected to Nebari. For me prefect and clearml are good examples of this. I would also like to see if this could be adopted within Nebari for some parts.
Suggestion
Features that the extension mechanism should have.
Example
Lets start a discussion about this. We need to use approach as well for a few components.
The text was updated successfully, but these errors were encountered: