Skip to content
This repository has been archived by the owner on Aug 2, 2023. It is now read-only.

Stack controller can default to pipelines in Kab CR instance for Odo #762

Open
kaczyns opened this issue Jun 11, 2020 · 0 comments
Open

Comments

@kaczyns
Copy link
Member

kaczyns commented Jun 11, 2020

This is a child of issue #647.
When the stack controller is in Odo mode, if the Stack CR instance has no pipelines defined, it should use the ones in the Kabanero CR instance. There can be max 1 Kabanero CR instance in the namespace (and there has to be one or the stack controller wouldn't be running).

The admission controller for stacks probably gets upset if a stack version does not have pipelines defined. We'll probably have to change that, so that if the Stack is using a devfile, it's OK to have no pipeline definition. The stack controller can get it from the Kabanero CR instance instead at runtime.

The stack controller will probably need to watch Kabanero CR instances, if it's not already, so that if someone changes the default pipelines in the Kabanero CR instance, the stack controller will re-process the Stack CR instances. The watch only needs to be set up when the stack controller is in Odo mode. Unless we're already watching Kabanero CR instances in which case none of this matters. Remember that in a Gitops model, the Kabanero CR instance will not be the owner of the Stack CR instance.

We should verify that the Stack CR status pipeline information is complete when using the default pipelines from the Kabanero CR instance. I don't see why it wouldn't be or couldn't be, but lets just be sure that the information is populated correctly, such that if someone were to modify the Stack CR instance and add pipeline information for a version of the stack, that the stack controller would be able to correctly remove the default pipeline artifacts and replace them with the newly over-ridden ones.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant