| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-09 | |||
| 12:49:50 | openstackgerrit | Theodoros Tsioutsias proposed openstack/nova master: Introduce the PENDING instance state https://review.openstack.org/566473 | |
| 12:50:48 | efried | kashyap: ack | |
| 12:51:41 | sean-k-mooney | its surpring how often "sudo rm -rf /var/lib/docker/" fixs your docker issues | |
| 12:51:49 | efried | I at least diff from the last release's version before doing that; this one has changed substantially so I'll wait | |
| 12:52:39 | efried | What's the adage? "If you try to solve a problem using docker, now you have two problems." ? | |
| 12:53:47 | efried | Welcome to Train pre-PTG spec review day #1: https://etherpad.openstack.org/p/nova-spec-review-day | |
| 12:53:47 | efried | dansmith: Would you please update the channel topic to something like | |
| 13:13:11 | openstackgerrit | Huqiang Wang proposed openstack/nova-specs master: Separate the vCPUs into different pools based on priority https://review.openstack.org/649882 | |
| 13:19:53 | openstackgerrit | Dakshina Ilangovan proposed openstack/nova-specs master: Nova LLC allocation - RMD plugin for RDT CAT https://review.openstack.org/651233 | |
| 13:21:29 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Use migration_status during volume migrating and retyping https://review.openstack.org/637224 | |
| 13:37:26 | kashyap | sean-k-mooney: On "Docker", you're so 2014. 'Everyone' has moved on from Docker to "CRI-O" and "podman", etc. | |
| 13:37:43 | kashyap | (Please update your "container jargon" :D) | |
| 13:38:55 | sean-k-mooney | kashyap: i am using docker and plan to never use podman. i might use CRI-O | |
| 13:39:31 | kashyap | sean-k-mooney: I was massively trolling; sorry. (I have no clue about their compatibilities.) | |
| 13:41:33 | sean-k-mooney | podman has 1:1 commandline compatible with docker | |
| 13:41:44 | sean-k-mooney | or the docker cli | |
| 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" | |