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 worker node to run test operator on uni04delta-ipv6 deployments #403

Conversation

gmarcian
Copy link
Contributor

In order to run disruptive tests on the uni04delta env, We need to have a worker node dedicated for the test operator.
Thus we can ensure that test pods won't be affected by the failures.

  • Running disruptive tests is part of HA testing of the system. Please see OSPRH-7602

Copy link

openshift-ci bot commented Sep 18, 2024

Hi @gmarcian. Thanks for your PR.

I'm waiting for a openstack-k8s-operators member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

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/605f01ec091f444fb44e5598bc3cf611

✔️ noop SUCCESS in 0s
✔️ rhoso-architecture-validate-uni04delta SUCCESS in 5m 02s
rhoso-architecture-validate-uni04delta-ipv6 FAILURE in 4m 04s

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/77b345f8b27c4b94894fb0ec2736c3a9

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

@gmarcian gmarcian changed the title [Draft] Add worke node to run test operator on uni04delta [Draft] Add worker node to run test operator on uni04delta Sep 22, 2024
@gmarcian gmarcian force-pushed the add_worker_unidelta_ipv6 branch from 7fd9d21 to 04d698a Compare September 22, 2024 20:35
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/cb8f76a23e4040518b98dade07c4f325

✔️ noop SUCCESS in 0s
✔️ rhoso-architecture-validate-uni04delta SUCCESS in 3m 54s
rhoso-architecture-validate-uni04delta-ipv6 FAILURE in 4m 18s

@fultonj
Copy link
Contributor

fultonj commented Sep 23, 2024

rhoso-architecture-validate-uni04delta-ipv6 fails here

Sunday 22 September 2024  16:39:33 -0400 (0:00:00.050)       0:00:29.477 ****** 
fatal: [localhost]: FAILED! => changed=true 
  cmd:
  - oc
  - kustomize
  delta: '0:00:00.395164'
  end: '2024-09-22 16:39:34.530784'
  msg: non-zero return code
  rc: 1
  start: '2024-09-22 16:39:34.135620'
  stderr: 'error: fieldPath `data.node_3.internalapi_ip` is missing for replacement source ConfigMap.[noVer].[noGrp]/network-values.[noNs]'
  stderr_lines: <omitted>
  stdout: ''
  stdout_lines: <omitted>

https://softwarefactory-project.io/zuul/t/rdoproject.org/build/26179debe63644d6bff1fc3873e5d9dd

@abays
Copy link
Contributor

abays commented Oct 21, 2024

Is this still a draft? Has it been tested upstream and downstream?

@gmarcian gmarcian force-pushed the add_worker_unidelta_ipv6 branch 2 times, most recently from 918e4d2 to 77ff71b Compare November 5, 2024 13:22
@gmarcian gmarcian force-pushed the add_worker_unidelta_ipv6 branch from 77ff71b to 52f9c6c Compare November 14, 2024 02:38
@gmarcian gmarcian changed the title [Draft] Add worker node to run test operator on uni04delta Add worker node to run test operator on uni04delta-ipv6 deployments Nov 19, 2024
@gmarcian
Copy link
Contributor Author

@fultonj
Copy link
Contributor

fultonj commented Nov 19, 2024

https://sf.hosted.upshift.rdu2.redhat.com/zuul/t/tripleo-ci-internal/build/4702eb82b51945868ad8bbbbbd107dd8/logs

I see that test failed. Shouldn't it pass before we merge it?

@fultonj
Copy link
Contributor

fultonj commented Nov 19, 2024

So all uni04delta-ipv6 deployments will be able to run with four OCP nodes; i.e. 3 masters and 1 new worker node introduced by this patch?

I see it's following the pattern used here:

426b290

@arxcruz I'm assuming our testing nodes have the resources to handle the exta node.

@tosky I'm assuming this won't cause problems for storage related tests in this DT.

I'm OK with it provided we have the resources to handle it and others who depend on uni04delta-ipv6 are OK with it.

