Earlier  
Posted Nick Remark
#openstack-nova - 2019-01-29
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: Allow per-port modification of vnic_type and profile https://review.openstack.org/607365
16:28:37 openstackgerrit Adrian Chiris proposed openstack/nova master: Add free for claimed, allocated devices https://review.openstack.org/616120
16:28:38 openstackgerrit Adrian Chiris proposed openstack/nova master: SR-IOV Live migration indirect port support https://review.openstack.org/620115
16:28:38 openstackgerrit Adrian Chiris proposed openstack/nova master: Add get_instance_pci_request_from_vif https://review.openstack.org/619929
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,

Earlier   Later