Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-18
15:59:29 arvindn05 ahh..ok...will bounce the idea off matt for now :)
16:17:42 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Deduplicate notification samples Rocky - 7 https://review.openstack.org/560748
16:42:02 openstackgerrit Jay Pipes proposed openstack/nova master: mock utils.execute() in qemu-img unit test https://review.openstack.org/562339
16:44:27 cfriesen melwitt: had a thought on bug 1764556. If we deleted the compute node, recreated it, and migrated the instance back prior to the upgrade to Pike I think we could end up with the DB in the problem state. On the other hand, that seems like a pretty unlikely scenario.
16:44:27 openstack bug 1764556 in OpenStack Compute (nova) ""nova list" fails with exception.ServiceNotFound if service is deleted and has no UUID" [Undecided,Fix released] https://launchpad.net/bugs/1764556
16:47:50 melwitt cfriesen: what would be the full sequence there? sorry, I forgot what the original sequence was regarding deleting of the service, migration, re-create service, migrate etc
16:48:24 cfriesen melwitt: boot instance, migrate instance, delete compute node, create new compute node with same name, migrate instance to new compute node, upgrade to pike
16:50:49 melwitt okay. does seem unlikely but I wouldn't be surprised if someone someday would happen to do it
16:54:04 cfriesen melwitt: our local solution is to modify the online data migration in pike to put uuids on deleted services
16:54:30 openstackgerrit Merged openstack/os-vif master: Add lower-constraints job https://review.openstack.org/556056
16:55:32 melwitt ack
16:56:24 phuongnh hi all, I would like to add one more line in file https://review.openstack.org/#/c/462759/3/os_traits/hw/cpu/x86.py for CPU_FPGA
16:56:44 phuongnh the link to this cpu type is: https://en.wikipedia.org/wiki/Field-programmable_gate_array
16:56:51 bmace does anyone know or have any pointers to why stable/queens global-requirements is pinned to version 9.1 of python-novaclient when 10.1 seems to be the queens version of python-novaclient from what I can see?
16:56:56 phuongnh Do I need to propose a blueprint in launchpad?
16:57:45 melwitt jaypipes: what's the procedure for proposing a new cpu type to os-traits? ^
16:58:28 jaypipes phuongnh: that's not a CPU type.
16:58:48 jaypipes melwitt: the procedure to add any trait is simply to propose a patch to os-traits.
16:58:57 jaypipes melwitt: the issue here is that CPU_FPGA isn't a trait.
16:59:15 melwitt thanks
16:59:27 phuongnh thanks jaypipes
17:01:28 melwitt bmace: I think there was a problem with 10.1 not working with queens openstackclient. I have to look to see where/how that was noted (probably in some review somewhere)
17:02:46 bmace melwitt: if you have more info or it was just certain projects that would be very helpful. i think without it there are some issues getting multi-attach to work correctly through heat.
17:04:40 melwitt bmace: okay, let me look into it and get back to you. I think mriedem might be able to point to some details about it but he's not around at the moment
17:05:14 bmace melwitt: sure thing, thanks very much for your time looking into it.
17:24:20 openstackgerrit sahid proposed openstack/nova master: compute: introduce cpu_shared_set option https://review.openstack.org/561912
17:48:29 cfriesen melwitt: bmace: I think this might be it: https://review.openstack.org/#/c/538070/
17:49:18 melwitt cfriesen: looks like it, thank you
17:50:32 bmace cfriesen: melwitt: thanks much. interesting comment from matt. i'm pretty sure there are issues with multi-attach through heat not working without the 10.x novaclient
17:51:12 melwitt yeah, I'm wondering what in 10.0.0 is required for multi-attach
17:53:19 bmace melwitt: i'll chat with the person that was investigating the issue and get some more details. i think i recall it being at least in part related to the microversion or some such.
17:55:18 melwitt bmace: okay. yeah, the client itself has a version range it supports, maybe that's the missing piece. the microversion needed for multi-attach might have been added in 10.0.0, so even though there might not be anything else special in the client needed about it, the fact that 9.1.1 can't send the required microversion could break it. we have to look at it
17:55:54 bmace melwitt: i think that was the issue, and from what i recall the microversion may not have been right until 10.1
17:56:36 melwitt guh, okay. I'm not immediately sure what we can do about this. I'm not sure if we could just bump the microversion in a 9.1.2 to deal with this
17:57:23 bmace right, and trying to bump up the global-requirement to 10.1 back in stable queens might be a bigger change than people are comfortable with.
17:58:04 melwitt yeah. I don't know the details around why osc couldn't work with 10.1.0 and what it would take to make it work. or the other way around, how we could get 10.1.0 to work with osc
17:58:15 melwitt but that's another angle to look at
17:58:49 bmace from what i saw in the review it seemed like the only reason the requirement wasn't approved was because matt said it wasn't needed?
17:59:25 bmace oh, nevermind, reading through that link to the january mailing list now where there was some reported breakage
17:59:35 melwitt yeah
18:01:04 melwitt from the comments, it sounds like it's fixable, just that it wasn't going to make it in time for queens and also it was thought nothing requires >= 10.0.0 in queens
18:01:22 melwitt *fixing osc wasn't going to make it in time for queens
18:02:04 melwitt but if the latter isn't really true, we could fix it, AFAIK
18:03:03 bmace sure, it comes down to how much people actually want multi-attach to work in queens.
18:03:13 melwitt fix osc, release osc, bump the queens requirement. I want to check with mriedem to see if that's the best way forward or if there's another solution
18:03:34 bmace sounds good, thanks again.
18:03:41 melwitt we definitely want multi-attach to work in queens. just a matter of how to go about fixing it
18:04:04 melwitt thanks for letting us know about this problem
18:04:16 bmace sure thing! :)
18:25:43 openstackgerrit Matt Riedemann proposed openstack/nova master: Add functional recreate test for bug 1764556 https://review.openstack.org/562041
18:25:43 openstack bug 1764556 in OpenStack Compute (nova) ""nova list" fails with exception.ServiceNotFound if service is deleted and has no UUID" [Undecided,New] https://launchpad.net/bugs/1764556
18:58:41 openstackgerrit melanie witt proposed openstack/nova master: Make scheduler.utils.setup_instance_group query all cells https://review.openstack.org/540258
18:59:53 melwitt dansmith: updated to scope the query only for targeted cell for move operations, else scatter-gather ^
19:00:22 dansmith melwitt: tab queued
19:00:40 dansmith melwitt: tssurya: need a cells meeting today? I again have nothing new
19:00:58 tssurya dansmith: me neither
19:01:00 melwitt (was about to ask the same thing) are we having a cells meeting today? that was the only thing I think I wanted to highlight. mriedem isn't around on IRC today
19:01:29 dansmith sweet
19:01:32 melwitt okay, sounds like we're good to skip today. only thing to keep in mind is anything you'd like to get in for r-1 tomorrow
19:02:29 melwitt lettuce know
19:02:34 tssurya also question about this nova-manage bug -> https://bugs.launchpad.net/nova/+bug/1746530 I marked it as won't fix because it felt more like an oslo_db issue, however please revert the status if there is a possible fix in nova part
19:02:34 openstack Launchpad bug 1746530 in OpenStack Compute (nova) "nova-manage api_db sync - NotSupportedWarning ['use_tpool']" [Medium,Won't fix]
19:03:43 tssurya infact we would be interested if there is a fix on the nova side for the warning that comes up in Queens all the time
19:07:16 melwitt looks like that oslo.db fix landed in queens, but we didn't bump our requirements for oslo.db and we can't now that queens is a stable branch. so yeah, would have to do something in nova if anything
19:08:13 tssurya melwitt: oh I didn't know that fix landed in queens as well,
19:08:32 melwitt er, maybe it didn't. sorry, I got confused looking at the nova commit
19:08:54 tssurya yea I guess the oslo_db fix is also only in master
19:09:34 melwitt yeah if it was fixed recently then it would be for rocky and even if it was backported, we couldn't bump the requirement on stable to consume it
19:10:00 tssurya I know that its just a warning, but was just wondering if there was a work around by any chance in nova
19:10:15 melwitt yeah. it's possible, I dunno off the top of my head
19:10:16 tssurya oh okay, shall I keep it as won't fix ?
19:11:03 melwitt yeah, I would since it's fixed for master and probably not worth trying to do a one-off for queens since it's just a warning IMHO
19:11:29 tssurya yep,
19:11:31 tssurya cool
19:18:37 openstackgerrit Merged openstack/nova-specs master: Fix typo in GET os-instance-actions url. https://review.openstack.org/557143
19:45:42 cdent melwitt: Is there still a gate job that runs with postgres? I seem to recall an experimental one or something?
19:48:51 openstackgerrit Merged openstack/osc-placement master: Initialize 'result' variable in functional.base https://review.openstack.org/560004
19:49:44 melwitt hm, not sure. looking
19:52:22 cdent the reason I ask is because I've stumbled upon a postgres-related problem in some of the placement sql and I can't figure out when it started and I'm exploring my options for finding it
19:53:35 melwitt I see. having trouble finding where our list of experimental jobs is, I can't remember where things are supposed to be since zuul v3
19:54:44 cdent yeah, had the same problem
19:54:51 melwitt but not finding hardly anything related to postgres in openstack-zuul-jobs
19:55:55 melwitt or project-config
19:56:16 cdent ditto
19:56:38 openstackgerrit Jackie Truong proposed openstack/nova master: Implement certificate_utils https://review.openstack.org/479949
19:56:39 openstackgerrit Jackie Truong proposed openstack/nova master: Plumb trusted_certs through libvirt driver image paths https://review.openstack.org/561262
19:56:40 cdent so it's either gone or hiding. I know Matt was keen on it existing, but don't know if it stayed aline
19:56:40 openstackgerrit Jackie Truong proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204
19:56:41 openstackgerrit Jackie Truong proposed openstack/nova master: Add certificate validation docs https://review.openstack.org/560158
19:57:18 cdent i'll try faking it locally
19:57:32 openstackgerrit Matt Riedemann proposed openstack/nova stable/ocata: libvirt: Block swap volume attempts with encrypted volumes prior to Queens https://review.openstack.org/561604
20:05:15 spotz Hey all do you want me to file a bug for nova where the error message in the nova client is typoed? I'm guessing I can track it down and fix it possibly
20:07:50 melwitt spotz: sure, you can file a novaclient bug here https://bugs.launchpad.net/python-novaclient
20:08:07 melwitt (assuming the typo is in novaclient)
20:08:56 spotz Thanks melwitt, trying to track it down. It might be a little larger then just the message. stable/ocata won't associate a floating IP even though it says after Pike
20:11:42 spotz If I change the api version as the message suggests it works so, I'lljust bug the typo
20:12:47 melwitt cdent: you might be able to use a technique similar to this if you can find a postgres job in another project https://review.openstack.org/#/c/427668
20:15:01 cdent thanks melwitt
20:15:02 openstackgerrit Matt Riedemann proposed openstack/nova stable/ocata: Modify incorrect debug meaasge in _inject_data https://review.openstack.org/519950
20:18:45 melwitt spotz: okay. link me the bug after you file it, I'm not sure what message this is about. starting in newton, the nova API stopped proxying to neutron so floating IP association has to be done through neutron or openstackclient. so I'm not sure what message is saying "after Pike"

Earlier   Later