-
Notifications
You must be signed in to change notification settings - Fork 7
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
Follow-up changes for WatcherAPI from PR 13 #26
Follow-up changes for WatcherAPI from PR 13 #26
Conversation
Build failed (check pipeline). Post https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/38cd80d695ca4a0b8e37128417e32d39 ✔️ noop SUCCESS in 0s |
c006fd8
to
0b8f99e
Compare
@@ -4,3 +4,4 @@ metadata: | |||
name: watcherapi-kuttl | |||
spec: | |||
databaseInstance: "openstack" | |||
secret: "osp-secret" |
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.
Given that the idea is that Watcher will create a secret with the minimum set of information required for the watcherapi, watcherdecisionengine and watcherapplier, we should use a different secret for watcherapi that the top level osp-secret this in kuttl tests containing only the required parameters instead of the entire osp-secret.
Also, in future, watcherapi may need some parameters which are not included in osp-secret.
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.
do you think it would be better to create some temporary secret in the kuttl tests and use that? By the time we integrate all the CRs into watcher we'll need to modify all these tests anyway
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, that was my idea. That would also help us when creating the integration between first level watcher and sub-CRs to identify what information should be included in the secret provided from Watcher to WatcherAPIs and the rest.
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.
ack, makes sense to be explicit, let me update the PR with the change
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.
done, kuttl tests are passing locally, let's see if CI is green as well
1a36fe9
to
11c9b64
Compare
Build failed (check pipeline). Post https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/f8bfb1c8c3d045c98a436aa4910f9656 ✔️ noop SUCCESS in 0s |
recheck |
/lgtm |
11c9b64
to
12569a2
Compare
/lgtm |
Following the review on PR 13, there were a few changes suggested. This PR does 2 of them: 1. Make the Secret field on the Spec required, and remove the default from WatcherAPI. This means that the field is no longer shared between the Watcher and WatcherAPI kinds. 2. Add more functional tests to test scenarios where the secret or database are not present. To test the change 1, this commit also changes the watcherapi kuttl test to explicitely create a Secret, mimicking what we'll later do via the Watcher controller.
12569a2
to
52053cb
Compare
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: raukadah 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 |
/lgtm |
eceb232
into
openstack-k8s-operators:main
Following the review on PR 13, there were a few changes suggested. This
PR does 2 of them:
Make the Secret field on the Spec required, and remove the default
from WatcherAPI. This means that the field is no longer shared
between the Watcher and WatcherAPI kinds.
Add more functional tests to test scenarios where the secret or
database are not present.
Related: OSPRH-11483