| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-06-14 | |||
| 14:35:47 | sdatko | mriedem: in nova.db.sqlalchemy.api i have function that returns model_query(context, models.Instance.instancE_typE_id).filter(models.Instance.host == host).filter(models.Instance.deleted == 0).distinct(models.Instance.instance_type_id).all() | |
| 14:35:53 | mriedem | gibi: ah this https://review.openstack.org/#/c/453077/ | |
| 14:36:13 | gibi | mriedem: there are actions with specific payload like https://github.com/openstack/nova/blob/master/nova/notifications/objects/instance.py#L121 | |
| 14:36:40 | mriedem | gibi: this is what i was thinking of https://review.openstack.org/#/c/453077/2/doc/notification_samples/instance-snapshot-end.json@71 | |
| 14:36:45 | sdatko | and it seems to work; however, i am trying to write unit test for that, but i receive "oslo_db.exception.DBNonExistentTable: (sqlite3.OperationalError) no such table: instances" | |
| 14:36:48 | mriedem | we added a more specific payload, | |
| 14:36:53 | mriedem | and i was checking to see what we did with the version | |
| 14:37:03 | mriedem | so that we are being consistent with InstanceCreatePayload | |
| 14:37:18 | gibi | mriedem: ahh I see. You are askin about the version number | |
| 14:37:23 | mriedem | yes | |
| 14:37:29 | mriedem | i want to be consistent when we rename payloads | |
| 14:37:36 | mriedem | consistent in what we do about the version i mean | |
| 14:37:40 | mriedem | does it stay the same or increment | |
| 14:37:51 | openstackgerrit | Maciej Kucia proposed openstack/nova-specs master: WIP Extended PCI alias https://review.openstack.org/474218 | |
| 14:38:03 | mriedem | gibi: looks like it's being consistent and not incrementing the version https://review.openstack.org/#/c/453077/9/doc/notification_samples/instance-snapshot-end.json | |
| 14:38:37 | gibi | mriedem: in case of snapshot_id we did increase as not just renamed the class but added the new field | |
| 14:38:42 | Kevin_Zheng | mriedem gibi I will ask for detailed usecase and see if it is persuasive enough | |
| 14:38:48 | gibi | mriedem: but in the create case we had a separate patch to rename | |
| 14:39:01 | gibi | mriedem: so there we kept the version | |
| 14:39:02 | mriedem | gibi: then isn't this wrong? https://review.openstack.org/#/c/453077/9/doc/notification_samples/instance-snapshot-start.json@72 | |
| 14:39:06 | openstackgerrit | Maciej Kucia proposed openstack/nova-specs master: WIP Extended PCI alias https://review.openstack.org/474218 | |
| 14:39:06 | mriedem | shouldn't that be 1.3? | |
| 14:39:28 | gibi | mriedem: yes, that is wrong | |
| 14:39:39 | mriedem | cool :) | |
| 14:39:41 | mriedem | -1! | |
| 14:39:54 | mriedem | Kevin_Zheng: thanks | |
| 14:39:54 | gibi | mriedem: thanks for founding it :) | |
| 14:41:09 | mriedem | sdatko: is this for something you're planning on contributing to nova in the community? or just working on separately downstream? because if it's the latter, i don't really have time to help with forking nova. | |
| 14:41:39 | gibi | mriedem: I will be more explicit in the https://review.openstack.org/#/c/453667/ as well about keeping the same version in case of pure rename and bumping it if also content is changed in the same step | |
| 14:42:08 | mriedem | gibi: ok i was going to ask that we document this in the devref | |
| 14:42:56 | sdatko | mriedem: nothing very important, i am just trying to get into Nova | |
| 14:44:07 | sdatko | playing on DevStack :-) Ok, maybe some other time | |
| 14:44:15 | sdatko | thanks! | |
| 14:44:45 | mriedem | sdatko: ok, i figured with the types of questions you're asking you are trying to implement some out of tree feature | |
| 14:45:20 | mriedem | sdatko: ultimately it depends on your use case, but i think if you're just trying to figure out which flavors are being used on which hosts, that can all be done via the REST API / client side tools | |
| 14:45:40 | mriedem | if you're working on a scheduler filter or something like that, then it's a different story | |
| 14:49:53 | kashyap | mriedem: Forgot to respond here, as I was asleep - about your persistent domain question | |
| 14:50:02 | kashyap | mriedem: But you answered yourself, and you were right | |
| 14:50:58 | mriedem | kashyap: yeah now just need to know why it takes 5 minutes to remove an ethernet interface device from a guest | |
| 14:51:12 | mriedem | was hoping danpb could help with some of that | |
| 14:51:17 | kashyap | mriedem: That sounds like an awful lot of time | |
| 14:54:13 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: explain payload inheritance in notification devref https://review.openstack.org/453667 | |
| 14:54:13 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add snapshot id to the snapshot notifications https://review.openstack.org/453077 | |
| 14:54:31 | gibi | mriedem: Fixed the versioning problem in the snapshot_id patch ^^ | |
| 14:54:45 | mriedem | kashyap: cool, comments 14 and on are the details https://bugs.launchpad.net/nova/+bug/1696125 | |
| 14:54:45 | openstack | Launchpad bug 1696125 in OpenStack Compute (nova) "Detach interface failed - timeout waiting to detach tap device in linuxbridge job (pike)" [High,Confirmed] - Assigned to Matt Riedemann (mriedem) | |
| 14:54:56 | mriedem | gibi: cool | |
| 14:58:26 | mriedem | gibi: ok +2 on the instance create payload change https://review.openstack.org/#/c/463001/ now | |
| 14:58:44 | gibi | mriedem: thanks for the review! | |
| 14:59:42 | gibi | mriedem: and thanks for the feedback on the doc. I will fix it soon | |
| 15:03:35 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Support tag instances when boot(4/4) https://review.openstack.org/469800 | |
| 15:03:43 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: explain payload inheritance in notification devref https://review.openstack.org/453667 | |
| 15:03:48 | mriedem | gibi: ok also some issues in https://review.openstack.org/#/c/453077/ | |
| 15:03:53 | mriedem | d'oh | |
| 15:04:08 | dansmith | dtantsur: is there an easy way to detect that I'm on the primary node or not? | |
| 15:04:16 | dansmith | actually | |
| 15:04:33 | dansmith | we should probably only run this if we're on a node where there is something like nova-api configured, so I'll do that | |
| 15:05:15 | mriedem | dansmith: that's what devstack/stack.sh checks for | |
| 15:05:17 | mriedem | so yeah | |
| 15:05:26 | dansmith | yeah | |
| 15:05:54 | gibi | mriedem: I have to run now, but will get back to the snapshot patch tomorrow morning. thanks again for the review! | |
| 15:06:18 | mriedem | yw | |
| 15:07:40 | mriedem | man we don't even go over conductor for compute_node_statistics | |
| 15:08:22 | dansmith | mriedem: well, it's api only, so we wouldn't | |
| 15:08:24 | dansmith | but no objects yeah | |
| 15:08:52 | dtantsur | dansmith: seems so: https://github.com/openstack/ironic/blob/870d909cc7e0c6118a174d412ae814953bb805e1/devstack/lib/ironic#L377-L384 | |
| 15:09:16 | dansmith | dtantsur: I think checking for n-api is the devstacky way | |
| 15:09:24 | dansmith | dtantsur: just pushed a rev for that | |
| 15:09:40 | dtantsur | thanks, I'll check after a meeting (and probably after Jenkins agrees with it) | |
| 15:09:44 | dansmith | cool, thanks | |
| 15:09:56 | dansmith | I'll be keeping an eye on it too of course :) | |
| 15:10:12 | dansmith | glad we (mriedem) caught this before we landed it and broke ironic this time :) | |
| 15:10:29 | mriedem | \o/ | |
| 15:10:32 | dansmith | heh | |
| 15:17:49 | kashyap | mriedem: Nice sleuthing on comment#16 | |
| 15:18:03 | kashyap | How did you guess it could be related to AppArmour? | |
| 15:18:11 | mriedem | kashyap: i'm not sure that it is, | |
| 15:18:31 | mriedem | kashyap: but we've had those previous bugs where based on the version of libvirt, the script path in the interface xml has to be None or '' | |
| 15:18:44 | mriedem | to tell qemu use the default, which is /etc/qemu-ifup | |
| 15:18:51 | mriedem | and apparmor could be blocking that script | |
| 15:19:03 | kashyap | mriedem: Yeah, just checking with Laine Stump on OFTC network, who mediatates on libvirt networking | |
| 15:20:41 | kashyap | mriedem: Yeah, I recall the script path thing, that's fixed, no | |
| 15:20:42 | kashyap | ? | |
| 15:21:23 | mriedem | it is | |
| 15:21:47 | mriedem | kashyap: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/designer.py#L62 | |
| 15:24:24 | mriedem | jaypipes: are you able to pull out of your bag of lore what the simple difference between disk_available_least and free_disk_gb is? | |
| 15:24:40 | mriedem | because the descriptions on those response parameters in https://developer.openstack.org/api-ref/compute/?expanded=show-hypervisor-statistics-detail#show-hypervisor-statistics is not clear | |
| 15:25:13 | kashyap | mriedem: Laine & DanPB said: Without looking at data from the guest, it's hard to say *where* precisely is the delay lurking | |
| 15:25:13 | jaypipes | mriedem: it's not clear because the implementation/design of it all is unclear... | |
| 15:25:25 | mriedem | jaypipes: plus it depends on backend storage doesn't it? | |
| 15:25:31 | mriedem | e.g. ceph vs others | |
| 15:26:01 | jaypipes | mriedem: disk_available_least is essentially the worst-case scenario whereas free_disk_gb considers sparse disks as not consuming their entire mapping file | |
| 15:26:21 | kashyap | mriedem: Are you able to reproduce this issue? You note a hit in the bug | |
| 15:26:22 | jaypipes | s/mapping/backing | |
| 15:26:34 | mriedem | kashyap: reproduce locally? i haven't tried. | |
| 15:26:43 | kashyap | mriedem: Okay, here's what the folks from #virt say: | |
| 15:26:46 | mriedem | kashyap: we had a recreate in upstream ci which is where i pulled and dug through those libvirtd logs | |
| 15:26:59 | kashyap | 17:19 < danpb> kashyap: suggests the guest OS is not honouring the unplug event promtly | |
| 15:27:02 | kashyap | 17:20 < danpb> kashyap: or perhaps it is honouring it, but something in the guest is waiting 5 minutes for something to happen before offlineing the nic | |
| 15:27:05 | kashyap | 17:20 < danpb> its hard to say for sure without getting data from the guest os really | |