| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-05 | |||
| 19:58:43 | prometheanfire | cool | |
| 19:58:44 | jaypipes | efried: you want >1 cinder volumes? then create them in cinder and attach them to your compute instance. | |
| 19:58:59 | prometheanfire | if that merges today then the xenapi change can go in tomorrow via bot update | |
| 19:59:04 | jaypipes | efried: there is absolutely no "atomically create 10 volumes in Cinder" command. | |
| 19:59:38 | mriedem | there isn't?! | |
| 19:59:40 | jaypipes | efried: and these kinds of requests that the VNFM would be making are essentially that: requests for a set of related resources to be created as an atomic unit. | |
| 20:00:14 | efried | jaypipes Seems like there should be a way to specify multiple `resources=` keys in a single request, kind of thing. | |
| 20:00:18 | mriedem | how about i request 10 VMs with block_device_mapping_v2 in the request, of size 10, for each entry with different device names so nova creates the volumes! | |
| 20:00:29 | jaypipes | incidentally, this is why there's no atomicity guarantees that *any* orchestrator provides. not k8s, not heat, not IBM "smart" cloud orchestrator. not any of them. | |
| 20:00:47 | mriedem | does sco still exist? | |
| 20:00:56 | jaypipes | heh, no idea. | |
| 20:01:03 | smcginnis | mriedem: I hear they own the copyright to OpenStack. | |
| 20:01:04 | efried | only as a lawsuit troller | |
| 20:01:18 | mriedem | they do have a snapshot api for vmware instances | |
| 20:01:22 | mriedem | which is different from os-createImage | |
| 20:01:27 | mriedem | different, and superior | |
| 20:02:03 | efried | Yeah, less concerned about atomicity at the moment. | |
| 20:02:22 | efried | I mean, what if I want two different GPUs with different specialties? | |
| 20:03:04 | efried | / capabilities | |
| 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: 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? | |