| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-13 | |||
| 18:05:28 | dansmith | that caused people a lot of pain, on top of the pain required to view/edit it in general | |
| 18:05:30 | jaypipes | dansmith: so we'd have multiple options like this? physnet_mapping_physnet0_name = "tenant_data_0"; physnet_mapping_physnet0_numa_nodes = 0,1; | |
| 18:05:49 | jaypipes | dansmith: personally I find encoded that to be less nice than just putting it in a JSON blob. | |
| 18:06:08 | dansmith | no | |
| 18:06:28 | mriedem | melwitt: notifications are on the rpc queue, so the user wouldn't see them... | |
| 18:07:06 | jaypipes | dansmith: mind etherpadding up your proposed conf option format? | |
| 18:07:06 | dansmith | jaypipes: https://pastebin.com/zP7eyAZw | |
| 18:07:10 | jaypipes | lol | |
| 18:07:12 | jaypipes | jinx | |
| 18:07:15 | mriedem | unless you mean user = admin/operator looking at notifications; as for the actual usefulness of that specific case, i don't think it's really useful either since it's normal during a quota recheck | |
| 18:07:19 | jaypipes | always ten steps ahead of me :) | |
| 18:07:26 | mriedem | i.e. we don't send a versioned notification when server create fails due to overquota on ram/cpu | |
| 18:07:45 | jaypipes | dansmith: heh, ok. sure, I can go for that. | |
| 18:07:58 | jaypipes | dansmith: excellent use of the words "bloopy" and "poopy" | |
| 18:08:23 | dansmith | um, excuse me. | |
| 18:08:26 | dansmith | it's "boopy" | |
| 18:08:34 | jaypipes | oh, my mistake. yes, boopy. | |
| 18:09:37 | mriedem | lyarwood: i don't see the problem, clear as day https://docs.openstack.org/nova/latest/configuration/config.html#pci.passthrough_whitelist | |
| 18:09:44 | jaypipes | dansmith: k. added a link on the spec and mentioned I could go for that. | |
| 18:09:57 | dansmith | ack | |
| 18:14:40 | lyarwood | mriedem: so for me that renders with unicode quotes that when copied into nova.conf makes n-cpu bork | |
| 18:16:02 | mriedem | lyarwood: i was joking, of course it does | |
| 18:17:05 | lyarwood | wunderbar | |
| 18:17:20 | mriedem | https://github.com/openstack/nova/blob/master/nova/conf/pci.py#L66 all looks pretty normal to me though | |
| 18:19:13 | edleafe | dansmith: I assume that all microversion changes, placement or not, require a reno | |
| 18:19:47 | dansmith | edleafe: okay I thought just a spec, but I don't really review that many api changes | |
| 18:23:31 | mriedem | arvindn05: comments on https://review.openstack.org/#/c/541507/ | |
| 18:23:49 | mriedem | arvindn05: i don't think we can simply pass through "trait:*" to the ImageMetaProps object, | |
| 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 | |