Posted	Nick	Remark
#openstack-nova - 2017-09-05
20:03:11	mriedem	ask cyborg
20:03:52	efried	I don't know what that means
20:04:13	mriedem	https://wiki.openstack.org/wiki/Cyborg
20:04:33	mriedem	https://review.openstack.org/#/c/448228/
20:04:59	mriedem	jaypipes: is Roman Dobosz still around?
20:05:09	mriedem	oh nvm
20:05:10	mriedem	no
20:05:13	jaypipes	mriedem: no
20:05:21	mriedem	he was osic?
20:05:36	jaypipes	no
20:05:47	jaypipes	just got moved to a super-special-secret internal Intel project
20:06:04	efried	Okay, so IIRC, it's legal in HTTP for a query param key to be repeated, and show up on the server side as a list of values.
20:06:28	jaypipes	efried: show me an EC2, GCE, or Azure ability to request an instance that has multiple GPUs that are different.
20:06:37	jaypipes	efried: yes.
20:06:44	efried	What, because they can't do it, we shouldn't?
20:07:09	efried	I mean, I'm at a clear disadvantage here, having no experience with any of those things.
20:07:13	jaypipes	efried: no, because they can't do it is a pretty good indication that it's not something we should spend a shit-ton of time trying to do ;)
20:07:32	openstackgerrit	Matt Riedemann proposed openstack/nova master: Make xen unit tests work with os-xenapi>=0.3.0 https://review.openstack.org/500968
20:07:36	efried	What if it's not a shit-ton of time?
20:07:50	jaypipes	efried: if it wasn't, you'd have done it already.
20:08:03	mriedem	prometheanfire: https://review.openstack.org/500968
20:08:20	efried	Mebbe I will.
20:08:26	efried	But - okay - will put this down for now as "stated acceptable limitation".
20:09:09	jaypipes	efried: all of these feature requests are basically for NFV use cases, anyway... which is hardware-defined software as I've said before. It's not cloud in as much as it's not abstraction. It's basically just automating the installation of \a very specific hardware environment.
20:10:47	efried	jaypipes So can I have a VM on more than one network?
20:11:03	jaypipes	efried: you can do that *now*...
20:11:48	efried	jaypipes Right, but when everything's placement, how am I gonna say "give me one VF from physnet A and one VF from physnet B" ?
20:12:22	jaypipes	efried: I don't know.
20:12:39	openstackgerrit	Lee Yarwood proposed openstack/nova master: libvirt: Refactor encryptor attach and detach calls https://review.openstack.org/460243
20:12:43	jaypipes	efried: I've been staring at a pastebin for 2 hours trying to think of how to represent that request.
20:12:58	efried	I mean, per earlier conversation with sean-k-mooney, I'll create one neutron port on each physnet and stuff 'em both into the spawn request; but somebody's gonna have to get both of those guys into placement somehow.
20:13:13	jaypipes	efried: without inventing YET ANOTHER orchestration DSL ala Kubernetes pod templates, Heat templates, TOSCA, and CloudFormation.
20:13:33	jaypipes	efried: which... oh wait! are orchestration frameworks, not compute infrastructure services. :)
20:18:14	jaypipes	efried_bbiab, edleafe, dansmith: I'm getting close to saying "fuck it, let's add another placement REST endpoint called POST /crazypants that accepts a JSON blob representing the innumerable requests for related resources that an orchestrator has"
20:18:53	mriedem	mmm JsonFilter
20:18:55	mriedem	v2
20:20:08	dansmith	jaypipes: maybe we should finish several of the things we started with baseline gains before we freak out about not being able to request two different types of gpus
20:20:35	openstackgerrit	Merged openstack/nova master: Add video type virtio for AArch64 https://review.openstack.org/493822
20:21:04	jaypipes	dansmith: that sounds like an excellent idea.
20:21:11	openstackgerrit	Merged openstack/nova master: Add uuid to migration table https://review.openstack.org/496933
20:23:24	mriedem	dansmith: when is https://review.openstack.org/#/c/498510/ not a WPI?
20:23:26	mriedem	*WIP
20:23:32	mriedem	given patches are merging
20:23:54	dansmith	mriedem: meant to remove it after the last round but ... didn't
20:24:25	openstackgerrit	Dan Smith proposed openstack/nova-specs master: Add migration-allocations spec https://review.openstack.org/498510
20:24:27	dansmith	ther go
20:29:01	openstackgerrit	Jackie Truong proposed openstack/nova master: Add trusted_certs to instance_extra https://review.openstack.org/457711
20:29:24	openstackgerrit	Chris Dent proposed openstack/nova master: WIP: [placement] POST /allocations to set allocations for >1 consumers https://review.openstack.org/500073
20:29:24	openstackgerrit	Chris Dent proposed openstack/nova master: Move project_id and user_id to Allocation object https://review.openstack.org/500410
20:31:35	openstackgerrit	Jackie Truong proposed openstack/nova master: Add trusted_certs to Instance object https://review.openstack.org/489408
20:36:13	melwitt	cdent: heh, I think we all noticed the issues with project_id/user_id on the List object at the time but nobody was sure we would need them per allocation yet
20:36:50	cdent	melwitt: tru
20:36:52	openstackgerrit	melanie witt proposed openstack/nova-specs master: Convert consoles code to use objects framework https://review.openstack.org/500975
20:54:00	efried	jaypipes Maybe different types of GPUs is crazypants, but somebody's gonna object to not being able to put a VM on more than one network.
20:54:27	jaypipes	efried: again, you can already do that.
20:54:34	efried	jaypipes With placement?
20:55:14	efried	Maybe I misunderstood the previous conversation. But I thought that was exactly my point: you can do it today, but you won't be able to do it tomorrow.
20:55:58	jaypipes	efried: no, not with placementy.
20:56:35	jaypipes	efried: you can currently do it with the physnet tag hack in the pci_passthrough_whitelist thing.
20:56:52	jaypipes	efried: and pre-creating Neutron ports with matching physnet tags
20:57:04	jaypipes	efried: and passing those ports in to the Nova boot request
20:58:18	efried	jaypipes Right. And I *thought* part of what we were trying to move toward is getting rid of the current PCI setup in favor of having device (incl. PCI) management revolving around placement.
20:58:22	jaypipes	efried: what you're asking for here is combining the PCI device manager and PCIPassthroughFilter's behaviour of selecting a specific device based on arbitrary tags in the pci_device_request into the placement API.
20:58:58	efried	jaypipes Well.... yes.
20:59:31	efried	I'm asking what's the answer to that ^ gonna be when we've gotten rid of the PCI device manager and moved to Placement nirvana.
20:59:40	jaypipes	efried: I'd like to be storing structurally-correct data in the placement DB, yes. that means nested resource providers, support for traits, and linking the (generic) device manager with support for both setting traits and inventory on a tree of provider records.
21:00:16	dansmith	efried: the people that want to attach multiple physical networks to vms are the same people that ultimately keep most of us employed you know
21:00:25	jaypipes	efried: what I *don't* see a way to do -- again, without crazypants complex DSLs -- is a way to reproduce the PciPassthroughFilter and NUMATopologyFilters as REST API requests to placement
21:00:50	dansmith	efried: I don't think we'll deprecate or remove legacy structures from nova before we have a way to replicate critical behavior like that using something else.. not sure where you got that idea
21:01:37	jaypipes	efried: it's the "how do I request all these related things from the placement REST API" part that has me stumped, not the "please store this structured data in the placement DB" part.
21:02:31	efried	jaypipes Right, I can see how to get the structure/inventory data into placement.
21:02:46	jaypipes	efried: yes. we're both A-OK on that front.
21:03:02	efried	dansmith Sorry it came across that way; I misunderstood some stuff.
21:03:21	jaypipes	efried: however, I still don't know a way to make a request of the placement API without essentially reproducing a domain-specific YAML/JSON language to deal with these complex topology requests.
21:04:55	efried	dansmith When jaypipes was venting about nova not being a cloud orchestration thingy, I thought he was saying being able to request multiple networks was a cloud orchestration thingy behavior, and that nova shouldn't be in that business.
21:05:26	efried	...Which may indeed be what he was saying - just not suggesting that that actually *happen* :)
21:05:48	efried	jaypipes Right, so go with me on this "multiple instances of the `resources=` key" thing for a sec.
21:06:25	dansmith	efried: I think what he was saying was that expecting nova to do lots of steps for you (i.e. determine and reserve multiple resources) as part of a single boot request is really getting into orchestration
21:07:11	openstackgerrit	Brianna Poulos proposed openstack/nova master: Add trusted_certificates to REST API https://review.openstack.org/486204
21:07:25	efried	So I'm confused as to how VCPU+MEM_MB+DISK_GB isn't determining and reserving multiple resources.
21:07:40	dansmith	efried: are you just being sarcastic and difficult now?
21:07:43	dansmith	obviously that's not
21:08:33	efried	No, dansmith, I'm actually this obtuse I'm afraid. Mostly from lack of experience (and a disproportionate lack of inhibition to speak up and ask questions).
21:08:48	efried	But again, apologies, I think I understand what you mean now.
21:08:56	efried	when you said "multiple resources"
21:09:13	efried	you meant "multiple disparate resources of the same class".
21:09:17	efried	mahbad.
21:09:22	jaypipes	efried: hold up... I just thought of something... gimme a minute to flesh it out in my brain.
21:09:58	efried	btw jaypipes I realized as I started typing it why the 'multiple querystring keys' thing is a nonstarter if traits is its own qs key...
21:10:17	dansmith	efried: I mean things like nova going to cinder to create, image, and attach a volume, and to neutron to create multiple ports for a complex network layout, and then to some other service to arrange for party balloons to be sent in ten minutes, and then, finally, to boot the instance
21:11:44	efried	dansmith Rightright. And I think again the reason I'm confused as to why we wouldn't want that is because that (at least the neutron & cinder stuff) is part and parcel of what nova does today, and therefore what I think of as being in nova's purview.
21:12:32	efried	and if we're not taking away at least the neutron &/| cinder stuff, then presumably there's going to have to be an answer for it in the placement world.
21:12:51	efried	which solution, if we're gonna solve it for neutron & cinder, would seem like it oughtta work for whatever.
21:13:03	efried	although I'm *not* suggesting it should go talk to just any external service.
21:14:09	efried	In the case of neutron, the model we have today for VFs is that you create your ports in neutron and then some gizmo in nova knows to associate that with the physnet tags from the [pci]passthrough_whitelist (which is one of jaypipes's bugbears)
21:14:09	dansmith	I don't follow
21:15:06	dansmith	we're not talking about getting rid of neutron or our talking to it, but just not trying to build requests for complex things into nova's API, IMHO
21:15:26	dansmith	I think I've lost track of why this is coming up in the context of placement
21:17:00	jaypipes	I'm still pastebinning. :)
21:17:05	efried	dansmith Well, the premise - which I *think* started with jaypipes (see comments here https://review.openstack.org/#/c/497965/) - is that we want to phase out the PCI device management gorp that's been frankensteined over the years.

Earlier   Later