| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-01-29 | |||
| 18:12:36 | openstackgerrit | Jack Ding proposed openstack/nova master: Improve libvirt image and snapshot handling https://review.openstack.org/616692 | |
| 18:14:26 | openstackgerrit | Jack Ding proposed openstack/nova master: Correct instance port binding for rebuilds https://review.openstack.org/603844 | |
| 18:51:59 | tomtom001 | hello, I am running openstack queens and I am having trouble getting nova instances to boot using emphemeral storage. I have force_raw_images = false and use_cow_images = true for my settings, would these conflict with that? I also have Host aggregates setting ephemeralcomputestorage = false would this cause a problem for the boot process? When my instances boot they just go to "No bootable | |
| 18:52:05 | tomtom001 | device" nova, cinder, and ceph seem to be all functioning correctly. | |
| 18:53:23 | tomtom001 | While I've found documentation for the nova settings, I have not found any for the Host Aggregate settings and how it affects the storage selection. | |
| 19:07:39 | mriedem | ephemeralcomputestorage isn't a special key in nova, | |
| 19:07:55 | mriedem | presumably you're trying to use that to restrict certain flavors or images to that host aggregate and linking it by the ephemeralcomputestorage key | |
| 19:08:20 | mriedem | e.g. https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#aggregateimagepropertiesisolation and https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#aggregateinstanceextraspecsfilter | |
| 19:09:46 | tomtom001 | mriedem: so if I've done that then I wouldn't be able to use ephemeral on our host aggregates with that key set? | |
| 19:10:20 | mriedem | are you trying to boot from volume? | |
| 19:10:47 | mriedem | i don't know where the "no bootable device" error is coming from - libvirt? | |
| 19:11:37 | mriedem | also not sure what you mean by ephemeral storage - do you mean local storage on the compute node? | |
| 19:11:43 | mriedem | i.e. not volume backed | |
| 19:12:24 | tomtom001 | from the console of the instance, showing no bootable device, ephemeral is not local nova disk, just not volume backed. | |
| 19:13:04 | mriedem | sounds like a problem with the image | |
| 19:14:17 | tomtom001 | The same images work if booted with a volume backing. | |
| 19:23:41 | openstackgerrit | Hang Yang proposed openstack/nova stable/rocky: Fix port dns_name reset https://review.openstack.org/633806 | |
| 19:24:16 | openstackgerrit | Hang Yang proposed openstack/nova stable/queens: Fix port dns_name reset https://review.openstack.org/633807 | |
| 19:34:48 | ioni | hello guys | |
| 19:34:52 | ioni | what's the right way to disable out of date images ? | |
| 19:34:59 | ioni | --deactivate or --private or other way? | |
| 19:35:03 | ioni | because now i'm using --deactive and if an instance that is using this image wants to resize, nova returnes and error that the project doesn't have permission to that specific image | |
| 19:35:07 | ioni | the error log: https://paste.xinu.at/b6ZsNA/ | |
| 19:48:46 | jaypipes | ioni: I would do the --private (or --protected + --private) route. | |
| 19:49:29 | ioni | jaypipes, that will prevent having issue with resizing ? | |
| 19:49:36 | ioni | thats what i want to resolve | |
| 19:50:42 | jaypipes | ioni: is your entire goal just to remove the image from the list of images that users see in Horizon or `openstack image list`? | |
| 19:50:55 | ioni | jaypipes, indeed | |
| 19:52:07 | openstackgerrit | Jack Ding proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.openstack.org/621646 | |
| 19:52:08 | jaypipes | ioni: you're on Queens, right? | |
| 19:52:13 | ioni | jaypipes, yes | |
| 19:52:24 | jaypipes | ioni: k. | |
| 19:53:21 | jaypipes | mriedem: if ioni deletes an image will that image still be available for resize operations? I know we continue to store the image metadata for instances but not sure if our resize operation will barf at deleted images or not. | |
| 19:53:55 | jaypipes | ioni: I'm assuming here you're talking about same-original-image resizes, not resize with a different image... | |
| 19:53:58 | ioni | jaypipes, that's mostly the case I didn't want to delete images, i don't know what happens | |
| 19:54:22 | jaypipes | ioni: ack. I'm not entirely sure either, which is why I called out the big guns (mriedem) | |
| 19:54:27 | ioni | jaypipes, openstack image resize, so yes, the same original image | |
| 19:54:38 | ioni | *openstack server resize | |
| 19:54:39 | mriedem | there is no resize with a different image | |
| 19:54:51 | jaypipes | mriedem: ah, sorry, yea, was thinking rebuild. | |
| 19:55:02 | mriedem | i suspect that if you delete the backing image and try to resize it will fail b/c the dest host won't be able to pull down the image | |
| 19:55:03 | ioni | i don't know why is trying to check the original image | |
| 19:55:54 | ioni | i have like 7 images with centos 7, built in various time acros years and some instances are running on old images | |
| 19:56:05 | ioni | i do update images from time to time to include up to date packages | |
| 19:56:24 | ioni | i only want the most up to date image to be available | |
| 19:56:29 | ioni | but also resize to work | |
| 19:58:08 | mriedem | ioni: have you asked the glance folk in #openstack-glance or the operators in #openstack-operators? | |
| 19:58:22 | mriedem | i'm not sure what the difference is between a deactivated image and a deleted image | |
| 19:58:27 | mriedem | https://docs.openstack.org/glance/latest/admin/index.html isn't helping me | |
| 19:58:45 | ioni | mriedem, i didn't ask in there, mostly because nova fails with an error | |
| 19:58:53 | ioni | so i was thinking that's a nova issue | |
| 19:59:17 | mriedem | you could maybe make the image visibility 'shared' and then only grant access to the projects that need access to that image to resize https://developer.openstack.org/api-ref/image/v2/index.html#sharing | |
| 19:59:27 | mriedem | but then it's not public for all projects to use | |
| 19:59:42 | mriedem | and it wouldn't show up in the default image list for those sharing member projects, only the owner (admin i presume) | |
| 20:00:09 | mriedem | anyway seems like a pretty common problem, i'd try #openstack-glance or #openstack-operators | |
| 20:00:13 | mriedem | it's not really a nova issue | |
| 20:00:26 | ioni | ok | |
| 20:00:28 | ioni | thanks | |
| 20:00:37 | mriedem | if you find out some juicy details please report back :) | |
| 20:02:45 | mriedem | https://docs.openstack.org/operations-guide/ops-user-facing-operations.html#deleting-images also isn't very helpful | |
| 20:02:51 | mriedem | "deleting images is fine unless you need to migrate servers" | |
| 20:02:53 | mriedem | :( | |
| 20:03:47 | ioni | so is mostly about driver | |
| 20:04:00 | ioni | or about the storage backend | |
| 20:04:06 | ioni | qcow, raw or other | |
| 20:05:26 | mriedem | well, libvirt is by far the most widely used compute driver, | |
| 20:05:49 | mriedem | if you were using shared instance storage across all of your computes, then the image might be cached and you don't need to fetch it from glance, | |
| 20:05:58 | mriedem | but that's not a deployment strategy that everyone uses | |
| 20:07:27 | mriedem | ioni: btw i'm asking in #openstack-operators | |
| 20:07:52 | ioni | mriedem, yes, i saw, i'm going to continue there | |
| 20:11:04 | mriedem | jaypipes: the answer was change the image status to "community" which hides it from the image list for all users except the owner, but you can reach it by uuid if you know it | |
| 20:11:13 | mriedem | so like shared but less private | |
| 20:18:30 | jaypipes | mriedem: ugh | |
| 20:18:52 | jaypipes | mriedem: that is so very non-obvious. | |
| 20:20:15 | mriedem | at least there is a solution | |
| 20:26:52 | cdent | "at least there is a solution" is the first album from my band "so very non-obvious" | |
| 20:35:26 | artom | I thought My Chemical Romance already did that? | |
| 20:43:53 | cdent | mriedem, jaypipes : can either of you remember the details of what's left on the nova side to make shared disk a possibility? | |
| 20:44:29 | cdent | The reason I ask is because I've been modelling various disk set ups in placement with the usual gabbits things I do, and it works very nicely from that side of things. | |
| 20:52:29 | mriedem | the bug about it has details | |
| 20:52:50 | jaypipes | cdent: mostly I think it's just that nova and the virt drivers simply have no idea that instances use shared storage or not. There needs to be something added to the resource tracker (I had proposed that provider YAML config file for this type of purpose) that communicates to the nova-compute service that the compute node has access to shared storage. | |
| 20:52:51 | mriedem | https://bugs.launchpad.net/nova/+bug/1784020 | |
| 20:52:52 | openstack | Launchpad bug 1784020 in OpenStack Compute (nova) "Shared storage providers are not supported and will break things if used" [Medium,Fix released] | |
| 20:53:18 | mriedem | there are lots of TODOs and FIXMEs in the code with things like "this will need to change to support sharing providers" | |
| 20:53:24 | mriedem | like in the cold migration flow | |
| 20:53:30 | cdent | thanks, I had lost track of that bug | |
| 20:53:43 | mriedem | also L220 https://etherpad.openstack.org/p/nova-ptg-stein | |
| 20:53:53 | jaypipes | cdent: along with a giant-ass reshape-the-world-for-shared-storage function that would "correct" the allocation of resources. | |
| 20:57:02 | cdent | It's looking like shared disk could make multiple datastores in one vsphere cluster way more sensible. nested could also work, but shared will work in both the "this cluster owns this store" and "this store is used by multiple clusters" set ups | |
| 21:05:21 | mriedem | fyi, new pip release of something is destroying pep8 in the gate | |
| 21:06:41 | mriedem | this https://pypi.org/project/pycodestyle/2.5.0/ | |
| 21:11:06 | cdent | joy! | |
| 21:11:20 | cdent | this is the disk playing about I was talking about ^^ https://github.com/cdent/placement-disk-models | |
| 22:04:45 | mriedem | good lord i really dislike the PciDevice* object interfaces | |
| 22:04:51 | mriedem | so different from everything else we have for versioned objects | |
| 22:06:32 | mriedem | burying too much business logic in the data model | |
| 22:06:42 | mriedem | it's that some kind of anti-pattern... | |
| 22:06:45 | mriedem | *isn't that | |
| 22:38:28 | mriedem | dansmith: interesting fun fact of the day: you can't load 'fault' using expected_attrs with Instance.get_by_uuid | |
| 22:40:41 | mriedem | http://paste.openstack.org/show/744212/ | |