| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-16 | |||
| 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 | |
| 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 | |
| 09:34:44 | alexey_weyl | gibi: bauzas: I have checked it again, and I didn't receive any notification about AZ and Aggregated host when changed their names | |
| 09:35:14 | gibi | alexey_weyl: do you get aggregate.create when you create a new aggregate? | |
| 09:35:15 | bauzas | alexey_weyl: and what if you change a metadata key that is *not* availability_zone ? | |
| 09:36:31 | alexey_weyl | gibi: bauzas: When i add, delete, update instances I receive all the notification. | |
| 09:37:04 | alexey_weyl | gibi: bauzas: maybe it is related to the fact that I perform the changes in the horizon admin tab? | |
| 09:37:29 | alexey_weyl | gibi: bauzas: I will try to create a new aggregated host via cli | |
| 09:37:44 | gibi | alexey_weyl: I think horizon should not be the problem | |
| 09:39:03 | alexey_weyl | gibi: bauzas: Ok, have created a new aggregated using the cli and i see it in the horizon but I didn't receive any upate | |
| 09:40:52 | gibi | alexey_weyl: strange | |
| 09:41:50 | gibi | alexey_weyl: did you check the notification from vitrage logs? doesn't vitrage filter on event_type? | |
| 09:42:27 | alexey_weyl | I have checked, I have put a print before the filtering | |
| 09:42:47 | alexey_weyl | gibi: I have checked, I have put a print before the filtering | |
| 09:44:33 | alexey_weyl | gibi: bauzas: | |
| 09:44:46 | alexey_weyl | gibi: bauzas: I might know the problem | |
| 09:44:50 | gibi | alexey_weyl: I set the notification driver to log in nova.conf and created an aggregate | |
| 09:44:55 | gibi | alexey_weyl: and I got the log: | |
| 09:44:56 | gibi | alexey_weyl: /var/log/nova/nova-api.log:2017-03-16T10:43:00.616385+01:00 cic-3 nova-api[22020]: 2017-03-16 10:43:00.615 22020 INFO oslo.messaging.notification.aggregate.create.start [req-0b7f199d-8d06-4d2c-bcd6-fc5a8d03b623 ad400a8540f744b5b7041a356d51b6f3 a21d93baeb5e42c8a9d1da782279e309 - - -] {"event_type": "aggregate.create.start", "timestamp": "2017-03-16 09:43:00.615696", "payload": {"name": "gibi-aggregate"}, "priority": "INF | |
| 09:45:05 | gibi | alexey_weyl: but this is Mitaka version | |
| 09:45:12 | alexey_weyl | gibi: bauzas: The productive system I work on is liberty. This might be the problem, right? | |
| 09:45:43 | gibi | alexey_weyl: the legacy aggregate.create works for me on Mitaka | |
| 09:45:50 | gibi | alexey_weyl: let me check Liberty... | |
| 09:46:27 | bauzas | FWIW https://blueprints.launchpad.net/nova/+spec/az-block-name-update | |
| 09:46:45 | gibi | alexey_weyl: Liberty code also has the notification https://github.com/openstack/nova/blob/liberty-eol/nova/objects/aggregate.py#L126 | |
| 09:47:03 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add PCIWeigher https://review.openstack.org/379524 | |
| 09:47:19 | alexey_weyl | gibi: bauzas: ok, now it is really weird. | |
| 09:48:36 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add PCIWeigher https://review.openstack.org/379524 | |
| 09:48:37 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Prefer non-PCI host nodes for non-PCI instances https://review.openstack.org/379625 | |