-
Notifications
You must be signed in to change notification settings - Fork 14
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
relationship between continous-deployment
and it's implementation specific incarnations
#19
Comments
hrmm -- what about not doing forks at all, and using a kustomize remote base like we discussed on call? |
Because we also want the documentation and tooling in the |
That's fair, I'm good with just using cmd line rebasing + pr, this could probably be automated in some form later |
I thought we had said we don't want to rebase where possible. |
Correct, if we reference external manifests. In this case we're adding implementation specifics (like the CRC or QuickLab cluster). Let's see how this works out |
@tumido mentioned developer docs, e.g. https://firebase.google.com/docs/firestore/quickstart - they tend to have language specific examples embedded via inline tabs. But then, if you're a user of the upstream repo and maintain your own implementation specifics, would they also show up in such inline tabs? |
continous-deployment
and it's "forks"continous-deployment
and it's implementation specific incarnations
@anishasthana maybe maintaining the manifests only in this repo works, with referencing them from the downstream versions. Would all changes like in https://github.com/operate-first/continuous-deployment/pull/20/files go to an overlay then? |
That's what I'm thinking too, any quick-lab/crc/whatever specific bits can go into overlays in other repos, and they can all pull from this repository. @durandom |
I like the idea of using remote base in kustomizations But yeah, then users will need to copy paste the rest of the files (like if they want to re-use docs) from upstream onto their own repo. |
Does Markdown not support overlays? :-) |
There's a bit of confusion regarding forking odh-manifests or using kustomize remotes, we should prioritize this discussion and come to a resolution |
So in the case of the ODH operator, remote references to manifests are not possible. This is due to how the operator is structured in terms of requiring tar balls. Having the operator reach out to tan upstream github repository every time it attempts to reconcile some changes will result in a lot of slowness. So from an operator-1st standpoint, I'd propose the following:
|
To me forking odh-manifests sounds like an overkill. I would personally prefer the approach no. 2 described in this Vasek's blogpost. Let's have our repo (not a fork), which can serve as an override for the already present ODH components. This repo can also host additinal demo components we'd like to provide on top of ODH. Mind that we'd like to stick as close to upstream ODH manifests as possible and feed any our changes upstream anyways. So, this is how it can be used: See this demo repo: https://github.com/vpavlin/odh-manifests-overrides It contains a kind: KfDef
...
spec:
applications:
...
- kustomizeConfig:
repoRef:
name: manifests
path: jupyterhub/jupyterhub
name: jupyterhub
- kustomizeConfig:
repoRef:
name: manifests-overrides
path: jupyterhub/jupyterhub
name: jupyterhub
repos:
...
- name: manifests
uri: https://github.com/opendatahub-io/odh-manifests/tarball/master
- name: manifests-overrides
uri: https://github.com/vpavlin/odh-manifests-overrides/tarball/master This makes the This way we can provide changeset to the ODH components in case we need to. That's pretty useful for cases when we'd like to modify the already present resource files - like config maps, etc. It's a file based paste/replace method. On the other hand we can't use this approach to provide additional resource files or overlays to the existing components though, because we can't reference the other repository and This "override repo" can be also used to define additional manifests as new |
@tumido your approach sounds good and it's recommended from the ODH folks. I'm 👎 for a fork. And of course we'll run into problems like the last paragraph ("On the other hand we can't use this approach to ...") but that's good and if we involve ODH in solving it, that's the goal of the op1st stuff |
I looked over Vasek's blog post. It seems he himself recommends the third approach, but I agree in that the 2nd approach seems to work better for us. The only downside he points out is that upstream could change the structure of the manifests, but you would have to watch out for this even if you rebase from an upstream and update overlays (option 3). I also think you could guard against such things via a ci pipeline, or even a script you can run to ensure no new files were added unintentionally.
Not sure if I understand this bit @tumido can you elaborate?
This sounds like we would be using odh as a general cd solution like argocd, might as well use argocd at that point. |
@durandom Approach #3 is what is recommended by ODH upstream -- @HumairAK I think your interpretation of the second approach is bang-on. At that point we're not really benefiting from using anything ODH, and we should just stick with ArgoCD. @tumido can you elaborate more on what you're saying?
If this results in the first |
If I read the blog post correct, it'll only override/replace the files that are in the override repo, in the example just the config-map. |
Maybe I should've read the documentation and the blog post more carefully. I always just saw "fork" and imagined approach No1. - and tbh I'm not sure which approach we used in https://github.com/AICoE/idh-manifests So No.2 seems like it the sane approach, but introduces the classic "how do I track what I'm changing". |
Let me explain elaborate on what The
That's it. So in this example: Use this
|
Conclusion is: Approach no 2. allows us to have a single repo which gives us the option to both modify as well as extend ODH. And all of that even without forking upstream. And I see that as a win strategy. |
Just to clarify, I was more referring to using the "override" feature to add "additional" components, which seems like it might be an abuse of its intention (maybe I'm wrong). When I hear the term override, I assume it's replacing something that existed before. Maybe that's me just nitpicking. Regardless, I'm voting for option no.2 as well, this way we can retain complete tarballs whether they are from the original odh-manifest repo or overrides in our own repo. Afaik, that was the primary concern with using remote references and overlays. |
Cool, thanks for weighing in everybody. Especially @tumido for his elaborate explanations and @anishasthana for challenging. |
Any objections to storing the actual odh manifests to deploy the operator (i.e. subscription/operator group etc.) alongside the kfdef and overrides all in the same repository (i.e. operate-first /odh ) ? I would like to avoid introducing more repos if we don't need to. I can create issues there for laying out readme about our override procedure etc. |
@HumairAK no objections on my end. I like that idea. Storing them besides the kfdef and the operator, in a 3rd folder in that repo, make sense to me. 👍 |
All right going to close this ticket, let's continue any/all discussions regarding this to the odh repository. Thanks everyone for chiming in. |
We want to maintain one upstream version of https://github.com/operate-first/continuous-deployment and make it easy for downstream users to build on top of the knowledge collected upstream. While we have control over our own downstream, e.g. CRC or QuickLab, we will not have control over a 3rd party downstream.
The amount of change introduces by downstream may also vary: from just changing a key in KSOPS to replacing KSOPS with Vault.
For a downstream user, it should be easy to follow the documentation, without any context switching to different repositories.
It should also be really easy to incorporate all changes from upstream, once upstream introduces new best practices.
The original idea was to have this
continous-deployment
repo to be the upstream with no implementation specifics and let other targets be the fork of it.E.g.
continous-deployment
<--upstream_of--continous-deployment-crc
Unfortunately you can't fork into the same account/org (https://github.community/t/alternatives-to-forking-into-the-same-account/10200)
I suggest to create a new or duplicate repo
continous-deployment-crc
and handle the rebasing without GH, just like explained in https://stackoverflow.com/questions/45748400/git-fork-repo-to-same-organizationThe downside is, we don't get a nice UI how many commits each repo is ahead/behind the other one.
Thoughts?
The text was updated successfully, but these errors were encountered: