| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-16 | |||
| 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 | Kevin_Zheng | gibi: Ah, Hi, I was going to ask something for notification, but I got it sorted out :) | |
| 09:19:12 | bauzas | gibi: good to know | |
| 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 | bauzas | already I mean | |
| 09:20:32 | openstackgerrit | jichenjc proposed openstack/nova master: Prevent delete cell0 in nova-manage command https://review.openstack.org/433476 | |
| 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 | |
| 09:30:05 | gibi | alexey_weyl: btw, do vitrage plans to move from the legacy nova notifications to the versioned ones? | |
| 09:31:48 | bauzas | gibi: AFAICS, if you do the WSGI action on os-aggregates to set_metadata, you call the Aggregate object method that emits the legacy notification | |
| 09:31:58 | bauzas | https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/aggregates.py#L196 | |
| 09:32:34 | bauzas | and https://github.com/openstack/nova/blob/master/nova/compute/api.py#L4490 | |
| 09:32:50 | alexey_weyl | gibi: I have to admit that this is the first time I hear about that, so I will need to check it out. But if this is something that all the projects have then vitrage will have to use such the new notifications | |
| 09:33:31 | gibi | alexey_weyl: we are in the process to define and implement the new interface so it is the good time to chime in from consumer side | |
| 09:33:44 | gibi | bauzas: that is my understanding of the code as well | |
| 09:34:17 | gibi | bauzas: but if alexey_weyl does not see the notification then there is something we don't see | |