Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-27
16:02:08 trident Before the fix it doesn't get into error.
16:02:16 efried if you put it all in one patch, we have to pull down the patch and remove your fix manually and run the tests to see that they fail.
16:02:27 efried cool
16:02:27 gibi I agree ^^
16:02:47 efried ocraplookatthetime
16:04:24 trident Great. I'll clean it up a little, get one node disabled and submit something by tomorrow. Thanks everyone for the assistance!
16:05:43 gibi trident: thanks for the effort!
16:14:01 openstackgerrit Merged openstack/nova master: Add doc on VGPU allocs and inventories for nrp https://review.openstack.org/647519
17:12:55 openstackgerrit Balazs Gibizer proposed openstack/nova master: Prepare _heal_allocations_for_instance for nested allocations https://review.openstack.org/637954
17:12:56 openstackgerrit Balazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations https://review.openstack.org/637955
17:12:56 openstackgerrit Balazs Gibizer proposed openstack/nova master: cache neutron ports in heal allocation https://review.openstack.org/638207
17:13:39 melwitt dansmith: do you think there would be any issues with having a module global ComputeAPI instance in console proxy? discussion in this patch of mine https://review.openstack.org/644998
17:14:17 dansmith melwitt: I think the only state computeapi maintains is the compute rpc instance right?
17:14:32 melwitt dansmith: I believe so
17:14:47 dansmith I don't remember how SIGHUP wires into triggering that to re-calculate the pins, so that would be my only concern I think
17:14:58 dansmith but otherwise probably fine
17:15:43 dansmith oh wait
17:15:49 dansmith you mean rpcapi/ComputeAPI yeah?
17:15:52 melwitt dansmith: ok, I'll look into it. thanks
17:15:55 melwitt yeah, I do. sorry
17:16:03 dansmith I was thinking you meant compute_api/TheThingWhatever
17:16:06 melwitt I was just realizing there's two different ones
17:16:08 melwitt yeah
17:16:11 dansmith so confusing that they're ... confusing
17:16:40 dansmith melwitt: yeah so right now that rpcapi gets created each time, which means it's never stale (but also means it's doing a calculation on every load)
17:16:59 dansmith so I think you'd want to make sure to wire up the sighup like the other services use to bump it
17:17:14 dansmith assuming that oslo.service gets fixed of course :)
17:17:19 melwitt I see, ok
17:27:28 openstackgerrit Balazs Gibizer proposed openstack/nova master: Change the TODO to NOTE about instance multi-create https://review.openstack.org/638847
17:39:09 melwitt dansmith: hm, the console proxies don't actually use oslo.service. they are websockify servers, and it looks like websockify currently ignores SIGHUP https://github.com/novnc/websockify/blob/master/other/websocket.c#L768
17:45:20 dansmith melwitt: ah, aight then
17:45:32 dansmith melwitt: it still means it's a change from current, but maybe more meh
17:49:42 melwitt dansmith: yeah. in my patch currently, I have rpcapi/ComputeAPI still as a class variable, but I'm relying on knowing the order of calls internally in websockify. making ComputeAPI global would eliminate that, but then I wouldn't be able to handle SIGHUP
17:50:16 dansmith well, it doesn't matter now because it's instantiated per request right?
17:50:28 dansmith meaning, no need for sighup currently, but after your change...
17:50:40 melwitt per connection yeah
17:51:43 melwitt yeah, if I make it global. I didn't make it global yet. maybe it's better to leave it as it is, per connection. because relying on the websockify call ordering seems less bad
17:57:59 dansmith yeah
18:58:15 openstackgerrit Artom Lifshitz proposed openstack/nova master: [WIP] Revert resize: wait for external events in compute manager https://review.openstack.org/644881
19:00:19 openstackgerrit Artom Lifshitz proposed openstack/nova master: [WIP] Revert resize: wait for external events in compute manager https://review.openstack.org/644881
19:08:43 sean-k-mooney so related to ^ i am currently porposing a change to neutron so that they will tell us when network events are sent so we can do that sanely https://review.openstack.org/#/c/645173/2
19:59:08 efried melwitt: I thought the concern was that we would do a bunch of init on ComputeAPI objects that ended up not being used
19:59:30 efried melwitt: in which case lazy load (but no global/singleton) would work okay, right?
20:19:54 melwitt efried: oh, you mean in new_websocket_client? hm, I guess that should work. from the pre-existing code comment, I was thinking it needed to be instantiated ahead of new_websocket_client, but I can try that and see if the tempest novnc tests pass
20:20:18 melwitt it = ComputeAPI
20:21:00 efried melwitt: I'm saying, instantiate it in the same place, but through a lazy loader
20:21:12 efried so it only actually initializes if you get down into new_websocket_client
20:21:30 efried but in the code paths that never get there, nothing ever happens to it and you don't waste the... whatever
20:21:54 efried but that way you don't have to worry about if like the code path changes from underneath you
20:22:06 melwitt efried: what is a "lazy loader"? I was thinking in __init__ it's set to None, in new_websocket_client, it's instantiated if None
20:22:44 efried We did a thing with this for the scheduler client at some point (we have since removed it)
20:25:13 melwitt that's how lazy load works underneath. won't be instantiated until use. I had thought from the pre-existing comment, it was saying it needed to be instantiated before new_websocket_client, but I don't see why it wouldn't work to instantiate it (once, if None) in new_websocket_client
20:25:48 efried melwitt: https://github.com/openstack/nova/blob/stable/queens/nova/scheduler/client/__init__.py
20:26:20 melwitt yeah, that's what I'm already saying I think
20:26:26 efried melwitt: I'm saying we shouldn't rely on new_websocket_client continuing to be the right place to do that init, in case the code flow changes underneath us.
20:26:50 melwitt efried: I get what you're saying, I'm saying I had thought from the existing code comment that it couldn't be that way. but I can try it and see what happens
20:26:59 efried so you keep it in init as
20:26:59 efried compute_api = LazyLoader(...)
20:27:06 efried oh
20:28:06 melwitt because what LazyLoader will do is what I said, construct a ComputeAPI object in new_websocket_client
20:29:00 melwitt I think it will work fine. I probably took the code comment too literally
20:29:32 efried okay, yeah, the way I read the comment is that new_websocket_client needs to use the ComputeAPI, so it had better be instantiated by the time it needs to use it.
20:29:47 efried but if you make it a lazy load, then it gets instantiated dynamically by the thing that needs to use it
20:29:50 efried badabing etc.
20:29:53 melwitt yeah
20:30:07 efried anyway, worth a shot
20:30:18 melwitt yeah, I'll try it
21:16:49 openstackgerrit François Palin proposed openstack/nova master: WIP - nova diagnostics command is not working with all interfaces https://review.openstack.org/648123
21:39:26 openstackgerrit Dan Smith proposed openstack/os-traits master: Add COMPUTE_IMAGE_TYPE_SUPPORT_* traits https://review.openstack.org/648147
21:51:45 openstackgerrit melanie witt proposed openstack/nova master: Move create of ComputeAPI object in websocketproxy https://review.openstack.org/644998
22:03:51 efried melwitt: ^ Very nice. So are we waiting for test results to prove it?
22:04:17 melwitt efried: yeah, just want to see the result of the tempest novnc tests
#openstack-nova - 2019-03-28
01:06:35 openstackgerrit Takashi NATSUME proposed openstack/nova master: doc: Fix openstack CLI command https://review.openstack.org/648299
01:18:42 openstackgerrit melanie witt proposed openstack/nova master: Add get_counts() to InstanceMappingList https://review.openstack.org/638072
01:18:42 openstackgerrit melanie witt proposed openstack/nova master: Count instances from mappings and cores/ram from placement https://review.openstack.org/638073
01:18:43 openstackgerrit melanie witt proposed openstack/nova master: Use instance mappings to count server group members https://review.openstack.org/638324
02:33:16 openstackgerrit Takashi NATSUME proposed openstack/nova master: Add minimum value in max_concurrent_live_migrations https://review.openstack.org/648302
03:19:37 openstackgerrit Merged openstack/nova stable/pike: Document unset/reset wrinkle for *_allocation_ratio options https://review.openstack.org/647292
03:33:00 openstackgerrit Merged openstack/nova stable/queens: Don't persist zero allocation ratios in ResourceTracker https://review.openstack.org/613271
03:33:06 openstackgerrit Merged openstack/nova stable/queens: Update resources once in update_available_resource https://review.openstack.org/612294
07:28:05 openstackgerrit Merged openstack/nova master: Exec systemd-run without --user flag in Quobyte driver https://review.openstack.org/554195
07:46:35 openstackgerrit Merged openstack/nova master: Update instance.availability_zone on revertResize https://review.openstack.org/643155
08:09:59 openstackgerrit Yongli He proposed openstack/nova master: Clean up orphan instances https://review.openstack.org/627765
09:06:17 tssurya alex_xu, dansmith: I get the backwards compatibility point and all here: https://review.openstack.org/#/c/638629/6/specs/train/approved/add-locked-reason.rst@106 , but introducing them as individual keys means more keys which would have the value as NULL most of the time.
09:45:37 sean-k-mooney o/
09:47:09 sean-k-mooney any nova cores about that care to review a neutron spec im proposing? i will be writing a nova spec for the nova/os-vif side but if its a total non starter then ill move on to more important things
09:47:21 sean-k-mooney gibi: thanks for taking a look already
09:47:31 sean-k-mooney https://review.openstack.org/#/c/645173
09:49:24 gibi sean-k-mooney: I think the goal to fix the problems you listed in that spec is a good goal. For me it is a bit hard to imagine how this will impact nova, especially the dependency between nova and neutron backends
09:49:27 sean-k-mooney by the way im aware we are trying to finalise RC2 so i know people are busy
09:49:55 gibi sean-k-mooney: I have to go back and read you answers still
09:50:56 sean-k-mooney gibi: ya i think i need to sit down and write the nova centric spec to illistrate that impact so that nova people dont need to look at the neutron aspect as much
09:51:16 sean-k-mooney i have left a comment that tried to summerise it but im not sure how clear it was
09:52:57 sean-k-mooney the nova/os-vif impact is summerised here https://review.openstack.org/#/c/645173/2/specs/train/port-binding-extended-information.rst@130
09:54:12 sean-k-mooney but anyway if other nova cores are interested in nova/neutron stuff early feedback on "is this somethign we want to fix" would be good as i dont want to speed lots of time on the nova spec if its a total non starter
10:06:45 sean-k-mooney gibi: so looking at you https://blueprints.launchpad.net/nova/+spec/enhance-support-for-ports-having-resource-request i have some long standing wish list items for network aware schduling that might be able to tie into that
10:07:31 sean-k-mooney if we look back at https://etherpad.openstack.org/p/placement-nova-neutron-queens-ptg i listed some of them when i was making the case for completeing nested resouce providers
10:08:12 gibi sean-k-mooney: let's list your needs part of the item in https://etherpad.openstack.org/p/nova-ptg-train
10:08:57 gibi physnet aware placement looks interesting
10:09:24 gibi vswitch vif capacity also seems doable now

Earlier   Later