| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-23 | |||
| 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 | |
| 20:52:36 | mriedem | unless we are going to build a ProviderTree object or something | |
| 20:52:55 | efried | mriedem: Do you have access to a SchedulerReportClient from wherever you are? | |
| 20:53:01 | mriedem | sure | |
| 20:53:03 | efried | mriedem: If so, then yeah, you have that ability with a single call. | |
| 20:54:07 | efried | mriedem: https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L986 would be that call. | |
| 20:54:36 | efried | The 'ensure_root' part is slightly uncomfortable, but you know the root exists when you call this. | |
| 20:54:42 | efried | And we can factor that out of there if it's an issue. | |
| 20:57:06 | munimehan | All, when nova generates VM definition it don't generate the PCIs for guest addresses, is there a way to manipulate those to make it in sync for the interface order | |
| 20:57:58 | arvindn0_ | efried: good suggestion...will look into that. | |
| 20:58:59 | arvindn0_ | btw currently in the image_props_filter.py we dont have SchedulerReportClient...we can create and get access...but now we have 2 API calls from the filter.... | |
| 21:00:15 | efried | arvindn0_: Do you have a resourcetracker? | |
| 21:00:23 | efried | arvindn0_: or a schedulerclient? | |
| 21:01:00 | arvindn0_ | nope...currently the filters make 0 api calls....so no clients of any sort | |
| 21:01:44 | efried | arvindn0_: But we were going to have to call into placement one way or another (unless we went with option 1 and just blocked the whole thing). | |
| 21:02:15 | efried | arvindn0_: So yeah, you're not getting around that. And those should be pretty quick calls, one would hope. | |
| 21:02:49 | efried | arvindn0_: The set logic around required vs forbidden will be a little tricky. | |
| 21:02:54 | arvindn0_ | yup...i was just pointing out that we might now have to make 2 calls, but like you said they should be quick since they are focussed on only the current compute node | |
| 21:03:26 | arvindn0_ | we dont support forbidden traits in images i think... | |