| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-13 | |||
| 18:23:57 | mriedem | if you haven't yet noticed, the fields in that object are strictly defined | |
| 18:24:10 | openstackgerrit | Eric Fried proposed openstack/nova master: placement: generation in provider aggregate APIs https://review.openstack.org/548249 | |
| 18:24:11 | mriedem | therefore "trait:CUSTOM_FOOBARS" is going to explode if you try to hydrate it into that object | |
| 18:24:11 | openstackgerrit | Eric Fried proposed openstack/nova master: Stop assuming initial provider generation is 0 https://review.openstack.org/548975 | |
| 18:24:11 | openstackgerrit | Eric Fried proposed openstack/nova master: placement: Return new provider from POST /rps https://review.openstack.org/548934 | |
| 18:24:44 | mriedem | so traits in flavors is != traits in image properties because of the wild west vs strict nature of the two | |
| 18:27:37 | mriedem | edleafe: this isn't pointing at the correct blueprint https://review.openstack.org/#/c/552098/ | |
| 18:31:07 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Marker reset option for nova-manage map_instances https://review.openstack.org/539501 | |
| 18:34:44 | dansmith | mriedem: it's not? | |
| 18:35:01 | dansmith | oh, I see | |
| 18:35:20 | dansmith | it's for mine, but we did a different spec for it because api | |
| 18:39:07 | edleafe | dansmith: I'm confused. I thought this was on the same BP as yours | |
| 18:39:39 | mriedem | it's a dependency | |
| 18:39:40 | dansmith | edleafe: we did a spec for it specifically because of the api change, which is technically a different blueprint in launchpad | |
| 18:39:56 | dansmith | edleafe: but I know, it seemed right to me as well | |
| 18:42:02 | edleafe | dansmith: ok, found it | |
| 18:42:09 | openstackgerrit | Ed Leafe proposed openstack/nova master: Add 'member_of' param to GET /allocation_candidates https://review.openstack.org/552098 | |
| 18:42:18 | edleafe | pushed a new rev, with correct BP and shiny new reno | |
| 18:54:56 | melwitt | mriedem: yeah, I was thinking the quota recheck stuff is supposed to be transparent, though the more I thought about it I realized I think some behavior changed, for example, with multi-create, where overquota during recheck results in ERROR instances where it didn't before. but agreed we don't send server delete notifications for a server create fail for overquota during a recheck | |
| 18:55:37 | mriedem | melwitt: "with multi-create, where overquota during recheck results in ERROR instances where it didn't before" - Kevin_Zheng brought that up in denver at the queens ptg | |
| 18:55:40 | mriedem | and was mostly written off | |
| 18:56:14 | mriedem | just reno'ed for now https://docs.openstack.org/releasenotes/nova/pike.html#known-issues | |
| 18:56:16 | melwitt | yeah, I remember. I thought it was worth handling (to not change the behavior) but I think I was not in the majority opinion about it | |
| 18:57:34 | melwitt | I was aware of putting the instances in ERROR state but for whatever reason at the time, I didn't realize that meant things used to fail in the API before | |
| 18:57:59 | mriedem | we fail either way, | |
| 18:58:12 | mriedem | the difference is before you didn't have 50 instances in ERROR state that you had to manually clean up | |
| 19:00:37 | melwitt | yeah, that's what I meant, fail in the API without creating instances. and we can't just delete them instead of putting them into ERROR state because we have no other way to signal the create failed after the API returned a 202 | |
| 19:01:51 | melwitt | so then we were talking about counting build requests along with instances with de-duping I think. I think it would be worth it to avoid manual cleanup for users. but I think the other argument was that operators could turn off quota recheck | |
| 19:01:55 | mriedem | that and it would look janky if you're polling and watching the number of instances returned increase, then start automatically decreasing | |
| 19:02:31 | mriedem | i don't know who is going to ever turn off that quota recheck flag | |
| 19:02:43 | mriedem | but the build request count could also be based on that flag i guess | |
| 19:02:44 | melwitt | yeah | |
| 19:02:54 | melwitt | true | |
| 19:10:40 | openstackgerrit | Chris Dent proposed openstack/nova master: Use nova.db.api directly https://review.openstack.org/543262 | |
| 19:13:21 | openstackgerrit | Merged openstack/nova master: Move resource class fields https://review.openstack.org/540049 | |
| 19:14:31 | openstackgerrit | Merged openstack/nova master: Move resource provider objects into placement hierarchy https://review.openstack.org/551528 | |
| 19:18:31 | cfriesen | maybe a weird question, but is the metadata API accessible from all instances within the guest? Or would some like PCI VF/PF not necessarily support it? Just wondering how you're supposed to access device tagging if you don't know which NICs are which. Is a config drive recommended in this case? | |
| 19:18:40 | cfriesen | s/instances/interfaces | |
| 19:20:17 | dansmith | cfriesen: yeah, metadata access is generally handled by overriding routing on the host, or in the neutron netns | |
| 19:20:26 | dansmith | cfriesen: assuming conventional networking to cloud instances | |
| 19:20:34 | dansmith | if you have only direct network access, | |
| 19:20:41 | dansmith | then it's going to be hard | |
| 19:20:49 | dansmith | configdrive being a better option for that (and many cases) | |
| 19:24:23 | artom | Keep in mind: config drive is write-once. Tagged (at|de)tachments are not reflected. | |
| 19:25:41 | artom | Hrmm, that reminds me... | |
| 19:26:20 | artom | Didn't we have a conversation at some point about making the metadata API easier to consume? | |
| 19:29:08 | artom | Ahh, virtio-sock: http://lists.openstack.org/pipermail/openstack-dev/2017-February/112602.html | |
| 19:29:18 | openstackgerrit | Dan Smith proposed openstack/nova master: Add AggregateList.get_by_metadata() query method https://review.openstack.org/544728 | |
| 19:29:19 | openstackgerrit | Dan Smith proposed openstack/nova master: Add aggregates list to Destination object https://review.openstack.org/544729 | |
| 19:29:20 | openstackgerrit | Dan Smith proposed openstack/nova master: Make get_allocation_candidates() honor aggregate restrictions https://review.openstack.org/547990 | |
| 19:29:20 | openstackgerrit | Dan Smith proposed openstack/nova master: Add request filter functionality to scheduler https://review.openstack.org/544730 | |
| 19:29:21 | openstackgerrit | Dan Smith proposed openstack/nova master: WIP: Honor availability_zone hint via placement https://review.openstack.org/546282 | |
| 19:29:21 | openstackgerrit | Dan Smith proposed openstack/nova master: Add require_tenant_aggregate request filter https://review.openstack.org/545002 | |
| 19:29:30 | dansmith | edleafe: rebased on top of your patch ^ | |
| 19:30:10 | artom | Wonder how evil it would be support the metadata API with virtio-sock in libvirt only... | |
| 19:34:46 | dansmith | artom: it would be fully contained in the libvirt driver I think.. not sure that'd be a problem | |
| 19:35:16 | artom | dansmith, evil in the sense that we'd be leaving other virt drivers in a "we don't support the metadata API as well as libvirt does" state | |
| 19:35:39 | dansmith | I dunno how addressing works on vsock, and if you'd have to come up with a well-known address or port for it, but other than that it'd just be a proxy to the http interface | |
| 19:36:12 | artom | There'd also be the question of do we let the user decide whether they want a vsock or not | |
| 19:36:30 | dansmith | if it's a thing cloud-init looks for and supports, then it'd try that, like it tries http, and like it looks for a configdrive | |
| 19:36:48 | dansmith | no, I'd say you just expose it if libvirt can do it, maybe optional via config, | |
| 19:36:48 | artom | I should really be thinking about other stuff, but this is more fun :/ | |
| 19:36:51 | dansmith | but don't make it a user thing | |
| 19:37:07 | dansmith | I'm not sure it's a huge problem in need of a solution yeah :) | |
| 19:37:21 | dansmith | worst case, give them one vif on a private network that can get to metadata :) | |
| 19:38:18 | dansmith | ah, ports are strings, so "org.openstack.nova.metadata-api" or something | |
| 19:38:26 | artom | Well, as we use the metadata for more stuff (what did cfriesen want to use it for at the PTG? Something to do with pinning?), the fact that operators don't like deploying it (which I gather is a thing) is becoming a problem | |
| 19:39:50 | cfriesen | Yeah, I use it for CPU scaling since our qemu is too old for proper CPU hotplug...the metadata tells the guest at guest kernel boot time which vCPUs should be "offline". | |
| 19:40:58 | cfriesen | But we also have a terrible terrible feature that lets you specify the desired virtual PCI address for your virtual NICs. This was added for a customer that had legacy apps that had hardcoded PCI addresses for things. | |
| 19:41:15 | artom | cfriesen, hah, we had a customer that wanted to do that | |
| 19:41:26 | artom | I *think* we convinced them that device tagging was the way to go | |
| 19:41:45 | cfriesen | yeah...but until Pike you couldn't attach/detach tagged devices | |
| 19:42:22 | artom | Indeed, and PFs still can't be tagged, it turns out | |
| 19:42:34 | cfriesen | hmm, that's kind of lame | |
| 19:42:34 | artom | *nudge nudge* https://review.openstack.org/#/c/533805/ ;) | |
| 19:43:06 | cfriesen | I'll see if I can get our PCI guy to look at it. | |
| 19:43:43 | artom | cfriesen, thanks :) | |
| 19:58:34 | cdent | sorry, not sorry, I've given lots of people a merge conflict | |
| 20:00:14 | mikal_ | artom: I don't have a particular problem with the vsock thing if it "tastes like" normal network access inside the instance. | |
| 20:00:33 | mikal_ | artom: in fact, it would be nice for such a thing to "sign" the request so we strongly know what instance made it. | |
| 20:00:56 | mikal_ | artom: ala AWS | |
| 20:01:14 | artom | mikal_, hrmm, that's actually a good question - how does the host know what instance a request came from over vsock? | |
| 20:02:18 | mikal_ | artom: its not one vsock per instance? | |
| 20:02:32 | artom | mikal, it is, but... | |
| 20:02:46 | artom | This is where what little knowledge I have of this thing breaks down | |
| 20:02:49 | mikal | So nova knows when it sets the vsock the instance its going to wire it into... | |
| 20:03:18 | artom | But if there's only one service listening on the host side, even if there's one vsock per guest... | |
| 20:04:03 | artom | Presumably they speak TCP over that vsock, so unless every instance has its own "vsock IP" that nova knows about... | |
| 20:04:28 | artom | If berrange was here he'd probably laugh at my ignorance :/ | |
| 20:09:38 | dansmith | vsock works like AF_INET or AF_UNIX | |
| 20:09:42 | dansmith | it's a socket protocol | |
| 20:09:44 | dansmith | so no TCP or IP | |
| 20:09:59 | dansmith | it's 1:1 and uses strings as the addressing on either end | |
| 20:10:35 | dansmith | so it wouldn't "taste like normal networking" in that sense.. cloud-init would have to open an AF_VSOCK socket to some known port name and then try to speak HTTP over it or something, | |
| 20:10:55 | dansmith | which something on the host could proxy to the regular metadata API, or just emulate the metadata server | |
| 20:11:05 | dansmith | mikal: artom ^ | |
| 20:11:52 | artom | dansmith, heh, dunno if that was off the top of your head or you did the research, but thanks regardless :) | |
| 20:12:29 | cfriesen | artom: https://wiki.qemu.org/Features/VirtioVsock | |
| 20:15:04 | dansmith | artom: I had to refresh my memory on the port bit, but yeah, the rest is pretty straightforward | |
| 20:15:14 | dansmith | it's been discussed a couple times at least | |