-
Notifications
You must be signed in to change notification settings - Fork 84
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
Add telemetry to uni04delta-ipv6 #361
Add telemetry to uni04delta-ipv6 #361
Conversation
Skipping CI for Draft Pull Request. |
/test all |
396a824
to
ab4639d
Compare
ab4639d
to
2109533
Compare
2109533
to
c57959d
Compare
c57959d
to
ad4aecb
Compare
```bash | ||
cat > subscription.yaml << EOF | ||
--- | ||
apiVersion: operators.coreos.com/v1alpha1 | ||
kind: Subscription | ||
metadata: | ||
name: observability-operator | ||
namespace: openshift-operators | ||
labels: | ||
operators.coreos.com/observability-operator.openshift-operators: "" | ||
spec: | ||
channel: development | ||
installPlanApproval: Automatic | ||
name: cluster-observability-operator | ||
source: redhat-operators | ||
sourceNamespace: openshift-marketplace | ||
EOF | ||
|
||
# Apply the cr | ||
oc apply -f subscription.yaml | ||
|
||
# Wait for the deployment to be ready | ||
oc wait deployments/observability-operator --for condition=Available \ | ||
--timeout=300s | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In theory this could be handled in this DT's Kustomize templates and could be added as a stage in the associated https://github.com/openstack-k8s-operators/architecture/blob/main/automation/vars/uni04delta-ipv6.yaml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it automated elsewhere when you tested it downstream?
I have no objection to this PR otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
++ I would like to see that we try to consolidate on the automation here.
For context, currently observability-operator is installed by deploy-edpm.yml
which does ansible.builtin.import_playbook: playbooks/02-infra.yml
- the 02-infra.yml
includes ci-framework role openshift_obs
if cifmw_deploy_obs: true
. AFICT only uni01alpha enabled the cifmw_deploy_obs
option.
For this change to work, we would have to update the uni04delta-ipv6 job, toggling the same option.
I would rather see we implement it as suggested by Andrew here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is automated in the downstream job, but I don't mind moving it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ended up including a yaml file containing the COO subscription and I added that into the control-plane's kustomization.yaml. I hope that works for you. I'll remove the line which deploys COO from the downstream MR and I'll do a recheck on the downstream testproject MR (both MRs depend on this PR) to test everything still works. I'll report back when I see it pass the CI.
- select: | ||
kind: OpenStackControlPlane | ||
fieldPaths: | ||
- spec.ironic.template.rpcTransport |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess touching all these ironic values here is needed to avoid the OpenstackControlPlane update done to enable Ceph do not disable/change ironic config?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. I don't remember changing anything with ironic. Must be some leftover after a merge conflict and I somehow missed it when going through the PR 🤔 . Thank you for revealing this, I'll delete this and retest with the downstream testproject.
Build failed (check pipeline). Post https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/928cc3cb5608454cbef64fdab1babe79 ✔️ noop SUCCESS in 0s |
Build failed (check pipeline). Post https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/80e490889e3548589910c00f8b83aeb6 ✔️ noop SUCCESS in 0s |
69816c2
to
2371b46
Compare
2371b46
to
b3726b2
Compare
Heat has been added by another PR already
3cc5dae
to
f6119f1
Compare
@@ -4,5 +4,6 @@ kind: Kustomization | |||
components: | |||
- ../../../../dt/uni04delta-ipv6 | |||
resources: | |||
- coo-sub.yaml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works to inject the Subscription
for COO, because it will get processed here [1]. I do wonder though if it would be cleaner to have a separate stage for it before the control-plane one. It's not a deal-breaker in my opinion, however. Maybe @fultonj and @hjensas have other thoughts.
[1]
architecture/automation/vars/uni04delta-ipv6.yaml
Lines 17 to 28 in 6c766ab
- path: examples/dt/uni04delta-ipv6/control-plane | |
wait_conditions: | |
- >- | |
oc -n openstack wait osctlplane controlplane | |
--for condition=Ready | |
--timeout=60m | |
values: | |
- name: network-values | |
src_file: nncp/values.yaml | |
- name: service-values.yaml | |
src_file: service-values.yaml | |
build_output: control-plane.yaml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a separate step would be better.
Also, I think we should move the coo-sub.yaml to the library, since this is something that multiple VA/DTs will use? Something in lib/olm-deps
, and add the kustomize to apply in examples/common
?
Then the first automation stage for VA/DT's with Telemetry would be to apply path: examples/common/coo-sub
? (I think that should work, but we may need to relax the assertions in ci-framework's kustomize_deploy
[1] role to allow automation stages without values?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those sound like good ideas to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea too. I'll see what I can do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually by moving the coo subscription to lib/olm-deps, it'll get picked up by examples/common/olm automatically. I assume that examples/common is used for each dt/va, so this way COO will be installed everywhere. I think that's OK to have it everywhere since it's listed as a dependency in the RHOSO docs and I've seen some efforts of enabling telemetry on all dts. Check it in the latest commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I rechecked my testproject downsteam which depends on these changes. It's struggling to deploy the dataplane for quite some time now (I think the hypervisor is running out of resources), but it got far enough to successfully deploy the control plane and I can confirm that this approach for deploying COO worked. I'll reach out once I manage to get a successful run of the testproject.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hjensas are you ok with this most recent update?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think it is fine. We will end up install COO always, but I saw the resource usage was discussed and agreed to be small enough to do it like this.
/lgtm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: abays, vyzigold The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
a0cf8f9
into
openstack-k8s-operators:main
/cherrypick 18.0-fr1 |
@vyzigold: new pull request created: #422 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
No description provided.