| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-05-30 | |||
| 08:08:29 | sean-k-mooney[m] | bauzas: why the 14 we said it shold be milestone 2 | |
| 08:08:38 | bauzas | ie. 2 weeks after milestone-2, which itself is the spec review day | |
| 08:08:58 | bauzas | sean-k-mooney: we discussed this at the PTG and you reviewed the schedule change :) | |
| 08:09:06 | sean-k-mooney[m] | right but that is not what we normally do so why are we giving 2 addtional weeks | |
| 08:09:38 | bauzas | I can't remember the why | |
| 08:09:54 | bauzas | look at the etherpad | |
| 08:09:58 | sean-k-mooney[m] | fine i guess we can but if we are still at spec review time in the midle of july your spec is proably not going to get finsihed | |
| 08:10:12 | mikal | Also, I am open to horse trading. Like if someone would like me to review or assist with something else to earn karma for my stuff, then that's fine. I tried to review some other specs along those lines, but must admit I haven't in the last few weeks. | |
| 08:10:15 | sean-k-mooney[m] | ya i missed a lot of the ptg this time because of time zones | |
| 08:12:08 | sean-k-mooney[m] | i missed the reto and plannign disccustion and basiclly the firsr 90 mins or so of every day since there was no upstream ping and i was off by 1 | |
| 08:13:04 | bauzas | mikal: that's a kind offer but you shouldn't need it :) | |
| 08:13:17 | bauzas | we'll review your spec like others :) | |
| 08:13:34 | bauzas | (I just need a way to work concurrently better :D ) | |
| 08:13:45 | mikal | Ok. I know back in the day we used to tell people to go review some other stuff if they wanted their stuff reviewed. That is, not just the core team should be reviewing things. | |
| 08:14:18 | sean-k-mooney[m] | mikal: for what its worth since i didnt see an update on it for 30 days i assumd it had not changes since i last looked | |
| 08:14:20 | sean-k-mooney[m] | but i guess i missed the post ptg update | |
| 08:15:09 | mikal | sean-k-mooney[m]: "didn't see" means in email? | |
| 08:15:24 | mikal | But yeah, I just updated it and then went into a wait state. | |
| 08:15:55 | sean-k-mooney[m] | well reviews are always wellcome but that really only worked/works in my view as a side efffect of “oh this person is doing review, wasnt i ment to review there stuff too” i.e. seeing your name in gerrit reminds me of the fact i proably should have gotten back to reviewing your spec/patch | |
| 08:17:11 | sean-k-mooney[m] | didnt see in that on the spec review day i either looked before you updatd it or a few days after. so i had a spliting headache that day so i didnt do much review on that day and loopped back later in the week | |
| 08:17:38 | sean-k-mooney[m] | and i only looked at specs that had recent updates | |
| 08:17:49 | sean-k-mooney[m] | i must have missed yours | |
| 08:19:13 | sean-k-mooney[m] | mikal: do you have any devstack support or anything we can eaisiy setup to play with kerbside? when we get to reviewing the code it would be nice to eaisly deploy both | |
| 08:20:22 | mikal | No, I haven't done anything to integrate with devstack yet. I'm not opposed, but haven't done it. What I do have is a reasonably well documented process to build a set of Kolla-Ansible containers, as that's why my dev environment is using. | |
| 08:20:36 | mikal | s/why/what/ | |
| 08:21:57 | mikal | Kerbside itself is pretty simple to deploy. The complicated bit is landing the 20ish patches across various OpenStack projects to get it all wired up and pretty. | |
| 08:22:15 | sean-k-mooney[m] | ack, i like kolla-ansible although thats more useful for deploying kerbside then master for dev. that said i know they had an experimental dev mode that used git repos | |
| 08:22:21 | sean-k-mooney[m] | i just never got around to using that | |
| 08:22:23 | mikal | The complete set of patches is at https://github.com/shakenfist/kerbside-patches for what its worth. | |
| 08:23:12 | mikal | I've been working on publishing patched containers, but its taken longer than I'd like it to because I have a moral issue with running docker registry on my limited hosting resources and the complete set of Kolla-Ansible containers is pretty big. | |
| 08:23:57 | sean-k-mooney[m] | its about 8 GB of disksapace if i recall | |
| 08:24:15 | sean-k-mooney[m] | its been a while since i built them once you account for all the layer sharing | |
| 08:24:31 | mikal | Yeah, its 60+gb with unshared layers, about 6 IIRC with shared layers. | |
| 08:24:33 | sean-k-mooney[m] | prebuilt images isnt a requirement | |
| 08:24:56 | mikal | The readme in the patch repository documents by build process. | |
| 08:25:13 | mikal | Rebasing the patches is also a pretty good way to find mypy breakages in openstacksdk it turns out. | |
| 08:26:13 | sean-k-mooney[m] | hehe | |
| 08:26:38 | sean-k-mooney[m] | im partly surpsied you are not just keeping forked branches of each of the project | |
| 08:26:46 | sean-k-mooney[m] | and maintianin patches instead | |
| 08:26:50 | mikal | I am trying very hard to not be a bad person. | |
| 08:27:15 | mikal | I also backport all the patches to a bunch of openstack versions because I am fun at parties. | |
| 08:27:23 | sean-k-mooney[m] | why would having a fork be bad everyone has local forks :) | |
| 08:27:52 | mikal | I spent a lot of time arguing against forks in my youth. | |
| 08:28:05 | sean-k-mooney[m] | what you really need to aovid is getting on the hook with this in production for protracted periods of time without upstreaming | |
| 08:28:37 | mikal | Yeah agreed, that would suck. | |
| 08:28:51 | sean-k-mooney[m] | well normally i would either rjust submit the patches to gerrit or host them in a gitbub branch | |
| 08:28:57 | sean-k-mooney[m] | preferbally the former | |
| 08:29:35 | sean-k-mooney[m] | since that makes them aviable for review and eaislly downloadable in a working git tree | |
| 08:29:43 | mikal | I'd be happy to do that. I had kind of assumed people would find that annoying until the spec is approved. That said, a lot of the nova patches are fairly vanilla -- add a sound card, add some USB passthrough devices, enforce network encryption, etc etc. | |
| 08:30:18 | mikal | I also haven't really chased down any of the other openstack projects because there's not a lot of point until nova agrees to land the key bit. | |
| 08:31:31 | sean-k-mooney[m] | so it depend on if you follow the letter of the law or are pratical. our docs say you should not start writign the code until the specc is merged but practically speaking most people at least do a poc. and as long as your are not rebasing them alot and using lots of ci resouce there is noharm in pushing them | |
| 08:32:06 | mikal | Yeah, those patches haven't changed in a couple of months so there wouldn't be a lot of CI load. | |
| 08:32:11 | mikal | I'll add pushing them to my todo list. | |
| 08:33:27 | sean-k-mooney[m] | by the way kolla only builds debian images now as far as im aware so you probaly dont need the rpm supprot anymore in your kolla series | |
| 08:34:07 | sean-k-mooney[m] | not that that saves much since its only 4 lines or so but just tought i would mention it | |
| 08:36:15 | mikal | Oh interesting. I only build debian images anyways because RHEL dropped SPICE support which is kind of awkward for me right now. | |
| 08:39:18 | sean-k-mooney[m] | ya… redhat strop all development of spice and removed supprot for it in our version of qemu when the only person that work on spice on our virt/qemu team left | |
| 08:39:40 | sean-k-mooney[m] | they may of left because of the decsion to drop spice im not sure | |
| 08:39:58 | sean-k-mooney[m] | but in rhel 9 it got compiled out | |
| 08:40:41 | sean-k-mooney[m] | i dont know of any plans to every change that going forward | |
| 08:40:59 | sean-k-mooney[m] | if kerbside takes off who knows | |
| 08:41:49 | sean-k-mooney[m] | mikal: kolla still support installing on other distos they just use the debian image for that now | |
| 08:42:36 | sean-k-mooney[m] | i used to use ubuntu-source as my build target for kolla in the past, i never had issues with that on ubuntu or centos | |
| 08:43:04 | sean-k-mooney[m] | anyway im going to go grab a coffeee and move from my ipad to my desk o/ | |
| 08:47:15 | mikal | No worries, thanks for the chat. | |
| 08:51:40 | sean-k-mooney | gibi: bauzas: when ye have time can ye re reivew my ci fix for the emulation job https://review.opendev.org/c/openstack/nova/+/918464 | |
| 08:51:48 | bauzas | ack | |
| 09:32:24 | opendevreview | Marlin Cremers proposed openstack/nova master: feat: set rotation rate on disks based on rotation rate from volume https://review.opendev.org/c/openstack/nova/+/920818 | |
| 09:34:16 | opendevreview | Marlin Cremers proposed openstack/nova master: libvirt: set rotation rate on disks based on rotation rate from volume https://review.opendev.org/c/openstack/nova/+/920818 | |
| 09:43:09 | opendevreview | Marlin Cremers proposed openstack/nova master: libvirt: set rotation rate on disks based on rotation rate from volume https://review.opendev.org/c/openstack/nova/+/920818 | |
| 09:49:53 | marlinc | Hello there, I'm trying to contribute a small change to introduce support for the libvirtd rotation_rate flag for volumes. Now I'm wondering if I have to also create a spec alongside a blueprint for this | |
| 09:50:40 | marlinc | And I'm also wondering if I should also do this for cinder as it uses a new field in the connection_info from cinder | |
| 09:50:55 | marlinc | I have already written a small blueprint for this https://blueprints.launchpad.net/nova/+spec/rotation-rate | |
| 09:55:14 | opendevreview | Marlin Cremers proposed openstack/nova master: libvirt: set rotation rate on disks based on rotation rate from volume https://review.opendev.org/c/openstack/nova/+/920818 | |
| 12:26:34 | sean-k-mooney | marlinc feature by default are tracked as bluepirnt, we only require specs if there is an upgrade impact which this may or may not have when it comes to live migraton | |
| 12:27:03 | sean-k-mooney | we suppoirt compute nodes of up to n-2 or speciicly the previous slurp release | |
| 12:27:12 | sean-k-mooney | in thei case that n-1 | |
| 12:27:29 | sean-k-mooney | so we need to supprot live migrating form master to the previous relese | |
| 12:28:58 | sean-k-mooney | marlinc i see your irc client disconnected but ill capture it here in teh logs. what we woudl need to confirm is is there a live migration impact. i think yes. then we need to determin how to adress that. | |
| 12:29:50 | sean-k-mooney | the case that i am concerned about breaking is live migratine form n to n-1 and then back to n | |
| 12:30:40 | sean-k-mooney | if that work then the only other thing we should need to conifm is when was rotation_rate added and is it supported in our min libvirt version | |
| 12:31:05 | sean-k-mooney | those are the two main upgrade concerns since this is a dirver only change | |
| 12:31:34 | sean-k-mooney | "rotation_rate" attribute value since 7.3.0 | |
| 12:32:18 | sean-k-mooney | our min supported libvirt is 7.0.0 | |
| 12:32:25 | sean-k-mooney | so the patch also need to accomidate for that. | |
| 12:32:50 | sean-k-mooney | nova will not allow you to live migrate to an older libvirt | |
| 12:33:06 | sean-k-mooney | so you just need that check on the source node (the upgraded node) | |
| 12:33:20 | sean-k-mooney | ill metion thsi in the reveiw | |
| 15:11:53 | opendevreview | Arnaud Morin proposed openstack/nova master: libvirt: Log exception if failure checking block job https://review.opendev.org/c/openstack/nova/+/907720 | |
| 15:30:16 | opendevreview | Arnaud Morin proposed openstack/nova master: libvirt: Add retry on device job operation timeout https://review.opendev.org/c/openstack/nova/+/907730 | |
| #openstack-nova - 2024-05-31 | |||
| 10:44:11 | opendevreview | Merged openstack/nova master: add functional repoducer for bug 2065927 https://review.opendev.org/c/openstack/nova/+/920119 | |
| 13:58:51 | opendevreview | Marlin Cremers proposed openstack/nova master: libvirt: set rotation rate on disks based on rotation rate from volume https://review.opendev.org/c/openstack/nova/+/920818 | |
| #openstack-nova - 2024-06-03 | |||
| 08:06:37 | opendevreview | Zhang Hua proposed openstack/nova master: BlockDeviceMapping object has no attribute copy https://review.opendev.org/c/openstack/nova/+/920374 | |
| 08:53:33 | opendevreview | Maxime Lubin proposed openstack/nova master: libvirt: add power management xml handling https://review.opendev.org/c/openstack/nova/+/920993 | |
| 08:53:34 | opendevreview | Maxime Lubin proposed openstack/nova master: libvirt driver: configure power management behavior from flavor metadata https://review.opendev.org/c/openstack/nova/+/920994 | |
| 12:14:07 | andrewbonney | Hi. Unless there's a specific review session which could cover it, any further reviews of https://review.opendev.org/c/openstack/nova/+/919961 would be appreciated. Thanks | |
| 12:52:20 | opendevreview | Merged openstack/nova stable/2023.1: Fix nova-manage image_property show unexpected keyword https://review.opendev.org/c/openstack/nova/+/914766 | |
| 14:26:49 | opendevreview | ribaudr proposed openstack/nova master: Amend ShareMappingStatus due to asynchronous call https://review.opendev.org/c/openstack/nova/+/908864 | |
| 14:26:50 | opendevreview | ribaudr proposed openstack/nova master: Amend DB model add a unique constraint. https://review.opendev.org/c/openstack/nova/+/912518 | |
| 14:26:50 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (manila abstraction) https://review.opendev.org/c/openstack/nova/+/831194 | |