| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-25 | |||
| 15:22:57 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Ignore sqla-migrate inspect.getargspec deprecation warnings on py36 https://review.opendev.org/684781 | |
| 15:25:34 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/stein: Handle legacy request spec dict in ComputeTaskManager._cold_migrate https://review.opendev.org/684407 | |
| 15:27:34 | mriedem | gregwork: nope | |
| 15:27:52 | mriedem | could throw it at the bottom of https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc | |
| 15:28:30 | mriedem | (i just did) | |
| 15:28:54 | gregwork | i saw saw that :) | |
| 15:28:56 | gregwork | *just | |
| 15:29:46 | gregwork | getting our windows team members to become familiar with the openstack client and one of the things they need for new instances is to nova get-password server rsa-key .. trying to streamline the tools they start off with | |
| 15:30:24 | mriedem | yeah definitely want new people using osc if they can rather than the mish-mash of per-project CLIs | |
| 15:30:32 | mriedem | but someone would have to add that to osc | |
| 15:30:48 | mriedem | it would be a pretty easy addition to osc | |
| 15:40:28 | mriedem | gregwork: the question is if you have developers? | |
| 15:41:37 | gregwork | so its early days for my org, it would probably be me writing something like that. We are in the middle of a prod build of openstack where the broader organization must now get involved. | |
| 15:42:12 | gregwork | it would also need to be something id get our vendor to backport | |
| 15:42:19 | mriedem | ok, shouldn't really be too hard, it's mostly just argparse stuff in osc and it calls through to the novaclient python api bindings | |
| 15:42:30 | gregwork | we are definitely not brave enough to run upstream in production | |
| 15:42:34 | mriedem | backport how far? queens? | |
| 15:42:42 | mriedem | ah red hat | |
| 15:42:51 | gregwork | wha .. who where ? | |
| 15:42:56 | gregwork | :D | |
| 15:43:00 | mriedem | if only we (nova) had some red hat developers around | |
| 15:44:24 | gregwork | indeed | |
| 15:49:13 | mriedem | mlavalle: routed networks is not supported in nova yet, no - see https://review.opendev.org/656885 | |
| 15:49:46 | mriedem | i don't plan on actively pushing that forward | |
| 15:50:50 | mlavalle | mriedem: if my employer needs, this, could we push it forward in U? | |
| 15:52:40 | mriedem | you'll have to talk to the boss, efried | |
| 15:53:19 | mlavalle | mriedem: thanks for following up :-) | |
| 15:53:24 | mriedem | yw | |
| 15:53:31 | efried | mlavalle: Depends who your employer is | |
| 15:53:35 | efried | I kid, I kid. | |
| 15:53:53 | mlavalle | would you be open to use pushing this forward? | |
| 15:53:59 | efried | what are we talking about? | |
| 15:54:01 | mlavalle | to us^^^ | |
| 15:54:36 | kashyap | efried: https://review.opendev.org/#/c/656885/ | |
| 15:54:58 | kashyap | Ah, you were jesting | |
| 15:55:21 | efried | Has there been a bp and/or spec at any point? | |
| 15:55:52 | efried | is this related? https://review.opendev.org/#/c/263898/ | |
| 15:56:19 | mlavalle | this is the approved spec: http://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/neutron-routed-networks.html? | |
| 15:56:46 | mlavalle | yeah same thing.... | |
| 15:57:44 | efried | mlavalle: I'm toying with ideas for ways to dramatically constrain the scope of what we commit to in ussuri, on the theory that stakeholders (such as your employer, whoever that may be) would rather get a hard "no" up front than have a bp/spec approved and have NO IDEA whether it's going to land, based on our track record of landing a random 60-ish percent of the things we approve, with no relation to the supposed prioritization | |
| 15:58:15 | mriedem | mlavalle works for verizon media with jroll and penick and the gang | |
| 15:58:46 | mlavalle | LOL, I didn't know we are the gang | |
| 15:58:47 | mriedem | the routed networks stuff in that spec back in newton was a lot more grandiose with refactoring all of the port creation stuff in conductor - a lot of stuff johnthetubaguy worked on while at OSIC | |
| 15:59:09 | mriedem | what functionally landed on the nova side was actually a really small change to allow deferred fix ip allocation | |
| 15:59:27 | mriedem | for which https://review.opendev.org/#/c/641670/ is a follow up | |
| 15:59:44 | mriedem | the actual routed networks thing in nova is a lot more complicated, | |
| 15:59:53 | efried | Beyond that, I have no objection to this being a thing in general. But I haven't yet figured out a reasonable way to propose and effect such a constrained scope. | |
| 16:00:33 | mriedem | with the routed networks stuff, i'd say showing it working in a multinode ci job would be table stakes since there is a lot of orchestration and setup involved between nova, neutron and placement | |
| 16:00:48 | mriedem | but lots of people have wanted that feature for a long time (godaddy also) | |
| 16:01:02 | mriedem | so that you can scale out neutron, | |
| 16:01:06 | mriedem | efried: think of it like cells v2 for neutron | |
| 16:01:47 | mriedem | constrain a network to a host aggregate and when creating a server on that network, make nova smart enough to only ask the scheduler for hosts from that network | |
| 16:02:00 | mriedem | rather than randomly pick some host in another aggregate that can't talk to that network | |
| 16:02:29 | mriedem | i wouldn't be surprised if people do that with customer filters and scheduler hints today | |
| 16:02:44 | mlavalle | Neutron already creates the data in placement. what we need now is for Nova to use that data | |
| 16:02:57 | mlavalle | during the scheduling process | |
| 16:03:00 | mriedem | yup, that's what my patch started | |
| 16:03:16 | mriedem | link the requested network(s) to a resource provider aggregate and pre-filter the placement results using that | |
| 16:03:29 | efried | Above is explaining "what" and "why", which is great. Right now though I'm only focused on "how much". The "why" will become relevant when arguing whether this thing should bump some other thing out of scope for ussuri. | |
| 16:05:12 | mriedem | if verizon can somehow say they'll use vpmems would that sweeten the deal? | |
| 16:05:48 | mriedem | i kid | |
| 16:06:00 | mriedem | cyborg is probably the biggest ticket thing that should be pushed forward in ussuri | |
| 16:06:07 | mriedem | given the years of talk | |
| 16:06:29 | mriedem | granted, routed networks was from newton but who's keeping track | |
| 16:09:35 | mlavalle | All I can add to this is that we really, really need this | |
| 16:10:26 | mlavalle | how can we get this topic in the "how much" consideration? | |
| 16:10:35 | cdent | people | |
| 16:11:00 | mlavalle | well, I already said we would push it forward | |
| 16:11:12 | mlavalle | that's how the conversation started | |
| 16:12:00 | mriedem | mlavalle: how hard would it be to get a 2-node CI job setup which sets up a host aggregate for one node and a host aggregate for another and a separate network for each aggregate so the neutron+placement stuff happens? | |
| 16:12:32 | cdent | mlavalle: sorry I was joining in late and didn't mean to sound snarky (if that's the way it sounded) | |
| 16:12:37 | mriedem | i think work could be done toward the eventual goal that needs to happen anyway | |
| 16:13:20 | mlavalle | cdent: oh, no I didn't take it as "snarky".... I was just catching up ;-) | |
| 16:13:26 | mriedem | maybe it's just a matter of a tempest test against a 2 node job? tempest would create the per-node network and aggregate right? | |
| 16:13:42 | mriedem | the neutron would wire up the placement resource provider aggregate? | |
| 16:13:46 | mriedem | *then | |
| 16:13:50 | mlavalle | correct | |
| 16:14:07 | mriedem | after that it's just a matter of writing a tempest test that makes sure the server gets created on the correct host | |
| 16:14:12 | efried | mlavalle: honestly, our poor track record has more to do with reviewer resource than developer resource | |
| 16:14:16 | efried | bbiab | |
| 16:14:33 | mriedem | having functioning CI goes a long way in reviewer confidence | |
| 16:14:43 | mriedem | numa live migration wouldn't have made it this cycle (again) without that | |
| 16:15:01 | mlavalle | mriedem: this is a great point | |
| 16:15:13 | mlavalle | we can start there | |
| 16:15:37 | mriedem | a deterministic tempest test for routed networks would be, i think, trying to create a server with a network in aggregate 1 but requesting a host in aggregate 2 and seeing it blow up during scheduling | |
| 16:15:47 | mriedem | the test would assert the server fails due to NoValidHost | |
| 16:15:56 | mlavalle | yeap | |
| 16:16:31 | mriedem | with 2.74 in train that's pretty easy https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id66 | |
| 16:17:26 | mriedem | so you (or whoever) could get started with the tempest test which would actually assert that the server gets created on the wrong host for the network (port binding might actually fail i'd guess) until nova supports routed networks during scheduling | |
| 16:17:30 | mlavalle | yeah, thanks for pointing that out | |
| 16:18:23 | mriedem | david bingham on https://review.opendev.org/#/c/656885/ is from godaddy and he and another guy were at the last ptg asking about this as well - it was the only thing they talked about while at the ptg | |
| 16:18:26 | mriedem | coincidentally | |
| 16:18:37 | mriedem | so, maybe verizon and godaddy SIG UP on this | |
| 16:18:37 | mlavalle | efried_rollin: developer resource is a start, isn't it? | |
| 16:18:45 | mriedem | oh wait, | |
| 16:18:47 | mriedem | not SIG | |
| 16:18:49 | mriedem | POP UP TEAM UP! | |
| 16:19:06 | mriedem | cdent: as TC emeritus you can correct me if i'm wrong | |
| 16:19:32 | cdent | for routed networks pop up team would be the team-type of the the day | |
| 16:19:40 | mriedem | du jour?! | |