| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-19 | |||
| 08:21:28 | omkar_telee | yes, we use pacemaker | |
| 08:26:31 | omkar_telee | rpodolyaka : no, we dont use pacemaker | |
| 08:26:40 | omkar_telee | its just haproxy and vip | |
| 08:54:18 | openstackgerrit | Stephen Finucane proposed openstack/python-novaclient master: Explicitly set 'builders' option https://review.openstack.org/457929 | |
| 08:54:18 | openstackgerrit | Stephen Finucane proposed openstack/python-novaclient master: doc: Remove cruft from conf.py https://review.openstack.org/457930 | |
| 10:21:31 | openstackgerrit | Zhaokun Fu proposed openstack/nova-specs master: fix typos https://review.openstack.org/458001 | |
| 10:22:48 | openstackgerrit | Alex Xu proposed openstack/nova master: Add check to ensure the versioned_methods are sequential https://review.openstack.org/458004 | |
| 10:29:15 | openstackgerrit | Ritesh proposed openstack/nova master: Add image flatten when unshelve rbd image backend https://review.openstack.org/457886 | |
| 10:44:30 | openstackgerrit | Zhaokun Fu proposed openstack/nova master: fix typos https://review.openstack.org/458016 | |
| 10:44:54 | johnthetubaguy | sfinucan: do you have more context on this one? https://review.openstack.org/#/c/430026 | |
| 10:45:39 | sfinucan | johnthetubaguy: What particular aspects of it? | |
| 10:46:04 | johnthetubaguy | sfinucan: added some questions on the patch | |
| 10:46:16 | johnthetubaguy | sfinucan: basically, I am trying to workout if we are using the API correctly | |
| 10:47:23 | openstackgerrit | Zhaokun Fu proposed openstack/nova-specs master: fix version typo https://review.openstack.org/458019 | |
| 10:48:20 | johnthetubaguy | I may have found some more context in https://bugs.launchpad.net/openstack-api-site/+bug/1242019 | |
| 10:48:20 | openstack | Launchpad bug 1226279 in openstack-manuals "duplicate for #1242019 document multiprovidernet extension" [Medium,Fix released] - Assigned to Diane Fleming (diane-fleming) | |
| 10:48:25 | johnthetubaguy | "For these attributes validation rules are identical to the provider networks extension. Obviously both extensions cannot be used at the same time." | |
| 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 | dansmith | which lengthens our window | |
| 14:11:55 | mriedem | right | |
| 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 | |