Run meta content provider against watcher-operator #5
Conversation
Since watcher-operator is currently standalone operator. So we are only building watcher-operator and skipping meta operator build. Depends-On: openstack-k8s-operators/ci-framework#2529 Depends-On: openstack-k8s-operators#2 Signed-off-by: Chandan Kumar <[email protected]>
|
Build failed (check pipeline). Post https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/eef2e28874b7442cab1e5cf954101bfd ❌ openstack-meta-content-provider FAILURE in 8m 50s |
|
recheck after adding templates directory https://github.com/openstack-k8s-operators/watcher-operator/compare/81ff7e2940329ee3e7607ddb833478cd8ea6aebe..31c82d37d7ec2c7220380ff1b50505e3df797c75 |
|
Build failed (check pipeline). Post https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/cce0969aa96843c493ad5c7880cc9b38 ❌ openstack-meta-content-provider FAILURE in 9m 26s |
|
recheck |
1 similar comment
|
recheck |
|
Build failed (check pipeline). Post https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/6f83e32cf4af44eda8f0dd3a7768ab4c ❌ openstack-meta-content-provider FAILURE in 8m 43s |
|
recheck |
|
the only reason i put a hold on this is for use to get in the habit of doing that when there is an outstanding dep. tide for better or worse will not wait for the dep to merge we don't have tide enabled yet but when we do adding a hold is important not to break things by merging out of order we can likely merge both PRs tomorrow |
| jobs: | ||
| - openstack-meta-content-provider: | ||
| vars: | ||
| cifmw_operator_build_meta_build: false |
There was a problem hiding this comment.
what does
cifmw_operator_build_meta_build: false do?
this diverges from how we use it in nova so I'm just wondering why this is being set
There was a problem hiding this comment.
oh htis is becasue its standalone and we do not need to build the OpenStack operator correct
cifmw_operator_build_meta_build is a terrible name for that but we do something call it the meta-operator so i get where it came form
assuming that understanding is correct then i think we can proceed with this as is.
There was a problem hiding this comment.
based on the description at https://github.com/openstack-k8s-operators/ci-framework/blob/85b670cd3702aa167f5d3e206547ad659271df8b/roles/operator_build/README.md?plain=1#L18 yes it's for skipping meta operator build
There was a problem hiding this comment.
only concern/question is do we want to start this yet? I mean lets add some jobs that need the content provider ? (or do we already have something lined up right after this merges) Like this it will just build images every time and nothing will use them.
There was a problem hiding this comment.
@marios @SeanMooney Thank you for the reviews and comment! you both are correct, cifmw_operator_build_meta_build is skipping meta operator build.
There was a problem hiding this comment.
only concern/question is do we want to start this yet?
I mean lets add some jobs that need the content provider ? (or do we already have something lined up right after this merges) Like this it will just build images every time and nothing will use them.
For right now, we want to go ahead like this. It will validate the building process of watcher operator.
Once some CRDS and Kuttl tests will be added to the operator, then I think we can proceed with adding Kuttl/EDPM job to consume the operator image from content provider job.
| jobs: | ||
| - openstack-meta-content-provider: | ||
| vars: | ||
| cifmw_operator_build_meta_build: false |
There was a problem hiding this comment.
based on the description at https://github.com/openstack-k8s-operators/ci-framework/blob/85b670cd3702aa167f5d3e206547ad659271df8b/roles/operator_build/README.md?plain=1#L18 yes it's for skipping meta operator build
Since watcher-operator is currently standalone operator. So we are only building watcher-operator and skipping meta operator build.
Depends-On: openstack-k8s-operators/ci-framework#2529
Depends-On: #2