Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-01-29
15:46:36 mnaser is there any stable cores around to +w this? https://review.openstack.org/#/c/619352/
15:47:07 mriedem jangutter: https://bugs.launchpad.net/nova/+bug/1813789
15:47:08 openstack Launchpad bug 1813789 in OpenStack Compute (nova) "Evacuate test intermittently fails with network-vif-plugged timeout exception" [Medium,Confirmed]
16:08:10 mriedem jaypipes: since melwitt is out this week i replied on https://review.openstack.org/#/c/632904/ for that TooManyDiskDevices API error check
16:08:28 mriedem tl;dr there was already a lot of discussion between myself, melwitt, cdent and edleafe on that 403
16:09:16 mriedem i personally don't care if we change to 409, but i don't really think 400 is correct
16:11:57 cdent yeah, 409 is most correct, but 403 is consistent
16:17:40 efried mriedem: Where's the code that converts ComputeDriver.capabilities into traits on the compute node RP??
16:18:20 mriedem efried: https://review.openstack.org/#/c/538498/
16:18:28 openstackgerrit Balazs Gibizer proposed openstack/nova master: Fup for the bandwidth resource provider series https://review.openstack.org/633776
16:18:32 efried o
16:18:50 efried Why hasn't this merged yet <== because some a-hole -1'd it.
16:19:00 mriedem because i haven't updated it
16:19:05 gibi jaypipes, mriedem: here is the followup fixing comments in patches that are approved https://review.openstack.org/633776
16:19:26 mriedem gibi: ack
16:19:46 efried mriedem: Cool beans, just knew I had seen said code somewhere, but couldn't find it in the master branch. Thanks.
16:21:35 kashyap jangutter: Where do you see the 'run-devstack' taking 30 minutes here: http://logs.openstack.org/80/630980/7/gate/tempest-full/5b6ebba/ara-report/
16:22:12 kashyap jangutter: The one I found actually successfully "FINISHED"
16:22:28 kashyap (Although taking 30 mins & completing are not mutually exclusive.)
16:22:57 jangutter kashyap: in the devstack-tempest.yaml line, click on the "16 Tasks" button to pull them down. The run-devstack : Run devstack task went over 30 minutes.
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: 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

Earlier   Later