Adds notification bus #958
Conversation
|
Build failed (check pipeline). Post https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/5f2f11473cbd44c4b893856a98532d51 ✔️ openstack-meta-content-provider SUCCESS in 3h 21m 46s |
|
@auniyal61 Please make sure the tests covering expected behavir should be aligned with some changes done to the design spec #948 |
6718736 to
f983edb
Compare
|
Build failed (check pipeline). Post https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/c47bfaa15f3043eeb90b504f3d682cb0 ✔️ openstack-meta-content-provider SUCCESS in 24m 31s |
|
Merge Failed. This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. |
|
Merge Failed. This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. |
|
Merge Failed. This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. |
|
Merge Failed. This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. |
SeanMooney
left a comment
There was a problem hiding this comment.
I have not done a super detailed review but over all this looks ok
the main gap i see is we have not enabled testing in either of the tempest jobs.
it would be nice to do that in a followup.
my main concern is with the condition reporting commented inline.
| - message: Notification message bus not requested | ||
| reason: Ready | ||
| status: "True" | ||
| type: NovaNotificationMQReady |
There was a problem hiding this comment.
is this a bug?
so by default the notificaotn message bus is not passed in.
and i don't think you are enabling it in this test so this condition should not be reported.
it should be skipped and only reported if the notifications are enabled no?
i could be wrong but i belive that is how we handle the conditions for the nova metadata when it runs at the top level vs the cell level.
as long as we are consistent, i don't particularly mind, but i would like to avoid divergence if we can.
There was a problem hiding this comment.
@auniyal61 now these are not in the status any more as in these tests the notifications are not enabled and your new change removes the condition as Sean requested in that case.
| } else { | ||
| instance.Status.Conditions.MarkTrue( | ||
| novav1.NovaNotificationMQReadyCondition, novav1.NovaNotificationMQNotRequestedMessage) | ||
|
|
There was a problem hiding this comment.
i chatted to gibi on slack baout this about and i think this is misleading
it imples the notification bus is deployed when its not in use.
I'm not sure this is enoch to block the current pr but it is not consistent with the nova metadata API conditions which are only reported when they are enabled at the cell or nova level.
There was a problem hiding this comment.
this should also proably be reporeed on the cell contoelr state too.
not just the top level.
i think initally this is configured cluster wide so i guess that is why this is only reporter dat the top level.
but long term we will need to include this in the cell template.
so perhaps per cell reporting is not required until that is addded.
There was a problem hiding this comment.
it imples the notification bus is deployed when its not in use.
I'm fine to make it consistent between metadata and notifications and remove the notification condition form the status if notifications are not enabled
this should also proably be reporeed on the cell contoelr state too.
not just the top level.
Today the TransportURL is created at the top level and there we know when the Rabbit and therefore the TransportURL CR is ready, this is reflected in the condition on the top level. On the cell level we only get a transport_url value in the internal secret so nothing to wait for, what is there just gets included into the cell specific compute config Secret. So from the cell perspective the important conditions are the
- InputReady : are the internal secret available and has the expected keys
- NovaComputeServiceConfigReady: the cell specific compute config secret is created successfully
When we have a cellTemplate specific override (if ever) then we can discuss where to create the TransportURL for that. But note that the cell specific RPC TransportURL is still created on the top level not on the cell level for architectural reasons.
bb8f595 to
73c5768
Compare
|
Thanks for fixing my test nits. Those changes look good. Let me know when you implemented the removal of the condition if notificationsBusInstance is empty. |
1 - human operator will update rabbitmq in openstackcontrolplane CR
a) under rabbitmq: add new rabbitmq, ex: rabbitmq-broadcaster, something like
rabbitmq-broadcaster:
replicas: 1
2 - human operator will update Nova in openstackcontrolplane CR
a) under nova.template.spec: register new rabbit
(as we do for new cell but not inside celltemplate, as this one is top-level)
nova:
template:
spec:
apiContainerImageURL: image_url
apiMessageBusInstance: rabbitmq
// new var
notificationsBusInstance: rabbitmq-broadcaster
in Nova CR instance.Spec.NotificationsBusInstance value
nil : means not mentioned in CR, so disable it.
"" : disable notification
rabbitmq-broadcaster : notification to a bus rabbitmq-broadcaster
3 - nova-operator will recognize notificationsBusInstance and
retrieve transport_url of new rabbit (rabbitmq-broadcaster)
4 - nova-operator will set this transport_url in nova.conf
Closes: OSPRH-15392
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: auniyal61, bogdando, mrkisaolamb The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
SeanMooney
left a comment
There was a problem hiding this comment.
/lgtm
there is one minor testing change that we could do but i think I'm fine to merge this
| mariadb.SimulateMariaDBAccountCompleted(cell0.MariaDBAccountName) | ||
| infra.SimulateTransportURLReady(cell0.TransportURLName) | ||
| SimulateReadyOfNovaTopServices() | ||
| }) |
There was a problem hiding this comment.
we coudl have had an addtional check here to assert that the
novav1.NovaNotificationMQReadyCondition, is not in the list of status conditions.
but that the over all ready condition is true.
|
/unhold |
c71791e
into
openstack-k8s-operators:main
|
/cherry-pick 18.0-fr2 |
|
@bogdando: #958 failed to apply on top of branch "18.0-fr2": DetailsIn 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. |
|
ok, we need #985 to land then retry with cherry picking |
Initial commit - Adds tests for notification bus
how this should work is:
1 - human operator will update rabbitmq in openstackcontrolplane CR
a) under rabbitmq: add new rabbitmq, ex: rabbitmq-broadcaster, something like
2 - human operator will update Nova in openstackcontrolplane CR
a) under nova.template.spec: register new rabbit
(as we do for new cell but not inside celltemplate, as this one is top-level)
3 - now nova-operator will recognize notificationsBusInstance and retrieve transport_url of new rabbit (rabbitmq-broadcaster)
4 - nova-operator will set this transport_url in nova.conf
Jira: OSPRH-15392