Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-09-25
14:58:09 mriedem https://review.opendev.org/#/c/684769/
15:03:16 openstackgerrit Martin Midolesov proposed openstack/nova master: Implementing graceful shutdown. https://review.opendev.org/666245
15:06:14 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Ignore warning from sqlalchemy-migrate https://review.opendev.org/684772
15:06:15 openstackgerrit Stephen Finucane proposed openstack/nova master: tox: Use common 'command' definition for unit tests https://review.opendev.org/684774
15:06:15 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Nuke OS_STDOUT_CAPTURE, OS_STDERR_CAPTURE https://review.opendev.org/684773
15:06:16 openstackgerrit Stephen Finucane proposed openstack/nova master: tox: Stop overriding the 'install_command' https://review.opendev.org/684775
15:06:30 openstackgerrit Balazs Gibizer proposed openstack/nova stable/pike: Delete instance_id_mappings record in instance_destroy https://review.opendev.org/684658
15:06:32 stephenfin mriedem: You'd asked for the first of those last week ^
15:07:19 mnaser mriedem: ouch, i think it should be easy to fix .. i hope :X
15:10:17 mriedem stephenfin: so about that,
15:10:30 mriedem i was trying to do that last week myself and found the warnings go away for py27 but not py36 runs
15:12:17 mriedem stephenfin: comments in there, but the py removal is wrong, and we should split fixing that out since it's on stable branches
15:13:56 stephenfin mriedem: Oh, so it is (called py). My eyes completely glazed over that \o/
15:14:09 stephenfin fix coming right up
15:14:40 mriedem stephenfin: also a question in the nuke patch after that
15:15:27 openstack bug 1813147 in OpenStack Compute (nova) "p35 jobs are failing with subunit.parser ... FAILED" [High,In progress] https://launchpad.net/bugs/1813147 - Assigned to Balazs Gibizer (balazs-gibizer)
15:15:27 mriedem track that warning ignore patch against bug 1813147 as well
15:15:28 mriedem please
15:18:54 mriedem dansmith: care to get https://review.opendev.org/#/c/684140/ so the cross_az_attach func test patch can be unblocked?
15:19:20 dansmith oh sorry did I miss that yesterday?
15:21:55 gregwork is there an equivalent of nova get-password in the openstack client
15:22:55 openstackgerrit Stephen Finucane proposed openstack/nova master: tox: Use common 'command' definition for unit tests https://review.opendev.org/684774
15:22:55 openstackgerrit Stephen Finucane proposed openstack/nova master: Ignore warning from sqlalchemy-migrate https://review.opendev.org/684772
15:22:56 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Nuke OS_STDOUT_CAPTURE, OS_STDERR_CAPTURE https://review.opendev.org/684773
15:22:56 openstackgerrit Stephen Finucane proposed openstack/nova master: tox: Stop overriding the 'install_command' https://review.opendev.org/684775
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?

Earlier   Later