| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-01-29 | |||
| 16:23:20 | kashyap | jangutter: Right, there the status of 'run-devstack' task is "CHANGED". | |
| 16:23:29 | jangutter | kashyap: if you click on the parameters for the plays, you'll also see "timeout 30" | |
| 16:24:27 | kashyap | jangutter: Right, there I see it's 30 mins. And when I click on its 'Status' ("CHANGED" - what does it even mean), the job finished. | |
| 16:24:39 | kashyap | So I don't see any action item there. | |
| 16:24:42 | jangutter | kashyap: the playbook was interrupted, so the ARA results are inconsistent | |
| 16:24:47 | kashyap | Hmm | |
| 16:25:08 | kashyap | Just want to put this change out of its misery; it's been in time-out/recheck hell for 9 days | |
| 16:26:54 | jangutter | kashyap: http://logs.openstack.org/80/630980/7/gate/tempest-full/5b6ebba/job-output.txt.gz#_2019-01-29_00_14_28_138371 <--- this Ansible telling you the play timed out. | |
| 16:27:19 | kashyap | Ah, _there_ is the specific piece of hay in the haystack! | |
| 16:27:30 | jangutter | kashyap: is the recheck still in the gate? | |
| 16:27:39 | kashyap | Yeah, 8 hours and running. | |
| 16:28:03 | kashyap | Or something like that. But it doesn't bother me much, I've got a more than a few irons in the fire. | |
| 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 | |