| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-11 | |||
| 18:58:29 | dansmith | well, I dunno, given where we are, tags on the devices we add seems like a reasonable thing to me | |
| 18:58:42 | dansmith | especially given that there are some devices for which there is no service to talk to | |
| 18:58:46 | dansmith | like a raw pci device | |
| 18:59:15 | mordred | wouldn't that raw pci device be there at boot? or be a thing you added to the vm via nova? | |
| 18:59:16 | dansmith | if cinder gives us the serial number of the block device that we're going to add or something, then I guess we can do the same for cinder, | |
| 18:59:22 | dansmith | but otherwise that's a problem | |
| 18:59:43 | mordred | I mean - I hear you | |
| 18:59:45 | dansmith | mordred: what does it matter if it was there at boot? | |
| 19:00:04 | mordred | if it's there at boot, it can have data in config-drive without any issues | |
| 19:00:23 | mordred | the static nature of config-drive and dynamic devices was the issue | |
| 19:00:34 | dansmith | sure, I thought we were talking about not needing metadata at al | |
| 19:00:38 | mordred | oh golly no | |
| 19:00:41 | mordred | metadata is great | |
| 19:00:43 | dansmith | cinder doesn't show me a device serial number or aything, | |
| 19:00:51 | dansmith | so not sure that I can do the same correlation inside the guest for it | |
| 19:00:57 | mordred | well, mounting volumes is hard no matter what | |
| 19:01:09 | mordred | because how they're presented to the guest varies by hypervisor | |
| 19:01:22 | mordred | and the api can lie to you about the device name | |
| 19:01:24 | dansmith | well, same for nic, except we have an address in the case of ethernet | |
| 19:01:39 | mordred | dansmith: WHAT ABOUT TOKEN RING??? | |
| 19:01:47 | dansmith | mordred: indeed, what about token ring indeed, | |
| 19:01:55 | dansmith | but while you say that, | |
| 19:02:04 | dansmith | there are definitely requests for weird custom L2 things | |
| 19:02:15 | mordred | oh, I'm sure there are | |
| 19:02:15 | dansmith | at which I laugh, but.. | |
| 19:03:13 | mordred | so ... my world view has given up on magical agents sitting inside of guests looking for metadata updates to automagically reconfigure themselves | |
| 19:03:20 | mordred | that might color my opinion on how these things should work | |
| 19:03:41 | dansmith | well, in that case you don't really need instance creds, right? | |
| 19:03:56 | mordred | having systems that sit outside of the guests, that konw what's going on and that can reach in and execute commands in the guests works much better in my world so far | |
| 19:04:03 | mordred | dansmith: that is correct, I do not | |
| 19:04:23 | dansmith | anyway, I just think that being consistent about how you plumb things at boot or after boot requires metadata, and I like configdrive for that for all cases other than that it can't be updated after boot | |
| 19:04:25 | mordred | however, if instance creds are there, then in-instance things have access to the same power I have while sitting outside of the guest | |
| 19:04:36 | mordred | dansmith: ++ | |
| 19:04:57 | mordred | and I'd like more metadata - especially in cases where our current metadata is missing or lies | |
| 19:05:07 | mordred | "this is the volume you named bob" | |
| 19:05:07 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Idempotent PUT /resource_classes/{name} https://review.openstack.org/448791 | |
| 19:05:19 | dansmith | mordred: right and we have that now, but only at boot for configdrive | |
| 19:05:23 | dansmith | the volume thing I mean | |
| 19:05:32 | dansmith | because we can generate that data only in the hypervisor driver | |
| 19:05:39 | mordred | dansmith: we ALSO have the volume thing in libvirt with device names | |
| 19:05:48 | dansmith | and because it's virt-specific, we only show that to the guest not the external API | |
| 19:05:59 | dansmith | mordred: not with volume tags which we now have | |
| 19:06:12 | dansmith | mordred: now you get a metadata blob that says "your vdb IS the volume you tagged as foo" | |
| 19:06:37 | mordred | and that tag does't show up in /dev/disk? | |
| 19:06:53 | dansmith | meaning /dev/disk/by-tag/? | |
| 19:07:05 | mordred | yah | |
| 19:07:07 | dansmith | something in the guest would have to do that for us, of course | |
| 19:08:10 | mordred | we get labels for normal cinder volumes now though - but I guess a disk can only have one lable and could have many tags | |
| 19:08:27 | dansmith | we get labels if they lay a filesystem down, right? | |
| 19:08:57 | mordred | we get a by-$something thathas the volume name in somewhere - one sec, lemme find the thing I'm talking about | |
| 19:09:35 | dansmith | I don't think so | |
| 19:09:46 | dansmith | that would be by-label, and if they put a filesystem in and labeled it | |
| 19:10:13 | dansmith | or are you talking about the virtio-$neutered_uuid ? | |
| 19:12:04 | mordred | dansmith: ok. I think I may just be smoking crack | |
| 19:12:11 | dansmith | I would totally believe that | |
| 19:12:13 | dansmith | :) | |
| 19:12:30 | mordred | dansmith: it's 19:12 UTC, which everyone knows is crack-o'clock | |
| 19:12:38 | dansmith | obvi | |
| 19:16:27 | mordred | of course! | |
| 19:16:40 | mordred | dansmith: is there some other type I should know about? | |
| 19:16:54 | dansmith | mordred: nah, stick to the safe stuff | |
| 19:18:56 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Deprecate CONF.api.allow_instance_snapshots https://review.openstack.org/455100 | |
| 19:27:42 | openstackgerrit | Mathieu Gagné proposed openstack/nova-specs master: Nova support for attached volume extend https://review.openstack.org/453272 | |
| 19:35:09 | mgagne | gibi: mriedem asked me to ask you about your input/opinion on notification impact on this proposed spec: https://review.openstack.org/#/c/453272/ | |
| 19:35:23 | mgagne | gibi: in PS3: "Hmm, this seems like something for which we should send a notification. I don't think we send notifications for any external events that we handle today though. It might be worth talking to gibi about this. I wouldn't block this spec on it, but it seems useful." | |
| 19:39:28 | cfriesen | does anything test with "force_raw_images" set to false, or with glance image formats other than raw/qcow2 ? | |
| 19:41:00 | mriedem | of course not http://codesearch.openstack.org/?q=force_raw_images&i=nope&repos=nova | |
| 19:41:12 | mriedem | that reminds me, i noticed we don't test with that as False once | |
| 19:43:51 | cfriesen | it seems to work okay for raw/qcow2, but apparently it doesn't work with a vmdk format image file. (admittedly a qcow2 image with a vmdk backing file is a bit odd, but we don't do anything to prevent it) | |
| 19:45:41 | mriedem | cfriesen: did you mean integration test? because we don't even test that with a unit test | |
| 19:45:55 | mriedem | vmdk with libvirt imagebackend? | |
| 19:46:38 | mriedem | vmdk is all vmware | |
| 19:46:45 | mordred | cfriesen: we do vhd uploads in production | |
| 19:47:19 | mordred | but that's not helpful for gate testing :) | |
| 19:47:48 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add uuid to Service model https://review.openstack.org/453025 | |
| 19:47:49 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add online data migration for populating services.uuid https://review.openstack.org/454899 | |
| 19:48:51 | openstackgerrit | Jay Pipes proposed openstack/nova master: Read Neutron port 'binding_profile' during boot https://review.openstack.org/449257 | |
| 19:49:09 | openstackgerrit | Jay Pipes proposed openstack/nova master: Modify PciPassthroughFilter to accept lists https://review.openstack.org/444946 | |
| 19:49:21 | openstackgerrit | Jay Pipes proposed openstack/nova master: Read Neutron port 'binding_profile' during boot https://review.openstack.org/449257 | |
| 19:53:27 | mriedem | cfriesen: you've got a little unit test failure to fix up in https://review.openstack.org/#/c/447055/ | |
| 19:59:24 | cfriesen | mriedem: okay, will sort it out. I'm putting out customer fires. | |
| 20:00:22 | cfriesen | mriedem: mordred: apparently libvirt/qemu will boot a vmdk-format glance image. | |
| 20:01:31 | mriedem | https://en.wikibooks.org/wiki/QEMU/Images#Image_types | |
| 20:02:01 | mriedem | i don't see ploop in that list | |
| 20:02:16 | mordred | cfriesen: fascinating | |
| 20:03:04 | cfriesen | I have a report that it boots up, but then fails when we try to live-migrate the instance. | |
| 20:03:26 | cfriesen | I'll raise a bug once we have the info nailed down a bit more securely | |
| 20:03:50 | mriedem | please include customer credit card numbers in the bug report thanks | |
| 20:04:00 | cfriesen | wouldn't that be nice. :) | |
| 20:04:26 | cfriesen | not actually expecting it to get fixed, but at least someone else can see the bug report and know it's broken. :) | |
| 20:07:21 | jaypipes | wait, mriedem, your customers pay you? | |
| 20:07:53 | mriedem | i don't have customers | |
| 20:08:47 | d9k | is there any code for different components to share locks?, i dont see anything | |
| 20:09:29 | d9k | also oslo, which uses fasteners does not have any code for shared locks either | |
| 20:10:26 | d9k | i posted earlier about a race nova and neutron introduce with iptables and ipsets, both need to acquire shared locks from each other | |
| 20:11:06 | sdague | d9k: there is no mechanism for that today, is there an open bug on that issue? | |
| 20:16:54 | d9k | no not yet, acquiring neutron-ipset lock in the iptables-save/restore bit fixes https://ptpb.pw/16S8, but https://ptpb.pw/aukQ needs locks too | |
| 20:19:59 | mriedem | http://forumtopics.openstack.org/cfp/details/11 | |
| 20:21:51 | d9k | also this happens fairly often when running tempest compute.servers | |
| 20:30:13 | sdague | d9k: a bug with details would be good, sounds like you've done a lot of the debugging, and it would be great to get all those details down | |