| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-23 | |||
| 13:31:54 | lyarwood | mdbooth: swap volume and interested should never appear in the same sentence | |
| 13:33:59 | mdbooth | lyarwood: I proposed a green field implemention :) You never know, it might even make you happy. | |
| 13:34:27 | mdbooth | lyarwood: Anyway, I wanted *something* written down before the PTG session just to ensure it has some structure. If we throw it away that's fine. | |
| 13:34:55 | tssurya | mriedem: not yet I am still writing test cases and notification changes. Will add it to the queue once that is done | |
| 13:36:43 | lyarwood | mdbooth: ack thanks | |
| 13:38:17 | efried | mriedem: Extra runway time: sure | |
| 13:38:22 | mriedem | mdbooth: without reading, if i wrote swap volume today i'd probably use the os-server-external-events API as the callback from cinder like we use for neutron and cinder's extend volume api | |
| 13:38:40 | efried | kashyap: ack, thx | |
| 13:38:52 | efried | lbragstad: Yup, got it figured, thanks. | |
| 13:40:06 | efried | eandersson: ack, will look. Either way would be fine. I was going to say this is temporary until we rip out ironicclient; but the region_name and min/max fixes should be backported, so the stable branches will carry that code for a while. | |
| 13:40:30 | efried | mriedem: ack, saw the test.py thing, +2, good call. | |
| 13:43:48 | mdbooth | mriedem: My proposal wasn't explicit about what rpc method was used, but it is explicit about synchronous guarantees. | |
| 13:44:25 | mdbooth | mriedem: If we can use something more appropriate to the task than the rest api whilst having explicit calls and waiting between cinder and nova that would be awesome. | |
| 13:45:25 | mdbooth | I don't think it's possible to do with 1-way asynchronous calls, though, and 2-way asynchronous calls would be more complex. | |
| 14:01:52 | mdbooth | mriedem: Thanks, btw. I'd completely forgotten to discuss rpc mechanisms in that mail. I just tacked it on. | |
| 14:03:38 | mriedem | mdbooth: i wasn't talking about rpc, i was talking about rest api | |
| 14:04:12 | mdbooth | mriedem: I was talking about 'rpc', where the rest api is a type of rpc | |
| 14:04:49 | mriedem | mdbooth: do you want a new dedicated swapVolume server action that is synchronous to cinder? | |
| 14:05:39 | mdbooth | mriedem: It's described in the ML post, but basically there would be 2 separate calls and cinder would do the bulk of the copy itself. | |
| 14:09:22 | mdbooth | Note that the currently implementation is essentially synchronous as it has a callback, btw. Except when it doesn't :/ | |
| 14:09:41 | openstackgerrit | Christian Berendt proposed openstack/nova stable/rocky: Fix regression in glance client call https://review.opendev.org/655167 | |
| 14:19:54 | kashyap | efried: sean-k-mooney: A "traits" question: If I were to add a 'COMPUTE_UEFI_SECURE_BOOT' trait, to indicate the host QEMU+libvirt+OVMF is capable of Secure Boot support, what existing similar example would you suggest to look at, in the Nova code? | |
| 14:20:24 | mriedem | kashyap: look at the capabilities stuff the drivers report as traits | |
| 14:20:29 | mriedem | and what dansmith is doing with supported image types | |
| 14:20:29 | efried | mriedem has... yeah | |
| 14:20:46 | mriedem | https://review.opendev.org/#/c/652710/ | |
| 14:20:57 | kashyap | mriedem: Ah, yes. I took a cursory look at Dan's image_types. /me looks | |
| 14:21:03 | kashyap | Thanks, both | |
| 14:22:02 | efried | kashyap: also https://review.opendev.org/#/c/645316/ | |
| 14:22:57 | kashyap | efried: Yep, bookmarked & reading. Thanks for the (non-null) pointers | |
| 14:25:21 | kashyap | efried: mriedem: Oh, speaking of traits, it reminds of something I noticed the other day: e.g. I see the CPU_TRAITS_MAPPING work that alex_xu and co. did in the past | |
| 14:26:12 | kashyap | ...I see that we're missing some useful and important CPU traits like PCID feature, etc. | |
| 14:26:18 | sean-k-mooney | kashyap: i propsoed that in the past. https://review.opendev.org/#/c/514713/4/os_traits/fw/uefi.py | |
| 14:26:20 | kashyap | Is there a "recommended" way to systematically add new / missing traits? | |
| 14:26:42 | sean-k-mooney | although it was a slightly different usecase | |
| 14:27:06 | kashyap | sean-k-mooney: Right, I just saw the remark on your (abandoned) change | |
| 14:27:22 | mriedem | kashyap: propose them to the os-traits library | |
| 14:27:26 | kashyap | efried: Or is it just a matter of: "go, simply add the missing trait"? | |
| 14:27:34 | mriedem | lpetrut: was asking the same yesterday | |
| 14:27:49 | sean-k-mooney | if COMPUTE_UEFI_SECURE_BOOT means this host is capable of virtualising a vm with secure boot i think its fine | |
| 14:27:53 | kashyap | Yeah, so far I was "ignoring" traits thingie. Now I can no longer :D | |
| 14:28:10 | efried | kashyap: Yeah, I don't think we want a strategy of "add all these traits that might ever be relevant". | |
| 14:28:12 | kashyap | mriedem: Thanks! This one: https://github.com/openstack/os-traits | |
| 14:28:12 | sean-k-mooney | what i was orginally trying to model was this host host secure boot ebabled | |
| 14:28:23 | sean-k-mooney | that is what the pushback was reated too | |
| 14:28:28 | efried | Rather, we want to add as needed. | |
| 14:28:34 | aspiers | efried: thanks for the SEV spec review, just replying now | |
| 14:28:39 | efried | aspiers: ack | |
| 14:29:12 | kashyap | efried: Not "might". E.g. a practical example: if you applied all the Meltdown/Spectre fixes, then your guests are suddenly awfully w.r.t performance (while you may get security) | |
| 14:29:17 | mriedem | lyarwood: per your email about extracted placement + tripleo, does that mean train tripleo ci is using extracted placement in base deploys? | |
| 14:29:20 | sean-k-mooney | kashyap: os-traits uses story board so you will want to creat a story for the new triat | |
| 14:29:34 | kashyap | efried: ... unless you specify PCID. (https://kashyapc.fedorapeople.org/Reducing-OpenStack-Guest-Perf-Impact-from-Meltdown.txt) | |
| 14:29:37 | efried | kashyap: If you have a use case that encompasses some traits, that counts. | |
| 14:30:05 | kashyap | sean-k-mooney: Sigh, it seems more red tape, why a "storyboard" ticket for such a simple thing? A commit message should be able to handle it | |
| 14:30:23 | efried | kashyap, sean-k-mooney: I agree. | |
| 14:30:29 | efried | sorry | |
| 14:30:36 | efried | I agree that we shouldn't need a story for new traits. | |
| 14:30:39 | kashyap | efried: I'm only looking at CPU traits that are practically important / relevant. | |
| 14:30:46 | efried | unless there's some massive architectural thing going on. | |
| 14:30:57 | kashyap | sean-k-mooney: Let's not sleep-walk into mind-numbing process. It shoos away more contributors. | |
| 14:31:03 | efried | You can expect some bikeshedding on namespaces and whatnot, but all of that can happen in review. | |
| 14:31:06 | sean-k-mooney | kashyap: im not | |
| 14:31:14 | sean-k-mooney | once added a trait can never be remvoed | |
| 14:31:18 | kashyap | efried: Yeah, that's fine. | |
| 14:31:42 | sean-k-mooney | so i just wanted it to not slip between the cracks | |
| 14:31:45 | efried | but kashyap, note that storyboard in this sense would be more akin to bugs.launchpad, not blueprints.launchpad. | |
| 14:32:03 | kashyap | sean-k-mooney: The merits / demerits of a trait can be discussed in the review. If there is consensus that it should not be added, any reasonable person will concur. | |
| 14:32:14 | kashyap | efried: Yep, I've filed a few 'stories' myself :-) | |
| 14:32:21 | kashyap | (For the infra project, though) | |
| 14:32:32 | efried | I'm one for less process anywhere possible | |
| 14:33:28 | efried | kashyap: btw, in case your reference to the github repo was meaningful, os-traits is developed in gerrit | |
| 14:33:54 | efried | so like don't go submitting a pull request. | |
| 14:33:56 | kashyap | Yep, figured as much. | |
| 14:33:59 | efried | cool | |
| 14:34:06 | kashyap | Hehe, I by default assume all these are Gerrit-based. | |
| 14:34:52 | jaypipes | mriedem: yessir | |
| 14:37:11 | openstackgerrit | sean mooney proposed openstack/nova master: [DNM] AUTOPEP8 ignore https://review.opendev.org/655171 | |
| 14:39:47 | jaypipes | efried: can you link me the review I said I'd re-look at that I responded "yessir" to you last evening? my scrollback doesn't have it (and no, I don't log irc) | |
| 14:40:01 | jaypipes | efried: tia | |
| 14:40:16 | lyarwood | mriedem: sorry missed your ping, yes AFAIK it's the default in CI now | |
| 14:40:16 | efried | jaypipes: It was aspiers' SEV reproposal: https://review.opendev.org/641994 | |
| 14:40:41 | jaypipes | danke | |
| 14:40:42 | efried | jaypipes: he said he's responding to my last couple of comments now. | |
| 14:40:51 | jaypipes | k | |
| 14:41:39 | kashyap | jaypipes: Will answer your question shortly on the review. (And interesting pointer on "Shielded VMs", I guess that's the nail on the "use case coffin" :D) | |
| 14:42:07 | kashyap | jaypipes: Also on "stupid questions"...recall what the inimitable Carl Sagan said: | |
| 14:42:11 | kashyap | "There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand the world. There is no such thing as a dumb question."—Carl Sagan | |
| 14:48:31 | jaypipes | kashyap: the complete quote ends with "unless you're speaking with Jay Pipes. If that's the case, yes, there is definitely such a thing as a stupid question." | |
| 14:48:58 | kashyap | Hehe, go easy on yourself | |
| 14:49:23 | jaypipes | efried: k. to be clear, have all of danpb's concerns been addressed? | |
| 14:49:58 | efried | jaypipes: I definitely want to get a re-ack from danpb before we merge the spec. My review was only in terms of the placement- and nova-isms. | |
| 14:50:24 | efried | aspiers: Any progress on contacting danpb to sign off? | |
| 14:52:04 | efried | jaypipes: Of course you should dig into the SEV-specific gorp as you are able/willing, but I mainly wanted to make sure you were on board with the switchover to quantitative inventorying of SEV context. | |
| 14:52:12 | jaypipes | is there a danpb bat-signal? | |
| 14:52:36 | efried | "we're going to rewrite nova" | |
| 14:52:36 | efried | ^ that should do it | |
| 14:52:50 | jaypipes | efried: ack, lemme focus on those changes. | |
| 14:52:56 | jaypipes | efried: lol | |
| 14:53:08 | jaypipes | efried: danpb long ago gave up the nova ghost. | |
| 14:54:28 | efried | eandersson: I want to backport your region_name fix, so just need a bug associated with it and I think we're good to go. | |