| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-13 | |||
| 12:23:06 | artom | sfinucan, thanks for the tagged attach reviews :) I'll get to websocket proxy security, I promise. In my defense, it's harder to get full context for the latter than the former, and I don't feel like just reviewing patch by patch and writing nits | |
| 12:23:59 | artom | I had an idea about removing the tag=None param to the driver interface, let me respin that first | |
| 12:25:21 | artom | Building device metadata is probably not a huge deal, optimization-wise, but the DB call hidden in instance.save definitely is. So I'm thinking build the new device metadata, compare it to the old one, and only save if there's a difference | |
| 12:25:33 | artom | Get rid of the driver interface change, still no useless DB queries | |
| 12:26:29 | artom | Wait... | |
| 12:26:40 | artom | Doesn't save() call obj_what_changed() or whatever it's called? | |
| 12:26:54 | artom | Does it still call the database if nothing has changed? | |
| 12:28:45 | sfinucan | artom: Yeah, no (immediate) panic :) the websocket proxy stuff /is/ tougher to review than other stuff, seeing as it's not just glue like other nova code | |
| 12:29:09 | sfinucan | I'd be interested in seeing the approach to removing the tag parameter though, if it works out | |
| 12:29:19 | sfinucan | Steadily working through the rest of the series now | |
| 12:29:40 | sfinucan | sahid: RE: https://review.openstack.org/#/c/400875/, this is the issue I have with it https://review.openstack.org/#/c/400875/23/nova/virt/hardware.py@848 | |
| 12:29:44 | artom | Based on ^^^ I think we can just remove with no other changes/repercussions? | |
| 12:29:58 | sfinucan | For N calls of _numa_fit_instance_cell_with_pinning, you will only ever have one where num_cpu_reserved is anything but 0 | |
| 12:30:04 | sfinucan | That, to me, is overloading | |
| 12:30:18 | artom | dansmith can confirm when he wakes up, but if instance.save() is smart about how it calls the database, which I think it is, we're good | |
| 12:30:31 | sfinucan | artom: looking | |
| 12:32:35 | openstackgerrit | Sergey Nikitin proposed openstack/nova master: [WIP] PIC NUMA policy PoC https://review.openstack.org/390520 | |
| 12:35:33 | artom | https://github.com/openstack/nova/blob/master/nova/objects/instance.py#L721 https://github.com/openstack/nova/blob/master/nova/objects/instance.py#L663 | |
| 12:36:19 | artom | ^^ that pretty conclusively indicates that if device_metadata has not changed, there will be no useless DB calls | |
| 12:42:42 | sfinucan | artom: That would be reading of it to | |
| 12:42:44 | sfinucan | Good spot | |
| 12:42:47 | sfinucan | So | |
| 12:43:30 | sfinucan | We can just call it every single time with negligible performance impact | |
| 12:46:04 | artom | sfinucan, pretty sure | |
| 12:46:51 | artom | sfinucan, the little ones are waking up, let me drive them to daycare and I'll continue after | |
| 12:47:02 | sfinucan | artom: (y) | |
| 12:56:11 | erol | hi everyone, I wonder Is there any way to flush Nova Schedular RetryFilter count? I hit max attempt. What can i do now? | |
| 12:56:16 | sean-k-mooney | sc68cal: if you get a chance can you review https://review.openstack.org/#/c/444788 it will fix our third party ci after https://review.openstack.org/#/c/435575/ added a test requirement that break ovs compilation | |
| 12:57:01 | sean-k-mooney | sc68cal: it should also give a speed up in the ci jobs as less stuff needs to be downloaded which is a nice side effect | |
| 12:58:19 | sean-k-mooney | erol: usually you delete the instance and try again but if you hit max attempts its often because there was a problem with the request | |
| 12:58:48 | sean-k-mooney | erol: either no host satifies the request or you have an infra issue that is stoping the cloud from working correctly | |
| 13:03:37 | erol | sean-k-mooney: Thanks. I try to run Ironic and have an issue on provisioning. After I attempted several times. I came a cross with these output in schedular log http://paste.openstack.org/show/602488/ | |
| 13:12:39 | openstackgerrit | Rafael Folco proposed openstack/nova master: DELETE all inventory for a resource provider https://review.openstack.org/416669 | |
| 13:12:40 | openstackgerrit | Rafael Folco proposed openstack/nova master: Raising http codes on old microversion https://review.openstack.org/444497 | |
| 13:41:58 | openstackgerrit | Sergey Nikitin proposed openstack/nova master: [WIP] PIC NUMA policy PoC https://review.openstack.org/390520 | |
| 13:48:55 | mriedem | o/ | |
| 13:51:55 | dansmith | alex_xu: you still around? | |
| 13:55:15 | bauzas | oh, you US folks already had DST shift ? | |
| 13:55:20 | edleafe | Scheduler subteam meeting in 5 minutes in #openstack-meeting-alt | |
| 13:55:35 | leakypipes | rfolco: were you working on adding error codes (in addition to error messages) to the placement API? can't remember if that was you or diga... | |
| 13:55:35 | mriedem | bauzas: that was this weekend | |
| 13:55:36 | edleafe | bauzas: yep - yeaterday | |
| 13:56:10 | mriedem | leakypipes: neither https://review.openstack.org/#/c/418393/ | |
| 13:56:22 | leakypipes | mriedem: ah! | |
| 13:56:30 | leakypipes | it was _gryf | |
| 13:57:17 | bauzas | mriedem: edleafe: cool then, France is now closer to the US :) | |
| 13:58:01 | rfolco | leakypipes, morning. Not me. | |
| 13:59:45 | leakypipes | rfolco: np :) thanks! | |
| 14:00:40 | edleafe | leakypipes: time to plug the leak | |
| 14:00:49 | jaypipes | :) | |
| 14:04:43 | _gryf | yup, I did that bp | |
| 14:05:35 | markus_z | mriedem: JFYI, the VNC issue we talked about 1w ago will be fixed with: https://review.openstack.org/#/c/444164/ | |
| 14:07:34 | markus_z | mriedem: I also have to pester you about: https://review.openstack.org/#/c/406898/ All info you asked for is added to that review. | |
| 14:08:06 | mriedem | ok | |
| 14:09:10 | openstackgerrit | dane-fichter proposed openstack/nova-specs master: Trusted flavors https://review.openstack.org/312225 | |
| 14:10:01 | sfinucan | jaypipes: Might you be so kind as to stick this on your review backlog for this week? https://review.openstack.org/#/c/361140/ | |
| 14:10:31 | sfinucan | johnthetubaguy too ^, if you could | |
| 14:12:30 | dane-fichter | mriedem , sdague : Could you guys take a look at my change adding the security tempest tests as an experimental check in Nova? https://review.openstack.org/#/c/443167/ | |
| 14:13:59 | mriedem | dane-fichter: sure | |
| 14:14:11 | dane-fichter | mriedem: thanks! | |
| 14:18:57 | jaypipes | sfinucan: ya | |
| 14:19:19 | sfinucan | jaypipes: Thank you, sir | |
| 14:19:35 | jaypipes | sfinucan: np. you know I love my numa. :P | |
| 14:20:11 | sfinucan | jaypipes: I saw numa'y stuff and decided to r̶u̶i̶n̶ make your day | |
| 14:22:43 | mriedem | markus_z: the multinode vnc fix looks good to me, that's even called out in the devstack multinode docs | |
| 14:24:04 | jaypipes | sfinucan: :) | |
| 14:25:33 | openstackgerrit | Stephen Finucane proposed openstack/nova master: trivial: Add a note about 'cells_api' https://review.openstack.org/444926 | |
| 14:26:18 | dansmith | johnthetubaguy: alex_xu: I'm totally lost.. where does cachingscheduler override things in HostManager? | |
| 14:26:52 | johnthetubaguy | dansmith: it uses get_all_hosts() basically | |
| 14:27:02 | johnthetubaguy | rather than get_by_uuid | |
| 14:27:07 | johnthetubaguy | s | |
| 14:27:42 | johnthetubaguy | dansmith: https://github.com/openstack/nova/blob/master/nova/scheduler/caching_scheduler.py#L75 | |
| 14:28:09 | johnthetubaguy | dansmith: might be time to deprecate that thing soon, although I was hoping to wait until we do allocations in the conductor really | |
| 14:28:17 | dansmith | johnthetubaguy: okay the main scheduler uses that purely to prime the data structures, but not for an actual schedule.. wouldn't the caching scheduler only cache hosts that are valid for a particular spec_obj if we made that change? | |
| 14:28:35 | johnthetubaguy | dansmith: no, it caches the full list of hosts | |
| 14:28:48 | johnthetubaguy | and bypasses the placement PAI | |
| 14:28:49 | johnthetubaguy | API | |
| 14:29:41 | johnthetubaguy | dansmith: did we have moving allocations into the conductor pencilled in for this cycle yet? | |
| 14:29:52 | dansmith | johnthetubaguy: right, but.. I don't understand what you think needs to change.. the _all_cells method takes a spec_obj only if you want to cause it to limit the host list based on a requested cell, | |
| 14:29:56 | dansmith | which you'd never want to do with that right? | |
| 14:30:30 | johnthetubaguy | dansmith: oh, sorry, I see your point now... it just doesn't work for the caching scheduler | |
| 14:30:43 | dansmith | right | |
| 14:31:31 | dansmith | johnthetubaguy: either we'd have to honor the cell request somewhere else, or just not have this happen if you're using cachingscheduler | |
| 14:31:32 | dansmith | I dunno who all uses it, tbh, so I guess I'm not sure the implications of that | |
| 14:32:29 | johnthetubaguy | dansmith: large deployments currently suck without using that, like >100 nodes or something like that, so probably only the large ones | |
| 14:32:42 | dansmith | johnthetubaguy: what about large deployments now that we have placement? | |
| 14:32:54 | dansmith | johnthetubaguy: we should be getting the host list waaayyy faster now as of this cycle | |
| 14:32:57 | johnthetubaguy | dansmith: they are much worse, if I understand it correctly | |
| 14:33:06 | dansmith | WAT | |
| 14:33:10 | johnthetubaguy | yep | |
| 14:33:13 | dansmith | why? | |
| 14:33:13 | vsaienk0 | mriedem: could you please approve https://blueprints.launchpad.net/nova/+spec/ironic-hotplug-interfaces for Pike, the code is ready on both nova and ironic side, and it is very small change which already covered by CI tests. It would be great to have this implemented in Pike | |
| 14:33:24 | johnthetubaguy | dansmith: we don't do the allocations soon enough | |
| 14:33:40 | dansmith | jaypipes: ^ | |
| 14:33:42 | johnthetubaguy | dansmith: so you quickly hit the three retries, because everyone picks the same host | |
| 14:33:53 | dansmith | johnthetubaguy: placement makes that _worse_ ? | |
| 14:34:08 | dansmith | I thought cachingscheduler was for get_all_hosts() performance... | |
| 14:34:13 | johnthetubaguy | dansmith: worse than using caching scheduler, I mean | |
| 14:34:25 | johnthetubaguy | dansmith: its performance, and caching of results between API calls | |
| 14:34:54 | dansmith | johnthetubaguy: does cachingscheduler affect allocation timing though? I thought it was just about finding the list of hosts quickly, which placement *should*be improving | |