| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-23 | |||
| 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. | |
| 20:43:46 | melwitt | yikun: hi, I know you're not around right now but FYI your blueprint "Add host/hostId to instance action events API" has been added to a review runway https://etherpad.openstack.org/p/nova-runways-rocky | |
| 20:44:37 | arvindn0_ | Initial instance launch happens with SRIOV_VF:1 allocated, rebuild lauches with modified request with traits=HW_NIC_OFFLOAD_X, so basically we want the instance to be allocated the second nic | |
| 20:45:30 | arvindn0_ | but the original allocation happens against nic1 and since in rebuild the original allocations are not changed, we have wrong allocations | |
| 20:46:09 | arvindn0_ | mriedem: is the above scenario an issue if we use GET /resource_providers/{rp_uuid}/traits approch? | |
| 20:49:28 | mriedem | arvindn0_: did you see efried's reply in the mailing list? | |
| 20:50:07 | mriedem | even with efried's suggestion, that scenario is likely a gap yes | |
| 20:50:40 | arvindn0_ | mriedem: trying to figure out the mailing list...i only get digests....do you have a link? | |
| 20:50:44 | mriedem | we need to have some way of knowing, will a rebuild with a new image result in new allocations and if so, fail the rebuild | |
| 20:51:13 | mriedem | you can change your subscription to not be digests :) | |
| 20:51:24 | mriedem | http://lists.openstack.org/pipermail/openstack-dev/2018-April/129734.html | |
| 20:51:57 | mriedem | arvindn0_: also, what you're describing above is this bug https://bugs.launchpad.net/nova/+bug/1763766 | |
| 20:51:57 | openstack | Launchpad bug 1763766 in OpenStack Compute (nova) "nova needs to disallow topology changes on image rebuild" [Medium,Triaged] | |
| 20:51:58 | efried | mriedem, arvindn0_: With what I suggested, you will still know that. Because you know the RPs you've already allocated from (and which you haven't). | |
| 20:52:23 | mriedem | efried: i'm not sure we do, we just have the root provider uuid in the scheduler filter | |