| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-27 | |||
| 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 | |
| 10:17:04 | gibi | sean-k-mooney: I can get behind both effort as at the end of the they I would like to see both done | |
| 10:17:15 | gibi | just dont want to overcommit | |
| 10:17:24 | sean-k-mooney | gibi: ya that was the same conclution that i came to when talking to some of the redhat folks internally | |
| 10:17:46 | sean-k-mooney | but we also didnt know what the comunity wanted | |
| 10:18:38 | sean-k-mooney | i think this is already listed as a ptg topic but i hope we will as you said decied to either do numa or a set of other small things but not both | |
| 10:18:55 | sean-k-mooney | in this cycle | |
| 10:19:47 | sean-k-mooney | gibi: related to your move operation work i wanted to also highlight this patch form bauzas https://review.openstack.org/#/c/589085/ | |
| 10:20:40 | sean-k-mooney | gibi: one of the issue the move operation will have is the fact that resize/migrate does not have acess to allocation candiaties. bauzas started to fix it and stopped for his vGPU work | |
| 10:21:18 | sean-k-mooney | im hoping if we fix this generically we can acclearate move operation for both vGPU and bandwith based schduleing | |
| 10:22:11 | sean-k-mooney | i know there are other gaps but i think there will be a lot fo synergey between those features | |
| 10:22:22 | gibi | sean-k-mooney: thanks for the link. I need to sit down and plan the support for move operations. There I will use what bauzas discovered already | |
| 10:22:49 | bauzas | gibi: sean-k-mooney: yeah, I was planning to update the change later | |
| 10:42:20 | gibi | easy +A (efried already +2d) https://review.openstack.org/#/c/638847/ | |
| 11:05:40 | bauzas | gibi: done | |
| 11:23:52 | openstackgerrit | Silvan Kaiser proposed openstack/nova master: Adds systemd detection result caching in Quobyte driver https://review.openstack.org/648093 | |
| 11:24:58 | openstackgerrit | zhaixiaojun proposed openstack/nova master: Remove flavor id and name validation code because of jsonschema validation.The jsonschema validation was added with Ieba96718264ad2ddfba63b65425f7e5bbb8606a9. https://review.openstack.org/638150 | |
| 11:25:08 | openstackgerrit | Silvan Kaiser proposed openstack/nova master: WIP: Adds systemd detection result caching in Quobyte driver https://review.openstack.org/648093 | |
| 11:27:45 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Remove IP proxy methods https://review.openstack.org/643115 | |
| 11:50:38 | openstackgerrit | Silvan Kaiser proposed openstack/nova master: WIP: Adds systemd detection result caching in Quobyte driver https://review.openstack.org/648093 | |