| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-01-29 | |||
| 16:28:17 | kashyap | Just that it's annoying to wake up each morning to see that thing time out. | |
| 16:28:32 | jangutter | kashyap: the sarlacc pit is slow, but thorough. (plagiarizing and butchering jaypipes). | |
| 16:28:37 | openstackgerrit | Adrian Chiris proposed openstack/nova master: Add free for claimed, allocated devices https://review.openstack.org/616120 | |
| 16:28:37 | openstackgerrit | Adrian Chiris proposed openstack/nova master: Allow per-port modification of vnic_type and profile https://review.openstack.org/607365 | |
| 16:28:38 | openstackgerrit | Adrian Chiris proposed openstack/nova master: Add get_instance_pci_request_from_vif https://review.openstack.org/619929 | |
| 16:28:38 | openstackgerrit | Adrian Chiris proposed openstack/nova master: SR-IOV Live migration indirect port support https://review.openstack.org/620115 | |
| 16:28:40 | mriedem | gibi: regarding the microversion for move operations comment in https://review.openstack.org/#/c/630722/ i replied that i don't think we have to make that decision at that point in the series | |
| 16:28:58 | kashyap | jangutter: Hehe | |
| 16:29:51 | jangutter | kashyap: you'll see the tempest tests above that line have got times attached. Not sure if you could also grab them from the testr results, but chances are one of them is a candidate for the -slow set. | |
| 16:30:57 | jangutter | kashyap: I did see your review seems to have hit _different_ snags in the gate each time, so congratulations on being kind of a lightning rod. | |
| 16:31:27 | kashyap | jangutter: Yeah, I see some of the network tests are taking terribly long (test_server_connectivity_reboot) | |
| 16:32:02 | jangutter | kashyap: a heck of a lot of neutron and keystone reviews are getting booted because of what seems to be a sudden tightening up of pep8 enforcement. | |
| 16:32:06 | kashyap | jangutter: Yep, mumble-mumble something about "good deeds". | |
| 16:33:37 | kashyap | jangutter: I see, thanks for the info. | |
| 17:23:20 | stephenfin | Nice docs patch here if anyone fancies taking a look https://review.openstack.org/#/c/626931 | |
| 17:31:18 | kashyap | stephenfin: Yes, that's an important point easy to miss. | |
| 17:32:49 | kashyap | +1ed, FWIW. | |
| 17:36:15 | openstackgerrit | Merged openstack/nova master: libvirt: A few miscellaneous items related to "native TLS" https://review.openstack.org/630980 | |
| 17:36:24 | openstackgerrit | Merged openstack/nova master: docs: Update references to "QEMU-native TLS" document https://review.openstack.org/631283 | |
| 17:41:24 | jangutter | hehehe, kashyap, another timeout http://logs.openstack.org/59/624959/5/gate/tempest-full/ce2253e/job-output.txt.gz#_2019-01-29_17_20_17_952753 but looks like your reviews got merged! | |
| 17:42:01 | kashyap | Very bizarre | |
| 17:42:08 | kashyap | But I won't complain | |
| 17:42:27 | kashyap | That's a good excuse to go cook some dinner. | |
| 17:43:17 | kashyap | jangutter: The difference is time-out was not in the _same_ job ("tempest-full"), which succeeded this time. | |
| 18:10:19 | openstackgerrit | Jack Ding proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.openstack.org/621646 | |
| 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 | |