| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-23 | |||
| 12:47:04 | kashyap | aspiers: No, that's too FrankenStack to mix it like that :D | |
| 12:47:08 | aspiers | right | |
| 12:47:29 | kashyap | Okay, /me moves "office", home --> library; bbiab | |
| 12:48:57 | aspiers | kashyap: getting the emulator was the whole point of https://review.opendev.org/#/c/640483/ | |
| 12:51:54 | sean-k-mooney | aspiers: what were you going to use the emulator for? | |
| 12:52:35 | aspiers | for calling the API as per above | |
| 12:52:38 | aspiers | gotta run, biab | |
| 12:54:13 | sean-k-mooney | aspiers: you can only have kvm and zen on the same host if you run two agents. and are happy to support it entirly yourself because noone else will touch it :) | |
| 12:56:42 | sean-k-mooney | kashyap: if you did not restat the agent i think we would pick you the capablity changes via the periodic task but ya it would be an ill defined state untill that happened | |
| 12:57:08 | kashyap | Right | |
| 13:03:16 | mriedem | melwitt: about 5am i was thinking about quota and rebuild from cell0 - thoughts are in the spec https://review.opendev.org/#/c/648686/2/specs/train/approved/enable-rebuild-for-instances-in-cell0.rst@96 if you can check my thinking | |
| 13:03:49 | mriedem | tssurya: is your locked_reason stuff ready for review? if so, can you queue it up for runways? | |
| 13:04:58 | gibi | mriedem: what will happen if we run the migration, run archive, run migration, run archive again. Does that second archive fail to move the marker instance due to a unique constraint on the uuid field in the shadow table? | |
| 13:05:40 | openstackgerrit | Nikolay Fedotov proposed openstack/nova master: Fix disappearing ironic hypervisors after rebuilding hashring https://review.opendev.org/654584 | |
| 13:07:28 | gibi | mriedem: never mind, we dont add the unique constraint to the shadow tables | |
| 13:07:43 | gibi | mriedem: series starting at https://review.opendev.org/#/c/653098/ looks good to me | |
| 13:07:44 | mriedem | right | |
| 13:08:42 | mriedem | thinking about your migration + archive thing, i don't think we archive the deleted marker instance because of the fkey relationship to the vif | |
| 13:09:58 | mriedem | i also don't think we ever delete the marker vif even if we don't need to migrate any more records, | |
| 13:10:25 | mriedem | so eventually when we remove that online data migration, we'll likely also need to delete the marker vif so archiving can remove it and we can remove the hack in the api | |
| 13:13:05 | gibi | mriedem: hm, then I don't get how your functional test passes at https://review.opendev.org/#/c/653098/2/nova/tests/functional/regressions/test_bug_1825034.py@77 | |
| 13:13:35 | gibi | mriedem: or we delete the marker instance but no the marker vif? | |
| 13:13:49 | mriedem | correct | |
| 13:14:03 | mriedem | the instance record is soft deleted but the marker vif is not | |
| 13:14:19 | mriedem | efried: i reckon anything going into a runway slot today will get an extra week because of the summit yeah? | |
| 13:14:49 | gibi | mriedem: I see | |
| 13:15:30 | mriedem | melwitt: i removed the counting quotas from placement series out of the runway slot since the time expired but feel free to queue it back up | |
| 13:17:31 | bauzas | mriedem: sorry was on bank holiday yesterday, how can I help with some review ? | |
| 13:17:54 | openstackgerrit | Lucian Petrut proposed openstack/nova master: Expose Hyper-V supported image types https://review.opendev.org/655137 | |
| 13:18:13 | mriedem | bauzas: stein regression series starting here would be good https://review.opendev.org/#/c/653268/ | |
| 13:18:30 | mriedem | bauzas: and i need review on this queens backport https://review.opendev.org/#/c/640198/ | |
| 13:18:47 | mriedem | we're very close to closing out pike | |
| 13:19:33 | mriedem | extra credit for https://review.opendev.org/#/c/639382/ which is #2 in my series of 45+ changes in the cross-cell series | |
| 13:20:12 | mriedem | gibi: could i also ask, when you get a min, to review this functional recreate test for a latent bug https://review.opendev.org/#/c/641521/ | |
| 13:20:39 | gibi | mriedem: sure, looking | |
| 13:22:36 | mriedem | thanks | |
| 13:28:39 | gibi | mriedem: done, looks good | |
| 13:29:43 | mriedem | thanks again, and i see you took the extra credit :) | |
| 13:30:01 | mdbooth | lyarwood: Just sent a thing on swap-volume to the ML which you might be interested in. | |
| 13:30:30 | gibi | mriedem: :) | |
| 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. | |