| gibi | o/ | 07:27 |
|---|---|---|
| bauzas | \o | 07:27 |
| Uggla | o/ | 07:29 |
| bauzas | hmmmm, Kendall is asking me a few questions about the PTG | 07:48 |
| bauzas | I guess this email was sent to all PTLs | 07:49 |
| bauzas | tl:dr: the Foundation wants to invite ops at the PTG, which I think is an excellent proposal | 07:49 |
| bauzas | but now, in order to make this happen, we somehow have to showcase a bit and think how we could make their trip valuable | 07:49 |
| bauzas | if people are willing to, we can brainstorm a bit about those 4 questions she sent | 07:50 |
| bauzas | 1/ what do we want to hear from ops at the PTG | 07:50 |
| bauzas | 2/ what topics are on our PTG agenda (yet) | 07:51 |
| bauzas | 3/ what are the goals for the Columbus PTG ? | 07:51 |
| bauzas | 4/ what contributors think about an extra day on Friday if there is an Ops sessions day ? | 07:52 |
| MichielPiscaer[m] | I as ops person, I'm planning to got to the PTG. I think the main question is what do you want to know from me as operator. | 07:53 |
| gibi | bauzas: good questions. I think we should fire up an etherpad to collect the answers from the team | 08:02 |
| bauzas | gibi: this was my approach | 08:02 |
| bauzas | II don't want to hold that much to reply to diablo_rojo | 08:03 |
| bauzas | so ideally, I'd appreciate if I could reply by tomorrow (hence that not being discussed at the nova meeting) | 08:03 |
| bauzas | also, Kendall is asking whether we agree on publishing our responses into some superuser blog | 08:04 |
| bauzas | MichielPiscaer[m]: oh, thanks for your feedback, extremely valuable | 08:04 |
| bauzas | MichielPiscaer[m]: in general, we appreciate some ops presence in the room for challenging the usecases | 08:05 |
| bauzas | during the last 3 virtual PTGs, we didn't really went into deepdive design sessions, so I feel ops couldn't be that disconnected from the talks | 08:06 |
| gibi | bauzas: #1) new use cases, pain points, general info about what they are using (services, versions, configuration) | 08:08 |
| gibi | bauzas: #2) I will definielty talk about PCI in placement :) but not much else on my agenda so far | 08:09 |
| gibi | bauzas: #3) plan the AA (and BB cycle) | 08:09 |
| bauzas | I'm just creating the etherpad with my notes | 08:09 |
| gibi | bauzas: #4) I'm happy to have an extra day with Ops | 08:09 |
| bauzas | me too | 08:10 |
| gibi | ack, I will update the etherpad too | 08:10 |
| sean-k-mooney | gibi: i am hoping it will be functinal if but not nessisarly on by default in AA | 08:12 |
| bauzas | https://etherpad.opendev.org/p/nova-ptg-columbus-ops-presence | 08:12 |
| bauzas | gibi: add your points to the agendaz | 08:13 |
| sean-k-mooney | i would potentialy like to see the mdev support evloved to build in pci in placment and the pci track ro move to the resouces table like pmem overtime | 08:13 |
| gibi | sean-k-mooney: yepp I think we still have a chance to have the non neutron part in Zed, and then the neutron part in AA | 08:13 |
| sean-k-mooney | gibi: ack i would personally hold enabling by default until we have parity | 08:13 |
| sean-k-mooney | so likely BB | 08:13 |
| bauzas | tbc, this is a bit premature to know what the topics will be | 08:13 |
| gibi | sean-k-mooney: I agree with keeping off by default until we have full parity | 08:14 |
| sean-k-mooney | bauzas: all topic sure but we will have some in the back of our minds | 08:14 |
| bauzas | sean-k-mooney: then add them to the etherpad I mentioned | 08:15 |
| bauzas | and I'll summarize those | 08:15 |
| sean-k-mooney | bauzas: we ususally have a corss project day on monday should we make that ops and cross project | 08:15 |
| bauzas | keeping in mind most ops are running pre-Train :) | 08:15 |
| bauzas | so most of our semantics are mostly unknown by them :) | 08:16 |
| bauzas | sean-k-mooney: looks like there will be a ops day on Friday | 08:16 |
| bauzas | point is, we need a productive PTG | 08:17 |
| sean-k-mooney | i tought the ptg ended thrusday offically | 08:17 |
| bauzas | sean-k-mooney: see above | 08:17 |
| sean-k-mooney | October 17-20, 2022 | 08:17 |
| bauzas | sean-k-mooney: yes, this would be an extra day, a ops summit day if you prefer | 08:17 |
| sean-k-mooney | ack i was looking at flight if they want to add that they shoudl do it very very soon | 08:18 |
| sean-k-mooney | as some might be plannign to fly back on friday | 08:18 |
| * gibi updated the etherpad | 08:19 | |
| bauzas | sean-k-mooney: honestly, I don't look at flights until I get the green light | 08:20 |
| bauzas | sean-k-mooney: but you're absolutely free to *not* attend this extra day | 08:20 |
| bauzas | again, see the etherpad | 08:20 |
| sean-k-mooney | if it goies ahead and im there i will | 08:20 |
| bauzas | "If there was an extra day (Friday, October 21 of Operator sessions), would contributors from your team be interested in participating? " | 08:20 |
| sean-k-mooney | but i would annoyed at the foundation if it was added late and could not attend because i had arranged things | 08:21 |
| sean-k-mooney | or had to adjust flights or hotel booking | 08:21 |
| sean-k-mooney | bauzas: personaly i think havign the ops session on friday does not make sense | 08:22 |
| sean-k-mooney | if they do that i would prefer to see it on monday | 08:22 |
| sean-k-mooney | and shift the ptg to start on tuesday to friday | 08:22 |
| gibi | yeah I agree, probably we need the general input (Ops, cross project) earlier | 08:22 |
| sean-k-mooney | flight in on moday are cheaper then sunday | 08:23 |
| sean-k-mooney | as are hotels | 08:23 |
| sean-k-mooney | so those that dont plan to attend will have reduced cost | 08:23 |
| bauzas | I personnally feel brave enough to propose some nova agenda intended to be 'ops-understandable' by tuesday | 08:23 |
| sean-k-mooney | it also mean we can get the feedback before our seesion | 08:23 |
| bauzas | and us preventing to go into deep-dive whiteboarding sesssions until wed | 08:24 |
| bauzas | (because yes, this time, we should have a whiteboard :D ) | 08:24 |
| sean-k-mooney | maybe but why tuseday and not monday | 08:24 |
| bauzas | nova-specifics | 08:24 |
| bauzas | having ops only on monday is nice but doesn't help our project | 08:25 |
| bauzas | and if we don't make something to invite them in our room, they won't come | 08:25 |
| sean-k-mooney | ok so you want monday to be crossprojct/tc and general ops | 08:25 |
| bauzas | they could be in the hallways or in another room | 08:25 |
| sean-k-mooney | then tueday ops frieldy but nova specific | 08:25 |
| bauzas | -ish but yeah, you got my idea | 08:25 |
| sean-k-mooney | and deepdive on wednesday and thursday on nova specifics | 08:26 |
| sean-k-mooney | ok | 08:26 |
| bauzas | this is just an idea | 08:26 |
| bauzas | but we need to welcome them and make them sure they'll understand our language if they come | 08:26 |
| sean-k-mooney | yep | 08:29 |
| sean-k-mooney | which also might meen keeping slot free later in the week to be pland based on the hallway track and ops day | 08:29 |
| bauzas | that's why I think we reasonably need a single day ops-friendly | 08:33 |
| bauzas | or rather ops-welcome | 08:33 |
| bauzas | the two other days wouldn't mean ops would be unfriendly | 08:33 |
| bauzas | but we won't refrain ourselves to go into deepdive sessions if we feel we need to | 08:34 |
| sean-k-mooney | ops are always welcome :) | 08:38 |
| sean-k-mooney | well to me the ptg/design summit alwyas had 2 reasons to exist | 08:39 |
| sean-k-mooney | direct feedback form ops/user/project about pain points | 08:39 |
| sean-k-mooney | and brainstorming/deepdiving a problem with all that are interested in it | 08:39 |
| bauzas | yup | 08:43 |
| bauzas | gibi: could you please review https://review.opendev.org/c/openstack/nova/+/849133 even if we need to wait for unshelve | 09:10 |
| bauzas | ? | 09:10 |
| gibi | bauzas: ack | 09:10 |
| bauzas | gibi: sean-k-mooney already provided me a +2 | 09:10 |
| sean-k-mooney | you keypair change | 09:11 |
| sean-k-mooney | yes did you update it to disallow space or is that still allowed | 09:11 |
| sean-k-mooney | im ok either way as long as we are intentional about it | 09:11 |
| gibi | bauzas: you will come after auniyal's evac issue and the downstream cpupinning troubleshooting :) | 09:11 |
| bauzas | sean-k-mooney: we were accepting the spacs before | 09:11 |
| sean-k-mooney | bauzas: ack | 09:12 |
| bauzas | spaces* | 09:12 |
| sean-k-mooney | bauzas: cool ill try and review this again today or tomorrow | 09:12 |
| bauzas | sean-k-mooney: there is a -W | 09:12 |
| bauzas | because this is a 2.92 | 09:12 |
| sean-k-mooney | ah was just going to ask | 09:12 |
| bauzas | nothing changed from the 2.91 revision | 09:12 |
| bauzas | just I asked for 2.92 | 09:12 |
| sean-k-mooney | ok so this is quede behind which sepc | 09:13 |
| sean-k-mooney | unshleve | 09:13 |
| sean-k-mooney | or tenatn id | 09:13 |
| bauzas | sean-k-mooney: https://etherpad.opendev.org/p/nova-zed-microversions-plan | 09:13 |
| bauzas | should be unshelve | 09:14 |
| sean-k-mooney | bauzas: do we want to add that to the chagne topic | 09:15 |
| bauzas | which topic, sorry ? | 09:16 |
| sean-k-mooney | the #openstack-nova topic | 09:17 |
| sean-k-mooney | its currently "This channel is for Nova development. For support of Nova deployments, please use #openstack" | 09:17 |
| sean-k-mooney | we used ot have the runway link there | 09:17 |
| sean-k-mooney | we coudl add that if you think it woudl help | 09:18 |
| bauzas | I didn't had time to provide an email yet | 09:18 |
| sean-k-mooney | if not its fine | 09:18 |
| bauzas | but I'll do it | 09:18 |
| MichielPiscaer[m] | bauzas: I think that when ops travel to the PTG, they are probably newer then pre-train. | 09:25 |
| sean-k-mooney | MichielPiscaer[m]: yes that has been my expiricne as well | 09:25 |
| sean-k-mooney | the ones that only attend the summit/fourm are slower moving | 09:26 |
| sean-k-mooney | the ones that know about and attend the PTG tend to run more recent versions and be more familar with how the comunity works and be more invovled in general | 09:26 |
| MichielPiscaer[m] | indeed | 09:28 |
| EugenMayer | after i upgraded to the latest xena serias with kolla, my nova docker container fails to authenticate to libvirt due to the new sasl password | 10:16 |
| EugenMayer | 2022-07-21 09:19:23.586+0000: 6539: error : virNetSASLSessionServerStep:594 : authentication failed: Failed to start SASL negotiation: -20 (SASL(-13): user not found: unable to canonify user and get auxprops) | 10:16 |
| EugenMayer | i ensure i merged the inventory/password file properly, but i seem to now be able to fix it via kolla. Is there a way i could fix that on nova's side manually= | 10:17 |
| EugenMayer | my question would be, where would the sasl password be configured | 10:20 |
| sean-k-mooney | EugenMayer: sorry had wifi issue | 10:29 |
| sean-k-mooney | EugenMayer: in the libvirt section we have an optional connection uri option | 10:29 |
| sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.connection_uri | 10:29 |
| sean-k-mooney | EugenMayer: you may be able ot workaround your auth issues by adding parmaters to that | 10:30 |
| sean-k-mooney | EugenMayer: https://libvirt.org/uri.html | 10:30 |
| sean-k-mooney | is the libvift docs | 10:30 |
| EugenMayer | what i did is i ran 'saslpasswd2 -c -p -a libvirt nova' with the sasl pw on the libvirt container | 10:30 |
| EugenMayer | and verified that the auth.conf for nova has the same user/password | 10:31 |
| sean-k-mooney | EugenMayer: auth.conf? | 10:33 |
| sean-k-mooney | i assume that is a libvirt config file | 10:33 |
| EugenMayer | that's a kolla config, but i guess it is mounted into nova, let me inspect the docker containerh | 10:34 |
| sean-k-mooney | EugenMayer: i think the problem you are having is that you are tryign to use a libvirt feature that nova has no offical supprot for | 10:34 |
| sean-k-mooney | EugenMayer: it might be possibel to make it work | 10:35 |
| sean-k-mooney | but its not documenated as supported so its not a bug if it does not | 10:35 |
| sean-k-mooney | its a new feature | 10:35 |
| EugenMayer | "/etc/kolla/nova-compute/:/var/lib/kolla/config_files/:ro", | 10:35 |
| EugenMayer | this probably means that those configs are used with a entrypoint and then generate the actual nova config, i dont know | 10:36 |
| sean-k-mooney | EugenMayer: i assume you are tyring to use https://github.com/openstack/kolla-ansible/commit/d2d4b53d47df3b1a250c21404a8ec140873d4ce5 feature | 10:36 |
| EugenMayer | sean-k-mooney i'am not really doing anything myself, i rather upgraded to the newest kolla version for xena, an they introduced this https://docs.openstack.org/releasenotes/kolla-ansible/xena.html#upgrade-notes | 10:37 |
| EugenMayer | they are now, AFAIU talking with a sasl auth between nova and libvirt | 10:37 |
| EugenMayer | and this is the default in this regard | 10:37 |
| sean-k-mooney | i see | 10:38 |
| sean-k-mooney | the nova comunity was nto invovled in that work | 10:38 |
| EugenMayer | sean-k-mooney what you linked is perfectly right, but you also see, they default to enabling it | 10:38 |
| sean-k-mooney | so its nice that it works | 10:38 |
| EugenMayer | i see | 10:38 |
| sean-k-mooney | https://docs.openstack.org/kolla-ansible/latest/reference/compute/libvirt-guide.html#sasl-authentication | 10:39 |
| sean-k-mooney | so it looks like you need new passwoard in you passwords.yal | 10:40 |
| sean-k-mooney | i assume you geneerated those and mreged them with your exsitng ones | 10:40 |
| EugenMayer | did that already, the upgrade was not working without that | 10:41 |
| sean-k-mooney | ya i would expect the templates to fail to generate the config | 10:41 |
| EugenMayer | that is why i said on the compute, the auth.conf is created, has the right creds | 10:41 |
| sean-k-mooney | ack | 10:41 |
| sean-k-mooney | for now i would proably disabel the sasl auth and complete the upgrade | 10:41 |
| EugenMayer | and i assured that the backend, libvirt, has set the sasls password for the particular user | 10:41 |
| sean-k-mooney | then try and do a reconfigure later | 10:42 |
| EugenMayer | yes, seems that this might be the option i should go for | 10:42 |
| sean-k-mooney | i have not deployed kolla since wallaby by the way | 10:43 |
| sean-k-mooney | so im not up to date on how they currenlty do things | 10:43 |
| sean-k-mooney | lookign at the error | 10:44 |
| sean-k-mooney | i wonder is this related to userids and group ids | 10:44 |
| sean-k-mooney | libvirt is sayign the user does not exist | 10:44 |
| sean-k-mooney | user | 10:45 |
| sean-k-mooney | | not found: unable to canonify user and get auxprops | 10:45 |
| sean-k-mooney | EugenMayer: kolla defiens the nova user id and group id https://github.com/openstack/kolla/blob/master/kolla/common/users.py#L148-L151= | 10:46 |
| sean-k-mooney | but maybe that user is not create in the libvirt contaienr | 10:47 |
| EugenMayer | the docs are wrong there anyway | 10:47 |
| EugenMayer | The username is configured via ``libvirt_sasl_authname``, and defaults to | 10:47 |
| EugenMayer | ``kolla``. The password is configured via ``libvirt_sasl_password``, and is | 10:47 |
| EugenMayer | generated with other passwords using and stored in ``passwords.yml``. | 10:47 |
| EugenMayer | which is wrong, the default user is nova | 10:48 |
| EugenMayer | # Username for libvirt SASL. | 10:48 |
| EugenMayer | libvirt_sasl_authname: "nova" | 10:48 |
| sean-k-mooney | ack | 10:48 |
| EugenMayer | and also in my auth.conf it is nova | 10:48 |
| sean-k-mooney | https://github.com/openstack/kolla/blob/master/docker/nova/nova-libvirt/Dockerfile.j2#L10= | 10:48 |
| sean-k-mooney | and nova should exist in the libvirt container | 10:48 |
| EugenMayer | i did create it using saslpasswd2 -c -p -a libvirt nova | 10:49 |
| EugenMayer | myself, just to ensure it has been provisioned | 10:49 |
| sean-k-mooney | in the container | 10:49 |
| sean-k-mooney | ok | 10:49 |
| EugenMayer | you mean, there should be a linux user 'nova'? | 10:50 |
| sean-k-mooney | yes | 10:50 |
| sean-k-mooney | i think that is what the error is about | 10:50 |
| EugenMayer | (nova-libvirt)[root@compute1 /]# cat /etc/passwd | grep nova | 10:50 |
| EugenMayer | nova:x:42436:42436::/var/lib/nova:/usr/sbin/nologin | 10:50 |
| sean-k-mooney | yep | 10:50 |
| sean-k-mooney | that is what we expect | 10:50 |
| EugenMayer | yes | 10:50 |
| sean-k-mooney | what host os are you using | 10:51 |
| sean-k-mooney | i assum this is not related to md5 beign diabled because of fips or similar | 10:51 |
| EugenMayer | host os would not make any sense here | 10:52 |
| sean-k-mooney | ack | 10:53 |
| EugenMayer | sicne nova_compute and nova_libvirt run in dedicated docker containers, so the os is picked by kolla | 10:53 |
| sean-k-mooney | not nessisarly | 10:53 |
| sean-k-mooney | they share the kernel | 10:53 |
| EugenMayer | the container runs debian bullseye | 10:53 |
| sean-k-mooney | and if md5 was disabeled by the kernel security policy it would not work | 10:53 |
| EugenMayer | i see, well the host is what is expected by kolla, some version of ubuntu | 10:53 |
| sean-k-mooney | ya should not be an issue | 10:54 |
| EugenMayer | 11.4 | 10:54 |
| sean-k-mooney | i just asked becasue i know in fips enforcing mode md5 is not allowed by the kernel and its default to DIGEST_MD5 when libvirt_tls is not enabled | 10:54 |
| sean-k-mooney | that woudl likely give you a diffent error anyway | 10:55 |
| sean-k-mooney | https://github.com/openstack/kolla-ansible/blob/stable/xena/ansible/roles/nova-cell/handlers/main.yml#L118-L129= feels like a bit of a hack but form what i can see you appear to have set it correctly manually too | 10:56 |
| sean-k-mooney | ah i see | 10:57 |
| sean-k-mooney | https://github.com/openstack/kolla-ansible/commit/d2d4b53d47df3b1a250c21404a8ec140873d4ce5#diff-4b6ee2f357ff265811c14e74dd6144d494c4f2baf9e00a9871207114b1172a4bR58 | 10:57 |
| sean-k-mooney | that is how they are making this work | 10:58 |
| EugenMayer | yes | 10:58 |
| sean-k-mooney | EugenMayer: so they are modifying the default session config for the nova user | 10:58 |
| sean-k-mooney | that is distro specific normally | 10:59 |
| sean-k-mooney | as in rhel adn ubuntu have different default for how virsh functions | 10:59 |
| sean-k-mooney | but since its the same debian image | 10:59 |
| sean-k-mooney | i woudl expect it to be the same with kolla | 11:00 |
| EugenMayer | probably | 11:00 |
| sean-k-mooney | EugenMayer: have you tried using virsh in the nova_compute container | 11:00 |
| sean-k-mooney | and seeign if it can coonnect | 11:00 |
| EugenMayer | i did not - running with sasl false right now (running reconfigure) | 11:01 |
| EugenMayer | cannot test that rigtht now | 11:01 |
| sean-k-mooney | no worries | 11:01 |
| EugenMayer | important thing would be https://github.com/openstack/kolla-ansible/commit/d2d4b53d47df3b1a250c21404a8ec140873d4ce5#diff-daa292a9ef0f95cd3db9000779f7ae3caf56cc4628790fc37c361638d32e5861R12 | 11:01 |
| EugenMayer | if that was not set, it would not matter that the auth.conf was there and the linux user had the proper sasl password | 11:01 |
| sean-k-mooney | right | 11:02 |
| sean-k-mooney | presumable this is tested in the kolla ci | 11:02 |
| sean-k-mooney | if not perhaps a recnet libvirt release changed something | 11:03 |
| EugenMayer | without sasl it works, its all up and runnign again | 11:03 |
| sean-k-mooney | ack. | 11:04 |
| EugenMayer | my best guess right now is https://github.com/openstack/kolla-ansible/commit/d2d4b53d47df3b1a250c21404a8ec140873d4ce5#diff-daa292a9ef0f95cd3db9000779f7ae3caf56cc4628790fc37c361638d32e5861R12 as not set to sasl | 11:05 |
| EugenMayer | right now it is none, but well i did not peak that file beforehand | 11:05 |
| EugenMayer | just while i was applying the configuration with disabled sasl | 11:05 |
| sean-k-mooney | kolla can generate teh config without pushing them right | 11:05 |
| EugenMayer | i guess i will need to delay this, i did all this mess on prod | 11:05 |
| sean-k-mooney | oh ya | 11:06 |
| EugenMayer | no it generates them on the spot AFAIU | 11:06 |
| sean-k-mooney | ok i tough tyou coudl run config without reconfigure | 11:06 |
| EugenMayer | since it uses ansible, it will do all that remotely | 11:06 |
| sean-k-mooney | its been a while so i may be wrong | 11:06 |
| sean-k-mooney | in anycase i would play with this in a vm not prod | 11:06 |
| EugenMayer | sure, but it is not easy to reproduce that | 11:07 |
| sean-k-mooney | deploy Wallaby | 11:07 |
| EugenMayer | i bet this is an upgrade issue and if a spin up a new openstack cluster with kolla it will work | 11:07 |
| sean-k-mooney | then upgrade and it breaks no? | 11:07 |
| sean-k-mooney | yep i woudl expect if you do singel node wallay in a vm | 11:07 |
| EugenMayer | well that does not ensure we get into the same case. right now i upgraded in serias from xena x to xena >x, and this failed | 11:07 |
| sean-k-mooney | and upgrade it it will break | 11:07 |
| sean-k-mooney | oh ok | 11:08 |
| EugenMayer | s/in serias/in series | 11:08 |
| sean-k-mooney | it was a minor update with in xena | 11:08 |
| sean-k-mooney | got it | 11:08 |
| sean-k-mooney | very odd that this woudl be added mid series | 11:08 |
| EugenMayer | yes, so that is why i actually used prod. i did not jump a series | 11:08 |
| EugenMayer | they do that often, last mid series upgrade had a similar issue/breaking change | 11:09 |
| EugenMayer | https://docs.openstack.org/releasenotes/kolla-ansible/xena.html#relnotes-13-0-0-stable-xena-upgrade-notes | 11:09 |
| sean-k-mooney | add the feature maybe enabling it by default i woudl not expect | 11:09 |
| EugenMayer | but back then i think the reason was i was running on non stable kolla for xena, since they has not been a release for the xena stable release for quiet some time after xena itself was released | 11:09 |
| sean-k-mooney | basically in a minor update case i woudl expect to not need to update any config | 11:10 |
| sean-k-mooney | oh you deploy xena with master | 11:10 |
| sean-k-mooney | ya i have found issue doing that in the past | 11:10 |
| EugenMayer | then i upgraded to 13.0 and had to deal with the adjustments, which i see justified. now it was kolla 13.0 to 13.1 mid xena, with again breaking changes which kind of scare me | 11:10 |
| sean-k-mooney | ya i personally woudl not have defaulted this to enabled | 11:11 |
| EugenMayer | well i deploy xena with the stable/xena branch of kolla - back then there was no alternativw | 11:11 |
| sean-k-mooney | i may have backported it because deployment tools have different policies on that | 11:11 |
| sean-k-mooney | but not requried any operator intervention | 11:11 |
| sean-k-mooney | e.g. make it opt in | 11:11 |
| sean-k-mooney | they may have wanted it to be secure by default | 11:12 |
| EugenMayer | yeah that is how i would have done it, opt in for xena and default for yoga | 11:12 |
| sean-k-mooney | but i woudl only have done that in yoga | 11:12 |
| EugenMayer | still, release opt in, learn about the issues, make it default next one | 11:12 |
| EugenMayer | do not release such a change and make it the default in one go .. that would be my mantra | 11:12 |
| EugenMayer | as i see, we have the same ideas here | 11:13 |
| sean-k-mooney | yep i perscibe to what is sometiem refered to as the grenade theroy of upgrade | 11:14 |
| sean-k-mooney | https://opendev.org/openstack/grenade#Theory%20of%20Upgrade | 11:14 |
| EugenMayer | interesting | 11:20 |
| sean-k-mooney | if a project follow stable polciy ^ is the critia it needs to meet | 11:23 |
| sean-k-mooney | or at least a sub set of it | 11:23 |
| sean-k-mooney | when the project is evaulting uprade impact | 11:23 |
| sean-k-mooney | stable policy is a liggel more inovvled but for nova for example we need to ensure feature we develop on master comply with the grenade theory of upgrade | 11:24 |
| EugenMayer | well i guess it sometimes frustrates the developers to be limited by those rules | 11:25 |
| EugenMayer | but in the end your audience will be a happier ones. Scaring our audience away from applying upgrades due to the expectation of 'every one of those will be problematic', will make it worse | 11:26 |
| sean-k-mooney | i have never really found it limiting | 11:27 |
| sean-k-mooney | we just wait a release to turns things on if it need operator intervention | 11:27 |
| sean-k-mooney | it also lets us find bugs | 11:27 |
| sean-k-mooney | we enable it in the nova-next jobs for a cycle and see if it has issues | 11:28 |
| EugenMayer | feature flags often help if one is impatience here | 11:29 |
| *** haleyb_ is now known as haleyb | 12:52 | |
| *** dasm|off is now known as dasm|ruck | 13:05 | |
| sean-k-mooney | gibi: bauzas is downstream irc down for ye | 13:08 |
| bauzas | sean-k-mooney: nope | 13:09 |
| gibi | nope | 13:09 |
| bauzas | and I don't see a netsplit | 13:09 |
| sean-k-mooney | looks like the vpn dropped again | 13:09 |
| sean-k-mooney | ok ill fix that | 13:09 |
| *** mfo is now known as Guest5617 | 13:41 | |
| *** mfo_ is now known as mfo | 13:41 | |
| opendevreview | Rico Lin proposed openstack/nova master: Add locked_memory extra spec and image property https://review.opendev.org/c/openstack/nova/+/778347 | 13:54 |
| opendevreview | Rico Lin proposed openstack/nova master: libvirt: Add vIOMMU device to guest https://review.opendev.org/c/openstack/nova/+/830646 | 13:54 |
| opendevreview | Rico Lin proposed openstack/nova master: Add traits for viommu model https://review.opendev.org/c/openstack/nova/+/844507 | 13:54 |
| bauzas | folks, I need to disappear for a dentist appointment | 14:05 |
| * bauzas will be back in 1h | 14:05 | |
| EugenMayer | sean-k-mooney thank you for helping once again, sorry forgot the mention the obvious! | 14:15 |
| sean-k-mooney | EugenMayer: no worries sorry i did not see how to make it work end to end but happy your prod it working again | 14:23 |
| opendevreview | Amit Uniyal proposed openstack/nova master: add regression test case for bug 1978983 https://review.opendev.org/c/openstack/nova/+/849104 | 15:28 |
| opendevreview | Amit Uniyal proposed openstack/nova master: For evacuation, ignore if task_state is not None https://review.opendev.org/c/openstack/nova/+/848886 | 15:28 |
| colby_ | sean-k-mooney: bauzas: Still trying to get our vGPU stuff working. Here is the bug I filed: https://bugs.launchpad.net/nova/+bug/1981631. Im happy to be a guinea pig for testing. I can also poke around and help gather any info you need to help identify the issue. I did some logging of python code variables to see what rp(pri device) its trying to use when they are all created already and its def trying to use a new | 15:48 |
| colby_ | one instead of existing. Let me know if you need anything from me as manually deleting the mdevs is not ideal for production at this point. | 15:48 |
| bauzas | colby_: fwiw, I opened a bug against libvirt for it | 15:48 |
| bauzas | colby_: https://bugzilla.redhat.com/show_bug.cgi?id=2109450 | 15:48 |
| colby_ | ok thanks! Its good to know its on that end I guess. I guess that is the drawback of using centos8 stream which has the newer version of libvirt | 15:51 |
| colby_ | So will using that new API be backported to older releases once you add that in the next release? | 15:52 |
| bauzas | colby_: or libvirt will fix it | 15:53 |
| colby_ | or are we stuck hoping redhat will add the old functionality back in? | 15:55 |
| colby_ | ah ok | 15:55 |
| bauzas | colby_: tbc, I'm working on a POC to use the new API | 16:01 |
| bauzas | but ideally, the regression should be fixed | 16:01 |
| colby_ | cool. thanks for pointing me to that bug. Ill keep an eye on it. | 16:02 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Reproducer for bug 1982497 https://review.opendev.org/c/openstack/nova/+/850672 | 16:02 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Reproducer for bug 1951656 https://review.opendev.org/c/openstack/nova/+/850673 | 16:23 |
| opendevreview | ribaudr proposed openstack/nova master: Allow unshelve to a specific host (Compute API part) https://review.opendev.org/c/openstack/nova/+/831507 | 17:51 |
| opendevreview | ribaudr proposed openstack/nova master: Allow unshelve to a specific host (REST API part) https://review.opendev.org/c/openstack/nova/+/845897 | 17:51 |
| opendevreview | ribaudr proposed openstack/nova master: Allow unshelve to a specific host (REST API part) https://review.opendev.org/c/openstack/nova/+/845897 | 17:57 |
| opendevreview | liuhuajie proposed openstack/nova master: The default value of the dictionary get method is None, so remove the default value of None in the get method https://review.opendev.org/c/openstack/nova/+/850450 | 18:24 |
| *** dasm|ruck is now known as dasm|off | 21:04 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!