| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-05 | |||
| 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: Move project_id and user_id to Allocation object https://review.openstack.org/500410 | |
| 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: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 | dansmith | I don't follow | |
| 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: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. | |
| 21:17:41 | jaypipes | guys, can I hit pause on this conversation for 5 minutes so I can finish my braindump? | |
| 21:17:48 | efried | ...with some kind of "generic device manager" which talks to Placement | |
| 21:17:50 | efried | sure. | |
| 21:19:26 | dansmith | efried: definitely, to the extent we can | |
| 21:20:22 | openstackgerrit | Dan Smith proposed openstack/nova-specs master: Add migration-allocations spec https://review.openstack.org/498510 | |
| 21:59:53 | cfriesen__ | when calling a remotable object function, does nova-conductor do a keystone token validation? | |
| 22:01:40 | dansmith | no | |
| 22:21:40 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Spec for flavor description https://review.openstack.org/501017 | |
| 22:21:42 | mriedem | Kevin_Zheng: ^ | |
| 22:23:43 | jaypipes | efried, dansmith: sorry, dinner got in the way.. | |
| 22:23:55 | jaypipes | efried, dansmith: dumped some thoughts here: http://paste.openstack.org/show/620456/ | |
| 22:24:46 | efried | jaypipes ... | |
| 22:25:54 | jaypipes | efried: yes? | |
| 22:26:18 | efried | jaypipes Sorry, that's "Message received, processing..." | |
| 22:26:30 | jaypipes | efried: ack | |
| 22:29:19 | efried | jaypipes Yes, just so. But I thought this was the part we were all in sync with. The part we hadn't yet come to grips with was the hand-waving on L35-6. | |
| 22:30:14 | jaypipes | efried: no, I can come up with an *internal* representation for the request. what I can't figure out is how to map that to a *single* REST API call. | |
| 22:30:24 | efried | Right. | |
| 22:31:48 | efried | jaypipes Don't kill me don't kill me but... what if I numbered the query param keys? | |
| 22:32:10 | efried | resources1=...&traits1=...&resources2=...&traits2=... | |
| 22:32:34 | jaypipes | efried: uhm, eww? :) | |
| 22:32:56 | efried | Well, yeah it's eww, that's a given. But it's clear that it could work. | |
| 22:33:07 | efried | It could also conceivably answer the thing where it matters what order we attach devices in... | |
| 22:33:18 | efried | ...which some people care about. | |
| 22:33:34 | jaypipes | efried: not sure I follow why the attachment order matters to the placement API. | |
| 22:33:55 | efried | It doesn't, but when the request comes in, don't those keys come through? Mebbe not, sorry. | |
| 22:35:21 | efried | Anyway, for the general case, non-numbered querystring keys work just fine; in fact they don't even have to be numbers - we just parse the prefix and group by the suffix, whatever it is. | |
| 22:36:14 | jaypipes | efried: the problem with adding this to the placement REST API is that then we're adding a bunch of orchestration-like logic into the placement service. | |
| 22:36:48 | jaypipes | efried: instead of keeping that out of placement and relying on the caller to placement understanding that the request contains a number of "subrequests" that are for specific complex types. | |
| 22:37:07 | efried | jaypipes Yeah, I admit I don't understand what is meant by "orchestration" and where that line is drawn. | |
| 22:37:36 | jaypipes | efried: dealing with lots of resources as a group is orchestration. | |
| 22:38:08 | jaypipes | efried: where the relationship between the resources, the dependencies between them, the constraints that each imposes on each other, etc. that's orchestration. | |
| 22:38:39 | jaypipes | efried: whereas placement is designed to be a fast, efficient method of determining providers of resources for a given simple request for capacity. | |
| 22:41:21 | cdent | jaypipes: can you clarify something for me: I’m not fully grokking why, in your paste, we need to make multiple requests to /a_c ? Is it is because at the point we don’t have a good way to express (in one request) what we want or is there more than that? | |
| 22:42:23 | efried | jaypipes I'm probably being obtuse again, but I still don't really see how what we're talking about here doesn't still fall into that description. Placement is designed to grab resources from multiple resource providers. From a way-zoomed-out view, saying "you can only get stuff from a given resource class from a single provider" seems like an arbitrary limitation. Zoom back in, and it's one that seems imposed because we | |
| 22:42:23 | efried | 're having trouble expressing it under the current design, not because it inherently crosses the line to "orchestration". | |
| 22:42:47 | cdent | jaypipes: on line 50 it is GROUP_A on the first go round and GROUP_B on the second? | |
| 22:43:37 | efried | cdent Yeah; and/or L49 could be different egress bandwidth numbers | |
| 22:43:44 | cdent | thanks | |
| 22:44:01 | jaypipes | cdent: a couple reasons for that. the first is that it's difficult for me to map the concept of related sub-requests in a single REST API call (again, without resorting to some DSL-ish request payload) and b) because I suspect these types of use cases are just the tip of the iceberg and that the logic that relates various things with each other (GPUs, FPGAs, NIC HA groups, etc) will be different and not possible to cleanly express with simple | |
| 22:44:01 | jaypipes | query parameters. | |
| 22:44:51 | jaypipes | cdent: and yes, it would be GROUP_A on the first go around and GROUP_B on the second. | |