| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-19 | |||
| 09:33:48 | kashyap | Ah, I see. | |
| 09:33:49 | gibi | no I will check for the stack trace without your patch | |
| 09:33:59 | kashyap | gibi: One more: did you apply the main bump patch as well? | |
| 09:34:59 | gibi | kashyap: I checked out your Omit patch so I have the whole series | |
| 09:35:05 | kashyap | Ah, good. | |
| 09:35:49 | gibi | kashyap: the stacktrace is there even on master without your series | |
| 09:35:56 | gibi | so it is something unrelated | |
| 09:36:11 | kashyap | Okay, noted. Thanks for the quick check. | |
| 09:36:26 | kashyap | Wonder then should I 'recheck', as this could be a spurious failure? | |
| 09:36:42 | gibi | bottom line, the test fail in your patch due to some timing issue in the notification test, unrelated to that there is a ugly stack trace in the log even if it passes, all unrelated to your patch | |
| 09:36:50 | gibi | kashyap: yep, recheck it is | |
| 09:37:58 | kashyap | Noted, thanks for the quick double-check, feel a bit saner now | |
| 09:38:55 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Reject resize requests when the source host is down https://review.openstack.org/623489 | |
| 09:39:34 | lyarwood | sean-k-mooney: ^ I think you looked at this a while ago, should be ready for another review if you have time today. | |
| 09:40:43 | gibi | kashyap: filed a bug not to forget to look at that stacktrace https://bugs.launchpad.net/nova/+bug/1816538 | |
| 09:40:44 | openstack | Launchpad bug 1816538 in OpenStack Compute (nova) "test_volume_swap_server_with_error produce a suspicious stack trace" [Undecided,New] | |
| 09:40:56 | kashyap | Ah, excellent, thanks | |
| 09:50:15 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Use the correct mdev allocated from the pGPU https://review.openstack.org/636591 | |
| 09:50:16 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: libvirt: implement reshaper for vgpu https://review.openstack.org/599208 | |
| 09:50:16 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Add functional test for libvirt vgpu reshape https://review.openstack.org/631559 | |
| 09:58:13 | kashyap | stephenfin: When you can: https://review.openstack.org/#/c/632507/ | |
| 09:59:11 | kashyap | gibi: Remind me again, if I touch-up the commit message, will I lose all the +2s / +1s? | |
| 09:59:41 | kashyap | There is a small grammar mistake; it absolutely needs no touching up, but it's just the OCD... | |
| 10:04:14 | gibi | kashyap: hm, if you lose it I can give it back | |
| 10:04:25 | gibi | kashyap: I think rebase only remove +A | |
| 10:04:35 | gibi | but commit message change might remove +2 as well | |
| 10:04:56 | kashyap | Not worth it; the `diff` is this: | |
| 10:05:13 | kashyap | - create a duplicate 'pty' devices | |
| 10:05:14 | kashyap | + create duplicate 'pty' devices | |
| 10:05:15 | kashyap | :D | |
| 10:06:32 | gibi | kashyap: don't change it :D | |
| 10:08:53 | kashyap | Won't :-) | |
| 10:09:35 | kashyap | I'm not a native speaker either, but a stickler for (my own) language. | |
| 10:09:46 | kashyap | s/language/words/ | |
| 10:11:18 | stephenfin | kashyap: Yup, I left one comment there | |
| 10:11:55 | stephenfin | Still wondering if we should fix the s390x as a (backportable) precursor | |
| 10:12:59 | kashyap | stephenfin: Yeah, I'm wondering that too. I'll respond in the afternoon; need to be AFK soon for a bit | |
| 10:13:31 | stephenfin | kashyap: Cool. I'll hold off reviewing until then so | |
| 10:13:53 | stephenfin | It probably doesn't matter too much (no one has spotted this in ~2 years) but if it's an easy fix... | |
| 10:14:32 | kashyap | stephenfin: Yeah. And to backport it, it's easy to glean it off | |
| 10:14:48 | kashyap | stephenfin: Probably not worth the churn in this patch, IMHO. Not sure if you agree there | |
| 10:15:03 | kashyap | Let me comment on the review, and then head out | |
| 10:19:27 | kashyap | stephenfin: Responded; let me know what you think there. | |
| 10:30:42 | kashyap | stephenfin: Alright, will do. I _began_ with a separate patch, originally, you know - then squashed it :-) | |
| 10:47:20 | openstackgerrit | Adam Spiers proposed openstack/nova master: WIP: Convert driver supported capabilities to compute node provider traits https://review.openstack.org/538498 | |
| 11:40:18 | openstackgerrit | Silvan Kaiser proposed openstack/nova master: Added mount fstype based validation of Quobyte mounts https://review.openstack.org/522245 | |
| 11:50:59 | openstackgerrit | sean mooney proposed openstack/os-vif master: [WIP] remove brctl from vif_plug_ovs https://review.openstack.org/636821 | |
| 11:52:22 | openstackgerrit | sean mooney proposed openstack/os-vif master: remove brctl from vif_plug_ovs https://review.openstack.org/636821 | |
| 11:53:52 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: Avoid redundant initialize_connection on source post live migration https://review.openstack.org/637827 | |
| 12:35:35 | openstackgerrit | ya.wang proposed openstack/nova master: Add configuration item cpu_models to libvirt https://review.openstack.org/637834 | |
| 13:12:21 | aspiers | cdent: you around? I'm a bit confused whether a compute driver should be able to provide a CUSTOM_ trait or not. | |
| 13:13:53 | aspiers | https://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/resource-provider-traits.html suggests not but https://review.openstack.org/#/c/538498/7/nova/virt/driver.py@934 seems to contradict that | |
| 13:15:30 | openstackgerrit | sean mooney proposed openstack/os-vif master: remove use of brctl from vif_plug_linux_bridge https://review.openstack.org/636822 | |
| 13:15:57 | cdent | aspiers: I'm around now. What's up? | |
| 13:16:09 | aspiers | that spec suggests CUSTOM_* was just for admin/operator usage, but maybe it's for everything not in os-traits? | |
| 13:16:24 | aspiers | I see the placement API prevents a PUT of any trait without CUSTOM_ prefix | |
| 13:16:53 | aspiers | would a virt driver ever want to provide a trait not in os-traits? | |
| 13:17:02 | aspiers | 3rd-party drivers maybe? | |
| 13:23:59 | cdent | aspiers: sorry for the delay. It depends on who you ask. | |
| 13:24:40 | cdent | The hope is that anything that is the result of the virt driver "knowing things" about it's environment would be traits in os-traits | |
| 13:24:53 | cdent | and as things are needed by the virt drivers they get added to os-traits | |
| 13:25:25 | cdent | but it's pretty clear that's not always going to be realistic, but, as you say placement will only allow CUSTOM_* traits to be created over the api | |
| 13:25:38 | cdent | s/it's/its/ | |
| 13:26:11 | kashyap | stephenfin: Untangling the mess out of it turning out to be more painful than expected :-( | |
| 13:26:52 | cdent | aspiers: it's more a matter of trying (and failing) to fix my hasty typing disease. It's especially bad with contractions and homophones. | |
| 13:26:54 | kashyap | "the mess" -- remove the 'sclplm'-only first. | |
| 13:27:08 | aspiers | cdent: so you mean that for now at least, we have to allow for drivers providing traits not in os-traits? but would those traits always have the CUSTOM_ prefix, or not necessarily? | |
| 13:27:30 | cdent | If a driver needs to use something that's not in os-traits they have two choices: | |
| 13:27:34 | cdent | * add it to os-traits | |
| 13:27:40 | cdent | * use a CUSTOM_* | |
| 13:27:56 | cdent | ideally the former would be the go to thing | |
| 13:29:37 | aspiers | got it | |
| 13:47:16 | aspiers | cdent: so this? https://pasteboard.co/I1Tbzp2.png | |
| 13:48:00 | openstackgerrit | Silvan Kaiser proposed openstack/nova master: Exec systemd-run without --user flag in Quobyte driver https://review.openstack.org/554195 | |
| 13:48:40 | tssurya | mriedem, dansmith: under which section of the admin docs would you prefer the down cell to be in ? or should I just start w new one? | |
| 13:49:09 | kaisers | stephenfin: Hi! FYI: Followed up on your comments on https://review.openstack.org/#/c/522245/ and https://review.openstack.org/#/c/554195/ | |
| 14:17:06 | openstackgerrit | Hamdy Khader proposed openstack/os-vif master: Add create_port field in VIFPortProfileOpenVSwitch profile https://review.openstack.org/636061 | |
| 14:17:08 | stephenfin | kaisers: Sweet. I've left comments on the systemd one. Might be as easy discuss here if you disagree | |
| 14:17:41 | stephenfin | kaisers: I'm well aware of how many revisions it's gone through too. Sorry :( | |
| 14:22:39 | kaisers | stephenfin: mmh, driver changes have outgrown the tests, I'm going through those... | |
| 14:32:43 | cdent | aspiers: was on a walk. parsing that image... | |
| 14:36:50 | mriedem | melwitt: so on https://review.openstack.org/#/c/633351/ you're picking up a marker instance record from an earlier data migration | |
| 14:36:55 | mriedem | and that marker instance doesn't have a user_id set | |
| 14:36:58 | mriedem | hence the infinite loop | |
| 14:37:04 | stephenfin | kaisers: Addressed the other one too https://review.openstack.org/#/c/522245/ | |
| 14:38:03 | kaisers | stephenfin: thnx! | |
| 14:38:30 | mriedem | melwitt: this is the migration that creates the marker instance with the 0'ed uuid and no user_id https://github.com/openstack/nova/blob/ab5a9bba31664e74c1e866c620b0d284d1d4f4cb/nova/objects/virtual_interface.py#L301 | |
| 14:39:45 | mriedem | there must also be a data migration that creates a marker instance mapping with the same 00000000-0000-0000-0000-000000000000 uuid | |
| 14:44:35 | aspiers | mriedem: please can you sanity check my understanding too? https://pasteboard.co/I1Tbzp2.png | |
| 14:45:45 | mriedem | the capabilities patch being the one you're trying to rebase? | |
| 14:45:50 | mriedem | then yes i think so | |
| 14:46:00 | aspiers | yes, that one | |
| 14:46:13 | aspiers | well, I've succeeded in rebasing it ;-) the struggle now is finishing off the tests | |
| 14:46:15 | mriedem | the compute "owns" the capabilities it reports, and if something external removes it then it will get put back on the next periodic task run | |
| 14:46:40 | mriedem | if an admin wants to schedule around hosts with a given capability, they use forbidden traits in their flavor | |
| 14:47:01 | aspiers | but the driver can still provide other traits outside this new capabilities-to-traits mechanism, right? like cpu flags etc. | |
| 14:47:14 | mriedem | correct | |
| 14:47:29 | aspiers | but it can also provide CUSTOM_* stuff which isn't capabilities? | |
| 14:47:41 | mriedem | the libvirt driver would be reporting traits that are both cpu flags and capabilities, like COMPUTE_SUPPORTS_MULTIATTACH or whatever | |
| 14:47:56 | mriedem | no i don't think so | |