| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-23 | |||
| 19:18:16 | mriedem | ? | |
| 19:19:44 | esberglu | mriedem: Yep working on it right now | |
| 19:25:18 | arvindn0_ | mriedem: does the runway queue allow for closure on the specs? | |
| 19:26:27 | arvindn0_ | mriedem: i was thinking we can discuss the spec in the runway if thats the case. Also, we are trying to make progress on other patches which hopefully can also be reviewed in the runway | |
| 19:28:32 | mriedem | arvindn0_: my understanding is that runways are for things that are ready to go | |
| 19:28:37 | mriedem | and i wouldn't consider this ready to go | |
| 19:28:59 | mriedem | btw, i'm trying to summarize alternatives for this in the ML to get some visibility | |
| 19:30:53 | openstackgerrit | Merged openstack/nova master: Add root and parent provider uuid to group by clause https://review.openstack.org/562379 | |
| 19:32:32 | arvindn0_ | mriedem: thanks. should be fine to move to end of runway...i guess the runway maintainer is going to make this change | |
| 19:38:39 | jaypipes | artom: if you have a minute, would you mind giving your thoughts on https://review.openstack.org/#/c/546713/1/os_traits/compute/net.py please? | |
| 19:39:09 | artom | jaypipes, looking | |
| 19:40:01 | jaypipes | artom: cheers | |
| 19:40:09 | artom | jaypipes, I'd go with gibi | |
| 19:40:35 | artom | Maybe a "real" example would make more sense: | |
| 19:40:55 | artom | 1. Just interface attachment: nova interface-attach port-id=blah | |
| 19:41:09 | artom | 2. Tagged attachment: nova interface-attach port-id=blah,tag=foo | |
| 19:44:39 | openstackgerrit | Arvind Nadendla proposed openstack/nova-specs master: Handle rebuild of instance with new image https://review.openstack.org/560718 | |
| 19:47:18 | arvindn0_ | jaypipes: can you add your thoughts on the above BP? if we can get direction from you whether modifyiny `GET /allocation_candidates` by adding an in_tree parameter AND make resources optional is something we can agree to, i can start thiking in that direction | |
| 19:52:15 | openstackgerrit | Merged openstack/nova master: Leave a hint when populate_schema fails https://review.openstack.org/562757 | |
| 19:54:43 | jaypipes | arvindn0_: I don't have any thoughts on the above BP. I don't know much about rebuild at all and trust everything mriedem says. | |
| 19:56:05 | artom | Oh hey are we reopening the rebuild with new image can of worms | |
| 19:56:56 | jaypipes | artom: sorry, coming back to you... so I don't understand why that is a particular capability of the virt driver... is there a reason adding metadata about devices is specific to a virt driver? | |
| 19:57:24 | arvindn0_ | jaypipes: are you OK with modifying allocation_candiadates API to not take resources as a required parameter? | |
| 19:57:26 | artom | jaypipes, because the driver is what knows about the actual hardware metadata, like PCI and MAC address for NICs | |
| 19:57:40 | jaypipes | arvindn0_: no, I am not. | |
| 19:57:57 | jaypipes | arvindn0_: if there is nothing to allocate, there's no reason to call GET /allocation_candidates. | |
| 19:58:35 | arvindn0_ | jaypipes: if there are strong opinions against it, then we need to drop that proposal... | |
| 19:59:01 | jaypipes | arvindn0_: ok, gimme a bit. | |
| 19:59:18 | jaypipes | arvindn0_: I see mriedem just posted to the ML. I will respond there. | |
| 19:59:41 | arvindn0_ | no problem...i know rebuild is a can of worms like artom mentioned :) | |
| 20:00:34 | jaypipes | artom: but why is the capability to associated a tag of "foo" with a PCI address something that is virt-driver dependent? | |
| 20:01:00 | dansmith | jaypipes: because the virt driver is what knows the address of the thing | |
| 20:01:10 | dansmith | jaypipes: if you ask for two nics, one tagged as foo and one as bar, | |
| 20:01:18 | artom | jaypipes, because some virt drivers don't have the code for it :) | |
| 20:01:19 | dansmith | only the virt driver knows how and where those are attached | |
| 20:02:01 | artom | (Wasn't trying to be condescending, I swear!) | |
| 20:02:03 | jaypipes | *sigh* | |
| 20:05:42 | jaypipes | dansmith, artom: so you're saying that nova interface-attach port-id=blah,tag=foo only works if specific virt drivers (libvirt only I guess?) are in use for the instance? | |
| 20:06:01 | artom | jaypipes, yes | |
| 20:06:10 | jaypipes | that's lovely. | |
| 20:06:36 | jaypipes | implementation-defined interfaces. | |
| 20:07:04 | dansmith | jaypipes: you know that some virt drivers don't even provide network interface attachments at all right? | |
| 20:07:06 | dansmith | *gasp* | |
| 20:07:13 | artom | I don't disagree, but hasn't that been the case for a while? It's sort of why we have the support matrix in the first place... | |
| 20:07:13 | jaypipes | artom: why doesn't something above the virt layer save the tag information for the interface? | |
| 20:07:44 | dansmith | jaypipes: it does happen above the virt driver level, but it doesn't have sufficient information to be useful | |
| 20:07:45 | artom | jaypipes, it does, and we could conceivably just put "device: {tag: foo}" in the metadata | |
| 20:07:53 | artom | But that's useless for the guest OS | |
| 20:08:07 | jaypipes | why is that useless for the guest OS | |
| 20:08:09 | jaypipes | ? | |
| 20:08:10 | dansmith | jaypipes: if we're attaching a pci nic at pci addres 1.2.3, or a virtio nic in slot 7, or a xenback device at /xenstore/foo/bar -- | |
| 20:08:24 | dansmith | those are the things the guest needs to know which tag applies to which | |
| 20:08:25 | artom | For the guest to do anything useful with that it would need to know something about the hardware "associated" with that tag | |
| 20:08:28 | dansmith | and compute manager can't know that | |
| 20:08:38 | artom | jaypipes, https://notartom.net/2017/06/20/virtual-device-role-tagging-better-explained/ /shameless plug | |
| 20:09:32 | jaypipes | artom: how does EC2 handle this functionality? | |
| 20:10:00 | artom | ^^^ is about boot-time device tagging, but it explains the "why (is that useless to the guest OS)" question | |
| 20:10:05 | artom | jaypipes, it doens't | |
| 20:10:09 | dansmith | by not supporting more than one virt method? | |
| 20:10:31 | artom | jaypipes, wait, ec2... the metadata API? | |
| 20:10:48 | dansmith | he means EC2 the service I believe | |
| 20:10:52 | jaypipes | dansmith: no, how can an EC2 API user inform their guest that a particular NIC is "for this specific network"? | |
| 20:11:15 | dansmith | jaypipes: that's totally different than applying a tag to a thing | |
| 20:11:33 | artom | dansmith, to be fair, that's kinda what tags were made for | |
| 20:11:42 | dansmith | jaypipes: you may impute some meaning from the tag, but that's different | |
| 20:11:49 | jaypipes | exactly what they were made for, actually. | |
| 20:12:09 | dansmith | jaypipes: so lets use the volume case | |
| 20:12:23 | dansmith | jaypipes: doesn't ec2 let you say "this volume will be vdb"? | |
| 20:13:38 | jaypipes | dansmith: you can specify one, but it might rename it behind the scenes. | |
| 20:13:50 | artom | Also, and this may be stupid, but what does EC2 have to do with any of this? | |
| 20:14:06 | dansmith | artom: zero, because they don't do many hypervisors | |
| 20:14:29 | dansmith | jaypipes: can we jump on a hangout here to figure out what the real concern is? because I feel like something must be confused if you're really worried about this | |
| 20:15:33 | dansmith | jaypipes: https://hangouts.google.com/call/Jcmcsrr1qa7qmYfuZ_myAAEE ? | |
| 20:16:26 | dansmith | artom: of course, if jaypipes'll join | |
| 20:16:41 | artom | Of course what? | |
| 20:17:08 | dansmith | artom: join ^ | |
| 20:17:09 | jaypipes | I'm on. | |
| 20:17:46 | artom | dansmith, uh, sure, except it keeps telling me I'm not allowed | |
| 20:18:12 | dansmith | artom: we're on, it's just public | |
| 20:18:41 | artom | Oh hey, the gmail account works | |
| 20:23:33 | melwitt | mriedem: yeah, I guess so. I was thinking similar because it's not clear to me if this has utility beyond abort cold migrate. the alternatives section is empty https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/list-show-all-server-migration-types.html#alternatives | |
| 20:23:55 | mriedem | melwitt: exactly. ok i'll start a thread. | |
| 20:24:01 | melwitt | thanks | |
| 20:28:39 | melwitt | arvindn0_, mriedem: which thing are y'all talking about "moving to the end of the runway" earlier? | |
| 20:28:55 | mriedem | glance-image-traits | |
| 20:28:58 | mriedem | L62 | |
| 20:29:04 | mriedem | end-o-queue | |
| 20:29:08 | arvindn0_ | Support Traits in Glance: https://blueprints.launchpad.net/nova/+spec/glance-image-traits | |
| 20:29:22 | melwitt | oh, I see | |
| 20:29:36 | melwitt | I got confused with the rebuild talk right after it | |
| 20:29:45 | arvindn0_ | we are discussing an ammendement to the originally approved spec... | |
| 20:30:03 | melwitt | gotcha. I see the note in the runways etherpad | |
| 20:30:09 | arvindn0_ | rebuild is related to the amendment :) | |
| 20:30:19 | melwitt | ah, okay | |
| 20:38:20 | melwitt | mriedem: agreed that the host/hostId to instance action events API is the only thing that looks ready for a runway, so I'm gonna move it there | |
| 20:38:35 | mriedem | cool | |
| 20:38:36 | mriedem | http://lists.openstack.org/pipermail/openstack-dev/2018-April/129736.html | |
| 20:38:49 | melwitt | thanks | |
| 20:41:54 | arvindn0_ | mriedem: wanted to quick check something on the scenario 2 i detailed in the comment | |
| 20:43:08 | arvindn0_ | a host with two SRIOV nic. One is normal SRIOV nic, another one with some kind of offload feature. | |