| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-13 | |||
| 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 | |
| 14:35:00 | johnthetubaguy | jaypipes: in my head I had us killing the caching scheduler once allocations are written in the conductor | |
| 14:35:40 | johnthetubaguy | dansmith: no, its also about that cache being updated with the previous results, thats why it only works if you have one nova-scheduler, and fails badly if you have two caching schedulers | |
| 14:35:57 | dansmith | johnthetubaguy: ugh, okay | |
| 14:36:13 | johnthetubaguy | dansmith: yeah, its really non-obvious from the code thats how it works | |
| 14:37:24 | johnthetubaguy | dansmith: that logic that makes when we scheduler a request of 5 builds at once not all pick the same host activates for every request using the same cached list | |
| 14:37:26 | mriedem | vsaienk0: done | |
| 14:37:57 | vsaienk0 | mriedem: thanks! | |
| 14:38:07 | jaypipes | johnthetubaguy: I'd appreciate a hangout discussion with you about the caching scheduler and the placement service. | |
| 14:38:15 | jaypipes | johnthetubaguy: do you have some time to discuss it now? | |
| 14:38:19 | dansmith | johnthetubaguy: I guess I'm surprised that's a real problem with randomizing the result list and sufficient capacity | |
| 14:38:22 | dansmith | jaypipes: I want in on that | |
| 14:38:28 | dansmith | because cells. | |
| 14:38:34 | mriedem | can't you configure the scheduler to spread rather than pack? or does just no one do that in production? | |
| 14:38:37 | jaypipes | dansmith: I figured as much :) | |
| 14:38:41 | johnthetubaguy | jaypipes: dansmith: I have 20 mins now if you are both free? | |
| 14:38:47 | dansmith | I am | |
| 14:38:51 | jaypipes | me too. | |
| 14:38:52 | mriedem | i'm jumping in too | |
| 14:38:54 | jaypipes | sec, getting link. | |
| 14:38:58 | johnthetubaguy | mriedem: right, no one wants spread, because you run our of large instances | |
| 14:39:23 | jaypipes | https://hangouts.google.com/call/s6p6dqm3dfbyxjwu5ppyhj4y2ae | |
| 14:39:54 | jaypipes | mriedem: ^ | |
| 14:40:21 | mriedem | yeah, damn firefox doesn't support hangouts anymore on the latest version | |
| 14:41:44 | dansmith | jaypipes: https://review.openstack.org/#/c/438025/21/nova/scheduler/host_manager.py | |
| 14:46:17 | sc68cal | sean-k-mooney: you'll need to reach out to sdague about that issue, I'd like his input | |
| 14:47:02 | jaypipes | johnthetubaguy: https://github.com/openstack/nova/blob/master/nova/scheduler/client/__init__.py#L77 | |
| 14:49:21 | mriedem | pkoniszewski: i'm not totally sure about this backport since no one from the live migration subteam reviewed the change on master, can you take a look at this and see if the change itself (even though already merged on master), is OK? https://review.openstack.org/#/c/441037/ | |
| 14:55:01 | openstackgerrit | Béla Vancsics proposed openstack/nova master: Transform instance.trigger_crash_dump notification https://review.openstack.org/396225 | |
| 15:00:42 | mriedem | pkoniszewski: nevermind, it's only for resize, and tests there are all OK, so lgtm. | |
| 15:01:07 | mriedem | lyarwood: can you take a look at these ocata backports for a release this week? https://review.openstack.org/#/c/441171/ https://review.openstack.org/#/c/444374/ | |
| 15:03:13 | mriedem | dansmith: note i haven't posted the pike priorities list to the specs repo yet, but we had a list from the ptg, so this will change that | |
| 15:03:44 | dansmith | mriedem: it will a little, but I think it's clear that claims will be a queens thing | |
| 15:04:27 | mriedem | dansmith: ok that works too - and good to know since at the summit i/we have to present on what's in the works for queens, as annoying as that is to be reporting at this point | |
| 15:04:37 | dansmith | yeah | |
| 15:06:11 | sean-k-mooney | sc68cal: sure will do. thanks for taking a look though | |
| 15:06:23 | artom | johnthetubaguy, heya - sfinucan mentioned that the the SPICE native proxy spec (https://review.openstack.org/#/c/442040/) might be relevant to XVP in Xen - I'm mostly ignorant of what XVP is, but from a quick read I don't *think* there's any potential crossover between a SPICE native proxy, other than both are proxies, but maybe you could take a look? | |
| 15:07:32 | sean-k-mooney | erol: i dont think you are ment to use the RamFilter with ironic. at least in the past it had its own filter that replaced it | |
| 15:19:22 | BobBall | artom: Does this have to be spice-specific? XenAPI uses vnc consoles and - apart from the references to spice throughout the spec and in the API call - the proxying of the connection in this way should probably work for all console types, not just spice? | |
| 15:19:43 | artom | BobBall, not at all :) | |
| 15:20:08 | artom | The proxy code itself is completely generic, it's just iptables shovelling packets back and forth | |
| 15:20:38 | BobBall | Indeed - the only thing that concerns me ATM is using os-getSPICEConsole spice-native which is clearly spice specific | |
| 15:20:52 | artom | We started with SPICE because we need a user-facing feature to actually drive it, but we'll be happy to make adjustments of other drivers need it for them as well | |
| 15:21:18 | artom | BobBall, well, that's the API part for the user to get a URL for his native SPICE client | |
| 15:21:51 | erol | sean-k-mooney: I am using mirantis openstack with default settings. :( | |
| 15:22:30 | artom | BobBall, if xenapi wants a native proxy for their console an API can be added for that as well | |
| 15:23:00 | BobBall | artom: Understood. I'll comment on the spec. | |
| 15:23:10 | artom | And it can tell nova-nativeproxy which host/port it should start a proxy instance for | |
| 15:23:21 | artom | The host/port would come from the xenapi hypervisor, presumably | |
| 15:23:29 | artom | But that's your domain ;) | |
| 15:23:48 | BobBall | Indeed. That's how our consoles work with novnc currently. | |
| 15:27:50 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Modify PciPassthroughFilter to accept lists https://review.openstack.org/444946 | |
| 15:28:02 | openstackgerrit | Juan Antonio Osorio Robles proposed openstack/nova master: Make versioned notifications topics configurable https://review.openstack.org/444947 | |
| 15:31:08 | sfinucan | artom: Think I've all of https://review.openstack.org/#/q/topic:bp/virt-device-tagged-attach-detach reviewed now | |
| 15:31:37 | sfinucan | Thanks dansmith for the cells v1 clarification. I recorded it in the code itself here https://review.openstack.org/444926 | |
| 15:32:08 | artom | sfinucan, much thanks :) You were responsible for a cute moment this morning. I saw your "oh boy, here we go" email, laughed, daughter asked why I was laughing and wanted to see, I showed her your email, she did a forced laugh as well | |
| 15:32:51 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Read NIC features in libvirt https://review.openstack.org/444415 | |
| 15:34:29 | BobBall | artom: Just for my understanding, does requesting the spice console generate a unique password per request, or is a fixed password generated and associated with each VM? | |
| 15:34:30 | sfinucan | artom: Ha! cute :D | |
| 15:35:09 | artom | BobBall, the password is set by the libvirt driver on the SPICE console, and returned to the user | |
| 15:35:20 | artom | BobBall, xenapi can do whatever it wants in that regard | |
| 15:35:47 | BobBall | artom: So libvirt assigns a non-predictable password to each console? | |
| 15:36:00 | artom | BobBall, that's the current plan, yeah | |
| 15:36:17 | artom | Libvirt would set a new password on every request | |
| 15:37:04 | BobBall | ok thanks | |
| 15:37:40 | artom | Since this is essentially opening up the host's console socket to the entire world, we need to make it a minimum secure | |
| 15:37:51 | artom | So TLS if possible, and authentication | |
| 15:37:59 | BobBall | I totally agree. | |
| 15:39:08 | openstackgerrit | Maciej Szankin proposed openstack/nova-specs master: Add use-local-scheduler spec https://review.openstack.org/438936 | |
| 15:48:51 | mriedem | dansmith: replied in https://review.openstack.org/#/c/443403/ - let me know if i need to change things. starting orientation for the rest of the day in about 10 minutes | |
| 15:50:31 | bauzas | dansmith: jroll: jaypipes: do we have some spec that explains our consensus in L66 https://etherpad.openstack.org/p/nova-ptg-pike-placement | |
| 15:50:32 | bauzas | ? | |
| 15:50:53 | bauzas | tl;dr: ironic flavors need to be updated by adding extra specs | |
| 15:51:12 | bauzas | s/explains/reflects | |
| 15:51:28 | jroll | bauzas: that's on my list for this week | |
| 15:51:36 | jroll | (writing that spec) | |
| 15:51:48 | bauzas | jroll: okay, ping me when it's done, because I'm trying to push it downstream | |
| 15:52:02 | jroll | bauzas: will do, thanks | |
| 15:52:49 | bauzas | jroll: FWIW, operators would need to add a custom resource class in their extra spec per type of flavor they have, correct? | |