| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-16 | |||
| 08:46:51 | bauzas | alexey_weyl: it's not a nova specific object, neither persisted like you think | |
| 08:47:47 | alexey_weyl | bauzas: Let me explain to you our use case in Vitrage, and lets see what can be done. | |
| 08:49:24 | alexey_weyl | bauzas: In Vitrage we have many entities of different projects in Openstack and physical entities as well that Vitrage monitors and shows to the user and to the system as well so all the alarms and the root cause alarms in the system can be shown. | |
| 08:50:04 | alexey_weyl | bauzas: Thus, when a user changes the AZ name, it needs to be reflected in the Vitrage entity graph that has the AZ vertex in it. | |
| 08:50:40 | openstackgerrit | Béla Vancsics proposed openstack/nova master: Reduce code complexity - libvirt/config.py https://review.openstack.org/359879 | |
| 08:50:46 | alexey_weyl | bauzas: When vitrage receive the updated data from nova about the AZs in nova it doesn't know which AZ was changed or deleted or what has happened. | |
| 08:51:10 | alexey_weyl | bauzas: Thus if the AZ will have and ID Vitrage will know what AZ was changed or deleted. | |
| 08:51:24 | bauzas | alexey_weyl: I'm personnally in favor of not accepting to change the AZ if there are already some instances | |
| 08:51:45 | bauzas | I could write a spec | |
| 08:52:20 | bauzas | so it would mean a behavioural change, but post that microversion, it shouldn't be possible to change an AZ name | |
| 08:52:46 | alexey_weyl | bauzas: Does it sound as a reasonable use case from your side? | |
| 08:53:25 | alexey_weyl | bauzas: didn't quite understoud your last sentence. | |
| 08:54:30 | bauzas | alexey_weyl: lemme rephrase | |
| 08:55:02 | bauzas | alexey_weyl: since the AZ information is just an aggregate metadata that is user-facing, we already have the ID you need | |
| 08:55:19 | gmann | alexey_weyl: "when a user changes the AZ name" user you mean admin/operator right | |
| 08:55:27 | bauzas | changing that metadata value for that specific key is source of confusion, so I'm not in favor of accepting that | |
| 08:55:29 | alexey_weyl | bauzas: of course | |
| 08:55:54 | alexey_weyl | bauzas: so, you have that id already? can we get from somewhere? | |
| 08:56:08 | bauzas | it's just an aggregate... | |
| 08:59:13 | alexey_weyl | bauzas: don't quite understand. what can I do? | |
| 09:00:13 | bauzas | alexey_weyl: do you know https://docs.openstack.org/developer/nova/aggregates.html#availability-zones-azs ? | |
| 09:00:20 | gmann | alexey_weyl: we have id for aggregate not for AZ | |
| 09:01:41 | alexey_weyl | gmann: I am familiar with the ID in the aggregate host. | |
| 09:02:25 | bauzas | alexey_weyl: https://developer.openstack.org/api-ref/compute/?expanded=show-aggregate-details-detail tells you that availability_zone is just a specific metadata key for an aggregate | |
| 09:03:01 | bauzas | alexey_weyl: we're leaking the DB PK on the API unfortunately, but we added an aggregate UUID since 2.41 | |
| 09:03:22 | alexey_weyl | gmann: I understand. | |
| 09:04:10 | bauzas | https://docs.openstack.org/developer/nova/aggregates.html#availability-zones-azs is explaining that AZs are just a conceptual object that Nova doesn't deal with | |
| 09:10:03 | alexey_weyl | I see | |
| 09:10:14 | alexey_weyl | bauzas: I see | |
| 09:10:27 | alexey_weyl | bauzas: Then I have please another question | |
| 09:11:00 | alexey_weyl | bauzas: I saw that when i change the AZ name or the aggregated host name I dont receive any update event on the oslo messaging bus | |
| 09:11:10 | alexey_weyl | bauzas: how can i receive those updates? | |
| 09:11:19 | bauzas | you mean a notification ? | |
| 09:11:25 | alexey_weyl | correct | |
| 09:11:33 | bauzas | because it's an admin operation | |
| 09:11:42 | bauzas | so you are supposed to know what you do | |
| 09:12:17 | alexey_weyl | bauzas: but vitrage needs to get a notification of such a change. | |
| 09:12:36 | bauzas | I'd rather name it a callback... | |
| 09:12:47 | alexey_weyl | bauzas: ok | |
| 09:13:04 | bauzas | alexey_weyl: well, you can propose to add some new notifications | |
| 09:13:16 | alexey_weyl | bauzas: but still, when even an admin changes something we need to get some update that such a thing was done, how can we get it? | |
| 09:13:23 | alexey_weyl | i see | |
| 09:13:33 | bauzas | gibi: do you know if we need a spec for adding notifications? my guts say yes | |
| 09:14:11 | bauzas | johnthetubaguy: ^ | |
| 09:17:52 | gibi | bauzas: so far we went with specless bp for searchlight related additions | |
| 09:18:22 | gibi | Kevin_Zheng: ping, I'm here now | |
| 09:19:12 | bauzas | gibi: good to know | |
| 09:19:12 | Kevin_Zheng | gibi: Ah, Hi, I was going to ask something for notification, but I got it sorted out :) | |
| 09:19:24 | gibi | Kevin_Zheng: OK :) | |
| 09:19:32 | bauzas | gibi: I thought the notification object was somehow needing a consensus before writing the implementation, but okat | |
| 09:20:06 | bauzas | gibi: here, we are talking of sending notifications about aggregate modifications | |
| 09:20:09 | gibi | bauzas, alexey_weyl: yeah, if this is a new non trivial object then I agree that a spec for the data model is a good thing to have | |
| 09:20:29 | bauzas | gibi: do we notify some aggregate-related objects ? | |
| 09:20:32 | openstackgerrit | jichenjc proposed openstack/nova master: Prevent delete cell0 in nova-manage command https://review.openstack.org/433476 | |
| 09:20:32 | bauzas | already I mean | |
| 09:20:59 | gibi | bauzas: yeah, aggregate.create and .delete are both already transformed to versioned format | |
| 09:21:13 | bauzas | so we already emit those ? | |
| 09:21:16 | gibi | bauzas: aggregate.add_host and remove_host are in the pipe | |
| 09:21:22 | gibi | bauzas: yes | |
| 09:21:36 | bauzas | gibi: okay, that's what alexey_weyl was looking for | |
| 09:21:56 | bauzas | he would like to subscribe on aggregate metadata change | |
| 09:21:59 | gibi | bauzas, alexey_weyl: here is the data modell https://github.com/openstack/nova/blob/master/nova/notifications/objects/aggregate.py | |
| 09:22:24 | bauzas | gibi: perfect | |
| 09:22:43 | gibi | bauzas, alexey_weyl: I think metadata is already part of the notification | |
| 09:22:47 | bauzas | so alexey_weyl just needs to have the aggregate update to emit | |
| 09:22:53 | bauzas | gibi: yup | |
| 09:23:25 | bauzas | gibi: is there already a bp for tracking this ? | |
| 09:23:50 | bauzas | AFAICS, a specless BP should be enough given we already have the notification model | |
| 09:23:53 | alexey_weyl | gibi: bauzas: I am not quite familiar with all the internals of nova. | |
| 09:24:06 | gibi | bauzas: the aggregate ones are part of the notification transformation bp | |
| 09:24:13 | gibi | bauzas: as legacy had those as well | |
| 09:24:37 | bauzas | gibi: yeah, but that blueprint is not intended to add *more* notifications, just transform the existing, correct? | |
| 09:24:38 | gibi | bauzas: the metadata update part is something that is not transformed yet | |
| 09:24:59 | gibi | bauzas: we have metadata update legacy notification https://github.com/openstack/nova/blob/master/nova/objects/aggregate.py#L442 | |
| 09:25:01 | bauzas | gibi: lemme verify if we emit legacy notifications | |
| 09:25:07 | bauzas | ah-ah ! | |
| 09:25:26 | gibi | bauzas: so we have to just transform that | |
| 09:25:30 | bauzas | gibi: so alexey_weyl would just need to contribute to the transformation bp | |
| 09:25:44 | gibi | bauzas, alexey_weyl: it seems so, yes. | |
| 09:25:48 | bauzas | perfect | |
| 09:25:57 | alexey_weyl | bauzas: gibi: I didn't quite understood all what you said. can you please summerize that for me? what do I need to do? | |
| 09:26:02 | bauzas | alexey_weyl: so, your problem is solved from a nova perspective | |
| 09:26:12 | gibi | alexey_weyl: sure | |
| 09:26:21 | bauzas | alexey_weyl: as gibi said, we already emit notifications on aggregate update | |
| 09:26:26 | bauzas | https://github.com/openstack/nova/blob/master/nova/objects/aggregate.py#L442 | |
| 09:26:47 | bauzas | alexey_weyl: the thing is, we emit the information on a non-versioned dict | |
| 09:27:04 | gibi | alexey_weyl: we are creating a new notification interface for nova, to have a proper interface. these are called versioned notifications. | |
| 09:27:13 | bauzas | alexey_weyl: so gibi is the lead for transforming our legacy payloads into a richer format | |
| 09:27:17 | alexey_weyl | bauzas: gibi: I am listening to all of the notifications from nova and I didn't see any notification from nova when I changed the name of the AZ or the Aggregated host | |
| 09:27:40 | gibi | alexey_weyl: do you listen to notifications topic? | |
| 09:27:45 | alexey_weyl | yes | |
| 09:28:01 | alexey_weyl | we have added to notification topics a vitrage_notificcation | |
| 09:28:02 | bauzas | https://github.com/openstack/nova/blob/master/nova/objects/aggregate.py#L443 is the notification name | |
| 09:28:10 | gibi | alexey_weyl: hm, you should get aggregate.updatemetadata.end notification | |
| 09:28:11 | alexey_weyl | and thus we can receive all the data | |
| 09:28:17 | openstackgerrit | Béla Vancsics proposed openstack/nova master: Reduce code complexity - libvirt/config.py https://review.openstack.org/359879 | |
| 09:28:41 | alexey_weyl | bauzas: gibi: I will check it again just to make sure. | |
| 09:28:44 | bauzas | in theory, that notification has a payload including the metadata that changed https://github.com/openstack/nova/blob/master/nova/objects/aggregate.py#L423 | |
| 09:29:01 | gibi | alexey_weyl: if you not see that after updating metadata of an aggregate then we have some bug | |
| 09:29:22 | gibi | alexey_weyl: I will try to verify that as well | |