Earlier  
Posted Nick Remark
#openstack-nova - 2019-09-25
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 mlavalle efried_rollin: developer resource is a start, isn't it?
16:18:37 mriedem so, maybe verizon and godaddy SIG UP on this
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?!
16:19:46 cdent so sorry, yes
16:20:01 cdent i used up all my french recently
16:20:12 mriedem TC santioned collaborama du jour
16:20:16 mriedem is what i'm going to go with
16:20:31 cdent i believe pop up came about in response to encrypted volume efforts failing to get traction
16:20:44 cdent I fail to get traction understanding why a different name helps
16:20:45 mriedem s/volume/image/ but yeah
16:20:53 mriedem because SIGs were too formal dude
16:22:19 cdent I have really mixed feelings on all this stuff.
16:22:30 cdent On the one hand it is wrong that nova gatekeeps so much
16:22:39 cdent but on the other hand, if nova doesn't gate keep things go sideways
16:24:22 mriedem mlavalle: i added you to https://review.opendev.org/#/c/656885/3 and left a comment there with link to this irc conversation if that helps
16:24:54 mlavalle mriedem: it definitely does. Thanks you very much!
16:29:14 gregwork is it terribly difficult to to fiddle with libvirt <features> and <cpu> in nova?
16:29:30 gregwork i need to figure out how to set these to fool windows into not being terrible at everything because it detects its in kvm
16:29:31 gregwork https://pastebin.com/jw8Duq9S
16:29:51 gregwork it actively checks to see if its in kvm and turns off stuff
16:30:02 gregwork thats how i work around it using regular libvirt
16:30:47 mriedem gregwork: gpu?
16:31:04 mriedem gregwork: see https://review.opendev.org/#/c/579897/
16:31:42 gregwork so not an nvidia badness, i want to enable HyperV server role in my guest so I can run the cloud-base.it image generation git project
16:31:49 gregwork and it wont let you do that becuase HyperV detects KVM
16:31:53 gregwork and says "newp!"
16:32:18 gregwork this thing: https://cloudbase.it/windows-server-2016-openstack-images/
16:32:46 mriedem well i think you're looking for the img_hide_hypervisor_id image property or the hide_hypervisor_id flavor extra spe
16:32:48 mriedem *spec
16:33:03 mriedem the image property isn't in queens but the flavor extra spec might be
16:33:19 mriedem nope https://blueprints.launchpad.net/nova/+spec/hide-hypervisor-id-flavor-extra-spec was rocky
16:33:39 gregwork and there is no way to pass libvirt domain customizations
16:33:52 gregwork even kludgy ones :)
16:33:57 gregwork or even qemu execution lines
16:34:10 mriedem not through the compute api no
16:34:29 mriedem that's not really...cloud
16:35:29 artom Don't we have image props or something to make Windows happy?
16:35:54 mriedem artom: read scrollback
16:36:03 gregwork ever since they started planning to go to core based licensing instead of socket they have implemented some draconian things to prevent the potential for nested virtualization
16:36:11 openstackgerrit Merged openstack/nova master: docs: Scrub available quotas https://review.opendev.org/670125
16:36:31 gregwork especially since you can do performant nested virt with kvm on intel xeon e3-v4 processors using vmcs shadowing and device passthrough of network/storage
16:38:05 gregwork in our lab using those chips and passing through a virtual function off our nic to the L1 guest (hypervisor) we were only seeing a 5-10% difference in perf
16:38:10 gregwork it was really interesting
16:38:27 gregwork this is how hitachi does LPAR's on their x86_64 platform
16:39:04 gregwork hardware logical partitions which can run performant guests using intel xeon chips
16:39:17 gregwork anyhow it sucks i cant fiddle with this on queens
16:39:19 gregwork :/
16:40:51 mriedem i can't believe sean-k-mooney isn't around to chat about this
16:41:07 mriedem gregwork: well you could if you $$$ your vendor to backport a feature
16:43:32 artom mriedem, next time dinner first
16:47:00 mriedem dinner? you mean lunch?
16:47:05 mriedem what are you 80?
16:47:45 artom In my mind :(
16:53:35 mriedem stephenfin: i'm not sure we need this https://review.opendev.org/#/c/684781/ - it appears to already be fixed in master, though i guess we might want it just for backports
16:53:37 mriedem i left some notes inline
17:02:59 gmann mriedem: ohk. did you push the fix to tag tempest on pike gate ?
17:03:15 mriedem gmann: yup
17:03:41 gmann thanks. got it
17:09:17 openstackgerrit Matt Riedemann proposed openstack/nova master: Ignore sqla-migrate inspect.getargspec deprecation warnings on py36 https://review.opendev.org/684781

Earlier   Later