| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-09 | |||
| 13:42:16 | sean-k-mooney | cri-o is interesting but its non tivial to setup currently | |
| 13:43:43 | mriedem | mordred: as our resident compute api/sdk opinion czar, i'd like your opinion on this spec https://review.openstack.org/#/c/638629/9/specs/train/approved/add-locked-reason.rst@198 | |
| 13:43:52 | mriedem | specifically the response format for those new fields | |
| 13:44:00 | mriedem | i.e. nested or flat | |
| 13:45:54 | kashyap | gibi: Thanks! (I spent a lot of time wordsmithing to get words right in that spec) | |
| 14:11:03 | mriedem | tssurya: some questions in your ironic power state sync spec https://review.openstack.org/#/c/636132/ | |
| 14:11:09 | mriedem | dansmith: ^ you should probably review that as well | |
| 14:11:23 | tssurya | mriedem: ack, looking | |
| 14:11:41 | mriedem | jaypipes maybe too since he loves ironic nowadays | |
| 14:12:23 | jaypipes | mriedem: errmmm, not quite :) | |
| 14:12:35 | jaypipes | but I'll review regardless. | |
| 14:15:01 | dansmith | mriedem: on meetings for the next couple hours, but willt ry | |
| 14:22:19 | kashyap | Frelling rST | |
| 14:23:31 | mriedem | gibi: i've replied to your questions in the cross-cell resize re-proposal https://review.openstack.org/#/c/642807/ | |
| 14:23:55 | mriedem | suppose dansmith and melwitt should look at that one as well since they are familiar with the original in stein | |
| 14:26:28 | kashyap | alex_xu: Gosh, it is 22:26. Nothing is more important than sleep... | |
| 14:27:04 | alex_xu | \o/ sleep now | |
| 14:27:27 | mriedem | alex_xu: i still have some chinese cold medicine from the shenzhen airport i can send you :) | |
| 14:27:41 | mriedem | i don't know what it says on the packaging but i know i'm only supposed to take 2 of each every 12 hours | |
| 14:37:13 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Add 'flavor-extra-spec-image-property-validation-extended' spec https://review.openstack.org/638734 | |
| 14:40:25 | stephenfin | kashyap: Fair to say https://review.openstack.org/#/c/625216/ means https://review.openstack.org/#/c/651139/ is unnecessary? | |
| 14:42:38 | kashyap | stephenfin: Just took a cursory look, so they're proposing to expose _tunnelled via REST API. That's baloney | |
| 14:42:49 | kashyap | We don't want _tunnelled at all, we will deprecate it, as you know | |
| 14:43:24 | stephenfin | kashyap: Yup, that's what I was thinking but I just wanted to be sure it was as baloney as I thought it was | |
| 14:43:27 | kashyap | "We" as in, once we bump the min versions to have hypervisor-native TLS, then Nova can nuke _tunnelled support | |
| 14:44:11 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: Tools & docs for backlog & abandoned spec process https://review.openstack.org/648800 | |
| 14:44:19 | efried | stephenfin: Did I do that right? ^ | |
| 14:44:55 | kashyap | stephenfin: Aside: please deliver me from my misery by sharing the "genuine table" syntax. I'm only seeing these "naked tables": https://kashyapc.fedorapeople.org/Plain-rendering-of-table-Sphinx.png | |
| 14:45:23 | kashyap | (Also, I like the .. code-block: text tip from efried; it's visually clean and immediately shows what a user wants) | |
| 14:45:39 | stephenfin | kashyap: Ahh, that's the theme's fault. I'd been testing with the default Sphinx theme | |
| 14:45:42 | kashyap | (s/what a user wants/what the API entails/) | |
| 14:45:43 | stephenfin | Bad openstackdocstheme | |
| 14:46:10 | stephenfin | kashyap: OK, ignore that comment so. That's certainly more difficult to read that one would like | |
| 14:46:30 | kashyap | Yeah, phew. Thanks for confirming that I'm missing to see something that only you seem to see :-) | |
| 14:46:42 | kashyap | s/that I'm missing/that I'm _not_ missing/ | |
| 14:46:47 | stephenfin | efried: 'ish. You don't need to define the 'nodeps' testenv | |
| 14:46:49 | efried | stephenfin: There was another place where the lack of (even the ability to request) table borders was very annoying. | |
| 14:47:00 | gibi | mriedem: thanks. the cross resize patch looks good to me. I did +1 it only as I feel others should approve it | |
| 14:47:18 | efried | stephenfin: I figured I had the choice between defining that env or repeating 'deps=' in both, right? | |
| 14:47:57 | efried | figured the former was more DRY-ish and less prone to future slippage | |
| 14:48:06 | efried | can flip it if you prefer it the other way, whatevs. | |
| 14:48:09 | stephenfin | efried: Not really. deps for a given section will inherit from '[testenv]' by default | |
| 14:48:32 | stephenfin | So you've reverted back to 'deps = -r{toxinidir}/doc/requirements.txt' for those two sections | |
| 14:48:45 | efried | eh? | |
| 14:48:59 | efried | Even though I said envdir= ? | |
| 14:49:05 | efried | okay, I'll twiddle it again. | |
| 14:49:18 | stephenfin | yeah, envdir has no bearing on deps | |
| 14:49:23 | efried | ight | |
| 14:49:24 | mriedem | kashyap: stephenfin: gibi: i've left several comments and questions in this baselineHypervisorCPU spec https://review.openstack.org/#/c/645814/ and i must be missing something that everyone else understands about what this solves | |
| 14:49:46 | kashyap | Will look | |
| 14:49:50 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: Tools & docs for backlog & abandoned spec process https://review.openstack.org/648800 | |
| 14:50:00 | stephenfin | other than if you use the same envdir with different deps, in which case you get the aforementioned rebuilding on environment each time | |
| 14:50:26 | efried | whee | |
| 14:50:38 | efried | done | |
| 14:50:42 | efried | ---^ | |
| 14:50:54 | efried | Thanks for the help stephenfin | |
| 14:53:10 | gibi | mriedem: I think https://review.openstack.org/#/c/645814/ and https://review.openstack.org/#/c/642030/ are connected | |
| 14:53:38 | gibi | mriedem: so when nova will automatically select a specific cpu_model from a list of models it will select a better suited one | |
| 14:54:51 | mriedem | the former doesn't mention anything about the latter | |
| 14:55:16 | stephenfin | efried: +2'd | |
| 14:55:24 | efried | thank you sir. | |
| 14:55:50 | gibi | mriedem: that is true | |
| 14:56:53 | gibi | mriedem: kashyap knows more about the connection | |
| 14:57:25 | kashyap | I did mention about this https://review.openstack.org/#/c/645814/ in https://review.openstack.org/#/c/645814/ | |
| 14:57:49 | mriedem | i assume you meant to link to https://review.openstack.org/#/c/642030/ | |
| 14:57:51 | mriedem | which i haven't read | |
| 14:57:54 | kashyap | mriedem: The "executive summary" is that the two libvirt APIs Nova uses today don't take account what the host KVM, QEMU and libvirt are capable of, when computing CPU models. And the proposed two new APIs will solve a class of issues. | |
| 14:58:16 | kashyap | Among other things, Nova can now ask: "Are CPU flags X and Y supported by KVM, QEMU and libvirt on the host"? | |
| 14:58:20 | kashyap | How does that help operators? | |
| 14:59:21 | kashyap | It gives them more _useful_ (and in some cases _secure_ -- e.g. CPU flags introduced to solve Meltdown/Spectre) guest CPU configuration | |
| 14:59:25 | kashyap | (Not everything is linked to migration.) | |
| 14:59:41 | kashyap | I'll respond on the review, to save some typing. | |
| 14:59:48 | dansmith | kashyap: are you talking about for scheduling or for generating more optimal xml for a guest? | |
| 15:00:51 | mriedem | it's not clear to me if the operator is doing anything here, or if operators today are doing x to workaround limitations in nova's libvirt driver using these older apis | |
| 15:01:15 | mriedem | the spec just isn't clear to me on what the end user visible benefit is | |
| 15:01:21 | mriedem | i'm sure there is one, but it's just not clear to me | |
| 15:01:30 | mriedem | 1. use new apis, 2. ?, 3. profit. | |
| 15:02:02 | mordred | mriedem: I think either thing is fine from an openstacksdk POV - but I could see the shift from bool to dict being maybe a little more annoying for the more staticly typed folks like go - whereas the flat approach like it is in the notification payload would be potentially friendlier to deal with there | |
| 15:02:02 | kashyap | dansmith: Not scheduling. In some ways you can call it "optimal XML for a guest", but not everything is about XML generation. It is more about how Nova's libvirt driver can take into account multiple important factors (listed in the spec) when coming up with guest CPUs | |
| 15:02:05 | mriedem | i should probably re-watch your summit talk that is related to this | |
| 15:02:22 | dansmith | kashyap: okay, I | |
| 15:02:29 | mordred | mriedem: so I think I'd vote, in this case, for flat, mostly because of the existence of the locked key already | |
| 15:02:33 | dansmith | have only skimmed, but.. probably need to be more clear about that | |
| 15:02:34 | kashyap | mriedem: It is not directly a clean one-to-one mapping of: "if you click on this button, elephants will dance on your screen" | |
| 15:03:03 | kashyap | mriedem: The operator doesn't have to do anything much here | |
| 15:03:41 | mriedem | is there a very obvious case of "this is an issue we have today which is a limitation due to using the older apis which would be solved by using the new" | |
| 15:03:59 | mriedem | like an actual example | |
| 15:04:05 | kashyap | Yes, let me link to the code | |
| 15:04:26 | mriedem | mordred: ok, if you can take a sec to comment on the spec that would go a long way i think | |
| 15:04:37 | mordred | sure! | |
| 15:05:12 | kashyap | mriedem: libvirt upstream added the two APIs (partly) based on the need that came out of Nova, noted here: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3947,#L3958 | |
| 15:05:30 | kashyap | (That comment should be removed, now that the libvirt RFE I filed is fixed.) | |
| 15:05:50 | openstackgerrit | sean mooney proposed openstack/nova-specs master: Libvirt: add vPMU spec for train https://review.openstack.org/651269 | |
| 15:06:51 | mordred | mriedem: done | |
| 15:07:01 | kashyap | mriedem: A practical example is: the existing libvirt APIs can't answer this: Is this combination of 'IvyBridge' CPU model with 'pcid' and 'pdpe1gb' supported by the KVM+QEMU+libvirt on the host? | |
| 15:07:33 | sean-k-mooney | kashyap: isnt that a defct in libvirt | |
| 15:08:07 | openstack | bugzilla.redhat.com bug 1559832 in libvirt "[RFE] Fine-grained API to validate if a given CPU model and flags are supported by QEMU / KVM" [Unspecified,Closed: nextrelease] - Assigned to jdenemar | |
| 15:08:07 | kashyap | sean-k-mooney: Yes, it is. That's why I asked libvirt upstream to provide the two new RFEs: https://bugzilla.redhat.com/show_bug.cgi?id=1559832 | |
| 15:08:11 | sean-k-mooney | it could tell if pdpe1gb was supporte by looking the the host cpu flags | |
| 15:08:21 | kashyap | (To solve the problem for Nova.) | |