| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-13 | |||
| 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? | |
| 15:53:22 | openstackgerrit | Cedric Brandily proposed openstack/nova master: Remove VMware driver _get_vm_ref_from_uuid method https://review.openstack.org/444959 | |
| 15:54:30 | dansmith | bauzas: yes | |
| 15:54:31 | jroll | bauzas: yes | |
| 15:57:38 | openstackgerrit | Cedric Brandily proposed openstack/nova master: VMware: use WithRetrieval in get_network_with_the_name https://review.openstack.org/325587 | |
| 15:59:06 | openstackgerrit | Cedric Brandily proposed openstack/nova master: VMware: use WithRetrieval in vm_util module https://review.openstack.org/325608 | |
| 15:59:17 | openstackgerrit | Cedric Brandily proposed openstack/nova master: VMware: use WithRetrieval in ds_util module https://review.openstack.org/325610 | |
| 15:59:30 | erol | sean-k-mooney: Hey, When I added another ironic node, I didt get error from Schedular. I think it is all about RetryFilter. | |
| 16:01:16 | sean-k-mooney | erol: interesting. though the pastbin was showing that the ram filter was the filter that eliminated all of the host | |
| 16:01:34 | sean-k-mooney | erol: Filter results: ['RetryFilter: (start: 4, end: 3)', 'AvailabilityZoneFilter: (start: 3, end: 3)', 'RamFilter: (start: 3, end: 0)'] | |
| 16:02:35 | sean-k-mooney | erol: the retry filter eliminated 1 host which was the host that was tried first | |
| 16:03:28 | erol | sean-k-mooney: all of 3 node is kvm node, there is no enough resource that instance need on them. Sorry for the indicate it. | |
| 16:04:02 | sean-k-mooney | erol: so you have a mixed deployment ironic/kvm? | |
| 16:04:44 | erol | I think Retryfilter eliminate Ironic node, and then When it check ram resource it cant find correct one in kvm nodes. | |
| 16:04:50 | sean-k-mooney | and the ram filter failed on the kvm nodes when trying to select a baremetal flavor | |
| 16:05:15 | erol | sean-k-mooney: yeah. 3 Nova Compute 2 ironic compute for now. | |
| 16:05:17 | sean-k-mooney | erol: the retry filter only filters nodes if it tred to scheduler to it and then failed | |
| 16:06:18 | sean-k-mooney | erol: it previously selected u'ironic-compute', u'f01c9155-7d1e-4351-8225-670e0d48452a' that failed to boot and it retryed the rest - that node | |