| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-01-25 | |||
| 16:41:26 | sean-k-mooney | gibi: thanks :) | |
| 16:46:21 | opendevreview | Merged openstack/os-traits master: Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/os-traits/+/824050 | |
| 16:48:08 | opendevreview | Merged openstack/os-traits master: Add a trait for remote_managed port-capable nodes https://review.opendev.org/c/openstack/os-traits/+/818514 | |
| 16:52:00 | opendevreview | sean mooney proposed openstack/os-traits master: Add Train Ussuri Victoria release info https://review.opendev.org/c/openstack/os-traits/+/768889 | |
| 16:55:45 | sean-k-mooney | does anyone rememeber what that sate of owner traits is | |
| 16:55:50 | sean-k-mooney | https://review.opendev.org/c/openstack/os-traits/+/770569 | |
| 16:56:12 | sean-k-mooney | did we decided we were going to add them or not | |
| 16:56:30 | sean-k-mooney | im looking at what patches are old and can be abandonded | |
| 16:57:29 | sean-k-mooney | looking at the ptg gibi you were goign to work on a spec fo addign a OWNER_NOVA trait https://etherpad.opendev.org/p/nova-yoga-ptg#L77 | |
| 16:58:29 | sean-k-mooney | that was https://review.opendev.org/c/openstack/nova-specs/+/819510 | |
| 16:58:42 | gibi | sean-k-mooney: there was somebody from cyborg promised to look into it | |
| 16:58:52 | sean-k-mooney | but we are past the deadline so i guess we will pick it up next cycle again | |
| 16:59:02 | sean-k-mooney | gibi: ya the proposed a spec | |
| 16:59:03 | gibi | yepp the spec is stalled out on upgrade impact | |
| 16:59:10 | sean-k-mooney | ah ok | |
| 16:59:25 | sean-k-mooney | ill abandon the os-traits patch for now and link to the spec | |
| 16:59:40 | sean-k-mooney | we can reopen the review when we figure out the upgrade bit | |
| 17:01:43 | gibi | OK, thanks | |
| 17:02:20 | sean-k-mooney | elodilles: do you know where the release team hang out on irc | |
| 17:02:48 | sean-k-mooney | i guess i coudl hop on infra too | |
| 17:03:09 | sean-k-mooney | elodilles: just wonderign what the status of [release][infra] SSH host key issue - RedFlag stop approving is | |
| 17:03:14 | sean-k-mooney | ill swap to infra | |
| 17:04:36 | elodilles | sean-k-mooney: #openstack-release | |
| 17:05:59 | elodilles | sean-k-mooney: infra team is working on it, but hopefully will be fixed soon | |
| 17:08:01 | sean-k-mooney | elodilles: ack ill create the os-traits releaes patch so in parallel but obvioulys that will fail with the same issue. | |
| 17:18:35 | elodilles | sean-k-mooney: check jobs will pass, and release team won't approve it until the tag job isn't fully functional :) | |
| 17:19:06 | elodilles | sean-k-mooney: so feel free to propose the patches, it won't be a problem | |
| 17:20:27 | sean-k-mooney | ack was gettign coffee :) | |
| 17:22:16 | ralonsoh | sean-k-mooney, https://review.opendev.org/c/openstack/neutron-lib/+/645288/6/releasenotes/notes/new-vif-details-parameters-71e70ab5e7c26c45.yaml | |
| 17:22:45 | ralonsoh | I totally forgot that: "bound_drivers", that is already in n-lib since Train | |
| 17:23:06 | ralonsoh | this is what you need (and Neutron needs to populate right now) | |
| 17:23:26 | sean-k-mooney | ralonsoh: oh i know i rememebre it and pointed it out in the spec review | |
| 17:23:37 | sean-k-mooney | i was not sure why you were not using it and addign backend | |
| 17:23:49 | ralonsoh | yeah, I think this is the right parameter to populate | |
| 17:24:00 | ralonsoh | why? we never implemented that hehehe | |
| 17:24:05 | ralonsoh | I'll start now | |
| 17:24:32 | sean-k-mooney | proably a donwstream esclation caused a context switch that has just been unsuspended in your brain :) | |
| 17:25:01 | ralonsoh | or too much beer during weekend | |
| 17:25:04 | ralonsoh | most probably | |
| 17:25:11 | sean-k-mooney | ralonsoh: its not critical but the sunner its avaiabel the soone we can use it | |
| 17:25:17 | ralonsoh | for sure | |
| 18:39:58 | sean-k-mooney | bauzas: https://review.opendev.org/c/openstack/releases/+/826353 os-traits 2.7.0 release | |
| #openstack-nova - 2022-01-26 | |||
| 10:58:05 | kashyap | sean-k-mooney: I don't think we want to backport this to Xena/Wallaby, do we? - https://review.opendev.org/c/openstack/nova/+/798680 | |
| 10:58:33 | kashyap | sean-k-mooney: Downstream distros may backport it for their own needs, but from an upstream PoV, not - because the releases were already out | |
| 11:23:12 | sean-k-mooney | no this is not a backport candiate upstream its a blueprint not a bug | |
| 11:23:36 | sean-k-mooney | so by definition it cant be backported upstream | |
| 11:25:08 | kashyap | Yeah, yeah...there's always potential exceptions (not in this case) :) | |
| 11:28:34 | sean-k-mooney | kashyap: no i dont think we have broken that rule | |
| 11:28:43 | sean-k-mooney | this would not be a candiate as you said | |
| 11:29:06 | sean-k-mooney | but i dont think we have backported blueprints as an excption in the the past | |
| 11:29:53 | sean-k-mooney | we have converted them to a bug premtivly when we agreed it shoudl be adressed as a bug but i dont think we have ever done it retro activly | |
| 11:29:54 | kashyap | I think we definitely did at one point, I'm forgetting which one. Not obviously a huge feature, but a targetted one that was also helped w/ a security fix | |
| 11:30:39 | sean-k-mooney | i guess a cve might be a valid reason to cirumvent our normal process if it could not be fixed any other way | |
| 11:31:07 | kashyap | Yep, that's what I meant | |
| 11:33:14 | sean-k-mooney | that specific case is not ringing a bell but i also dont follow all the backports we do as well as i proably should | |
| 11:33:41 | kashyap | That's fine; following all backports takes up too much cognitive load (at least for me) | |
| 12:56:39 | plibeau2 | hello, I have add some comment on my proposal: https://review.opendev.org/c/openstack/nova/+/803713 I'm available to discuss with you. QEMU community has reply also. | |
| 13:29:09 | kashyap | plibeau2: Hi, I've responded to your question on qemu-devel | |
| 13:30:07 | kashyap | plibeau2: I think we can at least do the first step here as a patch: moving the freeze call after end of disk mirroring. | |
| 13:30:26 | kashyap | After that, any additions on top should be done separately. ("One logical change per patch.") | |
| 13:30:41 | kashyap | (I say it because we've identified a few more things on 'qemu-devel' list and on Gerrit review) | |
| 13:54:33 | gibi | does anybody know if and how the python logging can be enable during placement gabbi tests? | |
| 13:54:58 | sean-k-mooney | i assume you can export OS_DEBUG=1 | |
| 13:55:02 | sean-k-mooney | to get debug logging | |
| 13:55:09 | sean-k-mooney | on failure | |
| 13:55:31 | sean-k-mooney | i would have to look at how the logging fixture we use it implemented beyond that | |
| 13:55:44 | sean-k-mooney | are you looking for logs in the success case | |
| 13:56:36 | gibi | for gabbi tests there is no python logging output at all | |
| 13:56:43 | gibi | even if the test fails | |
| 13:56:47 | sean-k-mooney | gibi: by the way i broke placment with the os-traits release as i need to update the number of expecte traits which was expected. | |
| 13:56:55 | gibi | I tried OS_DEBUG without success | |
| 13:56:55 | sean-k-mooney | ill be pushing a ptach for that shortly | |
| 13:56:59 | sean-k-mooney | ack | |
| 13:57:11 | gibi | sean-k-mooney: yeah, os-trait releases always do that | |
| 13:57:16 | gibi | sean-k-mooney: ping me and I will approve the fix | |
| 13:57:23 | sean-k-mooney | will do | |
| 13:58:53 | sean-k-mooney | im just trying to see how gabbit tests are run | |
| 14:00:55 | sean-k-mooney | i wonder if there are any flags we can pass to https://github.com/cdent/gabbi | |
| 14:01:56 | sean-k-mooney | maybe -v https://github.com/cdent/gabbi/blob/main/gabbi/runner.py#L246-L250 i have never actuly run those | |
| 14:04:25 | gibi | sean-k-mooney: that would log the HTTP request / response information. I would need to look at the placement service logs | |
| 14:05:32 | sean-k-mooney | ack gabbit is spwaning a placment instance for each test right i wonder how logging is configured and if we are passing a config | |
| 14:06:13 | sean-k-mooney | it would be nice to beable to use gabbit for debuging this way | |
| 14:06:23 | gibi | https://github.com/openstack/placement/blob/master/placement/tests/functional/fixtures/gabbits.py#L62-L71 | |
| 14:06:31 | gibi | I probably need to tweak ^^ | |
| 14:07:11 | sean-k-mooney | ah you found it i did not know where the gabit fixutres were but i proably shoudl have looked there | |
| 14:08:11 | sean-k-mooney | if the loggs were reddirected to standard out/error then they woudl be aviable on failure | |
| 14:08:49 | sean-k-mooney | https://github.com/openstack/placement/blob/master/placement/tests/functional/fixtures/capture.py#L38-L60 | |
| 14:09:14 | sean-k-mooney | so its using the null handeler | |
| 14:09:26 | sean-k-mooney | we shoudl updat that to log to standard out/error | |
| 14:09:49 | sean-k-mooney | or do that based on an enviornment varable | |
| 14:09:58 | sean-k-mooney | so do that when you do OS_DEBUG=1 | |
| 14:10:45 | sean-k-mooney | that way it wont explode the subunit output normally | |
| 14:25:39 | gibi | sean-k-mooney: thanks | |
| 14:32:01 | gsantos | Hey folks, I'm working on a few vGPU features and trying to find a way to live migrate guests with a vGPU/mdev attached, but stumbled upon a libvirt function that says migrating guests with non-USB devices is forbidden. Have any of you guys tried this in the past and can confirm if it is, in fact, not possible to be done? | |
| 14:32:53 | sean-k-mooney | gsantos: you cant today | |
| 14:33:10 | sean-k-mooney | gsantos: qemu and the kernel do not suport live migrating with mdevs currently | |
| 14:33:27 | sean-k-mooney | gsantos: that is changing but proably 6 months before upstream can support live migrating | |
| 14:33:53 | sean-k-mooney | then we can add support in nova | |
| 14:34:39 | sean-k-mooney | speaking to people internally we are hoping that a new live migration capablity will be reported via sysfs which can then be reported by libvirt or quired by nova. | |
| 14:35:20 | sean-k-mooney | both the dest and source host have a new enough kernel and qemu then nova could allow the migratoin to proceed but right now its not possibel to transfer the guest vgpu state as part of the live migration | |