| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-16 | |||
| 08:30:46 | alexey_weyl | gmann: meanning, Vitrage don't know what zone was changed, because the previous name doesn't appear. | |
| 08:30:48 | alex_xu | gmann: not like config opt | |
| 08:34:11 | gmann | alex_xu: yea | |
| 08:34:51 | gmann | alexey_weyl: humm, yea name change, changes the AZ completely | |
| 08:35:47 | alexey_weyl | gmann: so how can Vitrage know which availability zone was changed besides storing a cache of all of the different availability zones? | |
| 08:35:52 | gmann | alexey_weyl: but you can get the old AZ from GET server | |
| 08:36:39 | gmann | alexey_weyl: i mean servers booted with AZ will be having the same | |
| 08:39:30 | alexey_weyl | gmann: do you think I can open a bug that we would like the availability zone to have an ID? | |
| 08:40:30 | alexey_weyl | gmann: but still when Vitrage is doing get all availability zones it won't know what AZ was changed. | |
| 08:40:33 | openstackgerrit | Béla Vancsics proposed openstack/nova master: Reduce code complexity - libvirt/config.py https://review.openstack.org/359879 | |
| 08:40:53 | bauzas | FWIW, I'm personnally opposed to accept the AZ changing its name unless there are no left instances in there | |
| 08:41:03 | bauzas | it's a source of confusion | |
| 08:41:27 | gmann | bauzas: yea me too, alexey_weyl is it much required use case? | |
| 08:41:36 | bauzas | creating an AZ is possibly one of the most important things to make sure | |
| 08:42:05 | bauzas | for example, you can default instances to have an AZ by modifying the config to name the default AZ | |
| 08:42:21 | gmann | AZ is something managed with name so changing name is all if you do not want to deal with old one | |
| 08:42:39 | bauzas | it's also an end-user UX | |
| 08:42:46 | bauzas | meaning that users see the AZs | |
| 08:42:57 | gmann | yea | |
| 08:43:07 | bauzas | when you want to modify a name, then you trample all your users | |
| 08:45:42 | alexey_weyl | bauzas: But shouldn't the AZs have and ID. like for every entity in the Database, that its properties are changed, so we will know whos data was changed by the ID. | |
| 08:46:14 | alexey_weyl | bauzas: gmann: another question, how can I receive update events of the AZ on oslo messaging bus? | |
| 08:46:19 | bauzas | alexey_weyl: AZs are just an aggregate metadata | |
| 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 | |