Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-19
10:51:47 johnthetubaguy "Finally, at least in ML2, the providernet and multiprovidernet extensions are two different APIs to supply/view the same underlying information. The older providernet extension can only deal with single-segment networks, but is easier to use. The newer multiprovidernet extension handles multi-segment networks and potentially supports an extensible set of a segment properties, but is more cumbersome to use, at
10:51:48 johnthetubaguy least from the CLI. Either extension can be used to create single-segment networks with ML2. "
10:51:52 johnthetubaguy hmm, I am confused
10:56:47 sfinucan johnthetubaguy: Far as I understand it, enabling that extension turns your typical response from something like this
10:57:06 sfinucan {'provider:physical_network': {'network': 'foo', ...}, ...}
10:57:08 sfinucan to this
10:57:24 sfinucan {'segments': ['provider:physical_network': {'network': 'foo', ...}, ...]}
10:58:15 sfinucan so vladikr is checking to see if that extension is enabled, then either simply returning 'provider:physical_network'->'network', or iterating through 'segments' to find the same
10:59:02 sfinucan johnthetubaguy: If that makes sense?
11:41:40 openstackgerrit Zhaokun Fu proposed openstack/nova-specs master: fix overridden error https://review.openstack.org/458034
11:53:34 openstackgerrit Zhaokun Fu proposed openstack/nova master: fix overridden error https://review.openstack.org/458037
12:08:20 openstackgerrit Roman Podoliaka proposed openstack/osc-placement master: tests: add a hook for functional testing in the gate https://review.openstack.org/452122
12:23:00 openstackgerrit Alex Xu proposed openstack/nova master: Add test ensure all the microversions are sequential in placement API https://review.openstack.org/458049
12:29:06 openstackgerrit Zhaokun Fu proposed openstack/nova-specs master: accomodate=>accommodate https://review.openstack.org/458050
12:40:24 openstackgerrit Andy McCrae proposed openstack/nova master: Allow CONTENT_LENGTH to be present but empty https://review.openstack.org/455710
12:45:08 alex_xu nova api meeting is in 15 mins at #openstack-meeting-4
12:48:21 openstackgerrit Roman Podoliaka proposed openstack/osc-placement master: tests: add a hook for functional testing in the gate https://review.openstack.org/452122
12:57:32 falseuser 1
12:58:34 falseuser hello！
13:01:37 johnthetubaguy sfinucan: sorry, missed your note, yeah thats what I was seeing, I am just trying to see if there is something else we should do too, maybe not
13:03:43 johnthetubaguy sfinucan: I wasn't expecting the neutron API to transform like that based on its settings, I guess thats what it does, confusing
13:04:42 sfinucan johnthetubaguy: Yeah, I must admit I based that on the docs. Maybe the docs don't reflect reality but I presumed they would
13:23:22 openstackgerrit Andy McCrae proposed openstack/nova master: Allow CONTENT_LENGTH to be present but empty https://review.openstack.org/455710
13:26:56 mriedem o/
13:37:35 openstackgerrit Andy McCrae proposed openstack/nova master: Allow CONTENT_LENGTH to be present but empty https://review.openstack.org/455710
13:43:01 johnthetubaguy sfinucan: I couldn't really find docs, just found the odd bug and things, where did you look for those?
13:43:16 sfinucan sec
13:44:19 sfinucan johnthetubaguy: https://developer.openstack.org/api-ref/networking/v2/#multiple-provider-extension
13:44:56 johnthetubaguy sfinucan: ah, yeah, I did look at those, just wasn't 100% sure how you use it still.
13:46:50 sfinucan johnthetubaguy: maybe we should ping the neutron guys directly?
13:47:04 sfinucan someone there could surely tell us this in a heartbeat :)
13:47:09 sfinucan one would hope, anyway ;)
13:48:05 johnthetubaguy sfinucan: yeah, we totally should
13:48:24 johnthetubaguy sfinucan: I think I get it now, just want to make sure I interpreted things correctly.
13:48:55 sfinucan johnthetubaguy: I'll let you do that and just lurk myself - you can ask your own questions best, heh
13:55:25 mriedem ha well this was popular https://review.openstack.org/#/c/457854/
13:57:00 mriedem lyarwood: can i get you to take a look at these backports? https://review.openstack.org/#/q/status:open+project:openstack/nova+topic:bug/1682693
14:00:35 jaypipes mriedem: reading your comment on bauzas placement-claims spec got me wondering... why is it that with multi-cell + super-conductor we are getting rid of the possibility of retries in the scheduling process?
14:01:03 openstackgerrit Feodor Tersin proposed openstack/nova master: Implement ScaleIO image backend https://review.openstack.org/407440
14:01:32 mriedem jaypipes: because the computes can only call back to the local cell conductor, not the super conductor, is my understanding
14:01:44 mriedem and there is no scheduler local to the cell,
14:01:52 mriedem so the local conductor can't ask the scheduler for a new list of hosts to retry
14:02:21 mriedem it would have to upcall to the top-level scheduler (the only scheduler), and i think we're avoid upcalls, because that's like cells v1
14:02:35 dansmith it's not just that we want to avoid them (we do),
14:02:39 openstackgerrit Andy McCrae proposed openstack/nova master: Allow CONTENT_LENGTH to be present but empty https://review.openstack.org/455710
14:02:42 dansmith but we have no connection information for the upcall
14:03:45 mriedem dansmith: does the cell conductor nova.conf have api_database set?
14:03:52 dansmith no
14:04:01 mriedem ok, just [database]connection = cell db
14:04:04 edleafe So the cell conductor talk to the super conductor?
14:04:15 mriedem edleafe: no
14:04:24 dansmith edleafe: they're on different busses, and the lower layer has no information about how to connect to the top layer
14:05:17 mriedem jaypipes: so for the claims in scheduler spec and the overhead stuff, couldn't we take the overhead values from the virt driver and adjust the allocations in the resource tracker?
14:05:33 mriedem if the overhead pushes us over what's available for inventory on that provider, we get a 409 i think, and then we fail the build
14:06:30 dansmith ugh
14:06:34 mriedem i would think if you had reserved some space for ram and disk for the provider itself, then the chances of hitting overhead 409s once we pick a host might be slim
14:06:36 dansmith I really hate that
14:06:43 mriedem dansmith: see my other options in the spec :)
14:06:47 mriedem there are worse options
14:07:24 openstackgerrit Matt Riedemann proposed openstack/nova master: Add online data migration for populating services.uuid https://review.openstack.org/454899
14:10:12 jaypipes mriedem: yes, we could possibly do that
14:10:40 jaypipes mriedem: I don't like it, same as dansmith, but not sure a better solution
14:10:59 dansmith so the point being,
14:11:04 mriedem i figured that would be better than conductor doing an rpc call into the compute to get the overhead values before posting allocations
14:11:18 dansmith we tell people to make sure they account for the slack in the reserved amounts on each host to keep the chances of a failure down?
14:11:25 mriedem dansmith: yeah
14:11:27 mriedem it sucks
14:11:28 mriedem i know
14:11:42 dansmith the conductor->compute call isn't so terrible,
14:11:52 dansmith it's just that we can't make it until we have a compute
14:11:55 mriedem right
14:11:55 dansmith which lengthens our window
14:12:05 cdent if we wiggle the reserved then we can't add the overhead to the allocations, right?
14:12:17 cdent it's one or the other
14:12:21 mriedem so conductor asks scheduler for a host, conductor gets the host mapping, rpc calls to the compute with the flavor to get the overhead, and uses that to post the allocations to placement,
14:12:28 mriedem if that fails, we have to go back through the scheduler again for a new host
14:12:36 dansmith cdent: hmm, yeah, placement won't let you eat the reserved amount I guess right?
14:12:42 cdent dansmith: correct
14:12:45 dansmith yeah
14:13:37 cdent I left a big comment there about quota too, not sure if/how that fits in
14:13:41 mriedem i liked the idea of posting the allocations from the scheduler where if we needed to retry we already have the list of filtered hosts, but we know that's a toss up perf wise
14:14:01 mriedem if we have to rpc call into the compute to get overhead, i think we then have to move everything into conductor
14:14:08 dansmith mriedem: well, and scheduler calling to compute is worse than conductor
14:14:09 dansmith much worse
14:14:10 dansmith yeah
14:15:06 dansmith so, another way to look at this:
14:15:24 dansmith we're talking about having resource overrides in the flavor
14:15:53 dansmith we could also just say that the drivers can't calculate different values for the resources, and have to build the vm from the things they're given,
14:16:00 bauzas sorry, was afk
14:16:08 dansmith which in the case of hyperv means you get $mem fewer MBs of disk,
14:16:13 dansmith and in the case of libvirt, you get one fewer vcpu
14:16:34 dansmith and if you don't want that as an operator, then you override the actual values for those with room for the slack, leaving the display values as what people will really get
14:16:56 dansmith for people that really use the same flavor for two hypervisor types (if that really happens) then things get ugly
14:17:18 dansmith but I kinda feel like the cloudy approach here is to not be as snowflake-y on the virt side
14:17:26 bauzas could someone tell which problem you folks are discussing ? #1 reschedules in a cellsv2 world or #2 overhead values for instance given by virt drivers ?
14:17:31 mriedem that also pushes a lot of complexity on the operator
14:17:37 dansmith it does, and that sucks
14:17:39 mriedem bauzas: #2
14:18:15 dansmith mriedem: so, we should probably go the extra-call-to-compute route for now and if that ends up being too expensive, then punt later
14:18:31 dansmith we already do that for things like getting predicted-but-never-correct bdm device names right?

Earlier   Later