Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-27
17:12:56 openstackgerrit Balazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations https://review.openstack.org/637955
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 compute_api = LazyLoader(...)
20:26:59 efried so you keep it in init as
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: Count instances from mappings and cores/ram from placement https://review.openstack.org/638073
01:18:42 openstackgerrit melanie witt proposed openstack/nova master: Add get_counts() to InstanceMappingList https://review.openstack.org/638072
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
10:09:30 sean-k-mooney well see that is the thing there are not execatly needs but they are more techdebt removal that happens to also imporve sechduling
10:10:38 sean-k-mooney gibi: ya i think you have put most of the infrastuture in place already as part of your bandwith work to adress some of those wishlist items
10:11:03 sean-k-mooney numa affinity of vswitches we have done in a none placement way already too
10:11:45 gibi I think it worth to talk about these on the PTG. I can definitely give review support for some of this items while I work on the move operation bp
10:12:17 gibi sean-k-mooney: do we want to re-do numa aware vswitches based on placement?
10:12:56 sean-k-mooney maybe at somepoint but i have been wonderign if we should punt numa in placement to U
10:13:15 sean-k-mooney to try and get other lower hanging furit feature workign first
10:13:45 sean-k-mooney long term i still hope we can model numa in placement but it makes everything more complicated
10:15:22 sean-k-mooney for better or worse the numa topology filter and numa resouce tracker work well enough that i think the benifit of track pci devices or cpus in placement without numa outways the beniftis of numa in placment
10:16:40 gibi sean-k-mooney: I think, either we need to put big focus on the numa-in-placement feature or focus on the small improvements that already possible, but both cannot be done in the same cycle

Earlier   Later