Skip to content
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

Conversation

vyzigold
Copy link
Contributor

@vyzigold vyzigold commented Aug 6, 2024

No description provided.

Copy link

openshift-ci bot commented Aug 6, 2024

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@vyzigold
Copy link
Contributor Author

vyzigold commented Aug 6, 2024

/test all

@vyzigold vyzigold force-pushed the add_telemetry_to_delta branch 5 times, most recently from 396a824 to ab4639d Compare August 12, 2024 13:02
@vyzigold vyzigold marked this pull request as ready for review October 4, 2024 16:04
Comment on lines 14 to 38
```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
```
Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/928cc3cb5608454cbef64fdab1babe79

✔️ noop SUCCESS in 0s
✔️ rhoso-architecture-validate-uni04delta SUCCESS in 3m 43s
rhoso-architecture-validate-uni04delta-ipv6 FAILURE in 3m 17s

Copy link
Contributor

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/80e490889e3548589910c00f8b83aeb6

✔️ noop SUCCESS in 0s
✔️ rhoso-architecture-validate-uni04delta SUCCESS in 3m 43s
rhoso-architecture-validate-uni04delta-ipv6 FAILURE in 3m 13s

Heat has been added by another PR already
@@ -4,5 +4,6 @@ kind: Kustomization
components:
- ../../../../dt/uni04delta-ipv6
resources:
- coo-sub.yaml
Copy link
Contributor

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]

- 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

Copy link
Contributor

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?)

[1] https://github.com/openstack-k8s-operators/ci-framework/blob/main/roles/kustomize_deploy/tasks/execute_step.yml#L10-L11

Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor

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.

@hjensas
Copy link
Contributor

hjensas commented Oct 22, 2024

/lgtm

Copy link
Contributor

@abays abays left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/approve

Copy link

openshift-ci bot commented Oct 22, 2024

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@abays
Copy link
Contributor

abays commented Oct 22, 2024

/hold

@vyzigold wants a @cjeanner review

Copy link
Contributor

@softwarefactory-project-zuul softwarefactory-project-zuul bot merged commit a0cf8f9 into openstack-k8s-operators:main Oct 22, 2024
7 checks passed
@vyzigold
Copy link
Contributor Author

/hold

@vyzigold wants a @cjeanner review

That's not required. I just saw that I received a LGTM and not an approval. The first message in the PR suggested to add him as a reviewer for approval, so that's what I did. Thanks for the approval. I'm really happy this is finally merged.

@vyzigold
Copy link
Contributor Author

/cherrypick 18.0-fr1

@openshift-cherrypick-robot

@vyzigold: new pull request created: #422

In response to this:

/cherrypick 18.0-fr1

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.

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

Successfully merging this pull request may close these issues.

5 participants