@abays
Copy link
Contributor

abays commented Nov 19, 2024

https://sf.hosted.upshift.rdu2.redhat.com/zuul/t/tripleo-ci-internal/build/4702eb82b51945868ad8bbbbbd107dd8/logs

I see that test failed. Shouldn't it pass before we merge it?

I also echo John's question.

@gmarcian
Copy link
Contributor Author

@abays , @fultonj, a lot of tobiko tests failed, but IMO these failures are unrelated to this change. Part of them relate to some tobiko issue, another failures are since vms, created by these tests, are unreachable via their floating IPs, which is because of ipv6/ipv4 misconfiguration.
To be more confident about the patch, I will re-trigger the job with tempest tests, which are expected to work the same way as on the original uni04delta-ipv6 job.

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.

Given @gmarcian's recent update, I am good with this. But I will defer to @fultonj to have the final word for approval.

/lgtm

@openshift-ci openshift-ci bot added the lgtm label Nov 21, 2024
Copy link
Contributor

@fultonj fultonj left a comment

Choose a reason for hiding this comment

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

/approve
/lgtm

Copy link

openshift-ci bot commented Nov 21, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fultonj, gmarcian

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

Copy link
Contributor

@softwarefactory-project-zuul softwarefactory-project-zuul bot merged commit 1100a50 into openstack-k8s-operators:main Nov 21, 2024
7 checks passed
gmarcian pushed a commit to gmarcian/architecture that referenced this pull request Nov 25, 2024
…er_unidelta_ipv6

Add worker node to run test operator on uni04delta-ipv6 deployments

In order to run disruptive tests on the uni04delta env, We need to have a worker node dedicated for the test operator.
Thus we can ensure that test pods won't be affected by the failures.

Running disruptive tests is part of HA testing of the system. Please see OSPRH-7602

Reviewed-by: Andrew Bays <[email protected]>
Reviewed-by: John Fulton <[email protected]>
softwarefactory-project-zuul bot added a commit that referenced this pull request Nov 25, 2024
Cherry-pick pull request #403 from gmarcian/add_worker_unidelta_ipv6

Add worker node to run test operator on uni04delta-ipv6 deployments
In order to run disruptive tests on the uni04delta env, We need to have a worker node dedicated for the test operator. Thus we can ensure that test pods won't be affected by the failures.
Running disruptive tests is part of HA testing of the system. Please see OSPRH-7602
Reviewed-by: Andrew Bays [email protected]
Reviewed-by: John Fulton [email protected]

Reviewed-by: Andrew Bays <[email protected]>
@tosky
Copy link
Contributor

tosky commented Dec 11, 2024

Please please next time squash all the changes, otherwise the git history becomes complicated to follow. This is a request to the reviewers too.

@abays
Copy link
Contributor

abays commented Dec 11, 2024

Please please next time squash all the changes, otherwise the git history becomes complicated to follow. This is a request to the reviewers too.

Do you mean have Zuul squash everything when it merges, or ask the author to squash their commits?

@tosky
Copy link
Contributor

tosky commented Dec 11, 2024

Please please next time squash all the changes, otherwise the git history becomes complicated to follow. This is a request to the reviewers too.

Do you mean have Zuul squash everything when it merges, or ask the author to squash their commits?

I would be more for "have the author present a clean history", as there may be cases where the original commits need to be preserved. But that's up to you.

@gmarcian
Copy link
Contributor Author

@tosky Ack. Can it be done from the github PR GUI?

@tosky
Copy link
Contributor

tosky commented Dec 11, 2024

@tosky Ack. Can it be done from the github PR GUI?

I'll leave the answer to others who know the github GUI, but I would say: no. Better rebase locally, you have more control (the operation is a local rebase of the history): https://about.gitlab.com/blog/2020/11/23/keep-git-history-clean-with-interactive-rebase/ (yes, the article is from gitlab.com, but it describes the step to execute with the git CLI tool).

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.

4 participants