Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-18
15:34:36 melwitt gibi: this time I'm going to try to prepare some slides in case we need them. apparently this is the sort of thing the foundation recommends we do or at least have available if the room is total newcomers https://www.slideshare.net/JayBryant2/openstack-cinder-onboarding-education-boston-summit-2017
15:35:16 efried dansmith: Looking at what compute manager does after that, it'll try to get that allocation again, and short-circuit out at *that* point.
15:35:41 dansmith efried: tbh, I would still raise a NotFound there instead of returning a boolean, but it should return False, since the code is using that to determine if the other side of the migration was new or not.. "it's already gone" is not what it's checking for
15:35:43 efried dansmith: So the harm is only one redundant placement call (and an info log).
15:36:20 dansmith efried: see above.. this is not just trying to nuke the allocation, it needs to know whether it existed or not
15:36:26 cfriesen efried: I'm thinking of the [glance]/api_servers or [neutron]/url
15:36:55 efried dansmith: Okay. So the report client method is doing the right thing; it's just that that thing is a bit confusing.
15:37:18 dansmith efried: well, like I said, if it raised NotFound there and we were catching it, I think it might be a little more obvious
15:37:29 efried dansmith: The docstring would say:
15:37:29 efried :return: True if the instance's allocations were deleted; False if they were not (which is also the case if the allocations weren't there to begin with)
15:37:31 cfriesen efried: although, I guess those are now optional rather than required
15:37:38 dansmith efried: instead of "did we delete it?" we'd be saying "We deleted it" or "it didn't exist" which is what we're really after
15:37:59 efried cfriesen: Correct.
15:38:24 efried cfriesen: deprecated, in the latter case. In the former case, only use api_servers if you actually *need* multiple endpoints.
15:38:47 efried cfriesen: There was work over the past couple of releases to make that happen. I can find the bp if you like...
15:39:18 efried cfriesen: https://review.openstack.org/#/q/topic:bp/use-ksa-adapter-for-endpoints
15:39:52 efried cfriesen: Note the one that's still open. I would welcome someone jumping in and finishing that one...
15:39:53 cfriesen efried: thanks
15:41:37 openstackgerrit Merged openstack/nova master: Fix docs for confirmResize action https://review.openstack.org/562062
15:42:32 gibi melwitt: OK. If you need help perparing or reviewing such slideset then I'm happy to help
15:43:06 melwitt thanks
15:43:07 openstackgerrit Nguyen Hai proposed openstack/nova-specs master: Follow the new PTI for document build https://review.openstack.org/551802
15:49:36 arvindn05 jaypipes: wanted to get your thoughts on role of placement during rebuild
15:50:07 openstackgerrit Nguyen Hai proposed openstack/nova-specs master: Follow the new PTI for document build https://review.openstack.org/551802
15:50:59 openstackgerrit Nguyen Hai proposed openstack/nova-specs master: Follow the new PTI for document build https://review.openstack.org/551802
15:56:31 jaypipes arvindn05: currently deep in the middle of teasing apart the @safe_connect decorator from the placement report client... may be some time until I can get to that :(
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

Earlier   Later