| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-17 | |||
| 16:46:58 | sean-k-mooney | gmann: wait we are not? | |
| 16:47:08 | sean-k-mooney | gmann: temest is ment to be branchless upstream | |
| 16:47:13 | gmann | but we have stopped ussuri support in tempest master | |
| 16:47:31 | sean-k-mooney | hum | |
| 16:47:37 | sean-k-mooney | because of what reason? | |
| 16:47:41 | gmann | sean-k-mooney: yes and master tempest is for SUpported branch and we cannot support EM branches | |
| 16:47:42 | sean-k-mooney | python version ? | |
| 16:48:04 | sean-k-mooney | shoudl that not be a project choice | |
| 16:48:16 | gmann | EM branches - #link https://docs.openstack.org/tempest/latest/stable_branch_support_policy.html | |
| 16:48:17 | sean-k-mooney | tempest should not have to support it | |
| 16:48:42 | sean-k-mooney | but project that support em branches shoudl still be able to choose which tempest to run | |
| 16:48:46 | gmann | sean-k-mooney: we have to pin tempest for EM branch so that using master there can break them anytime | |
| 16:49:06 | gmann | sean-k-mooney: yeah, you can but no guarantee if master tempest will work | |
| 16:49:19 | gmann | as long as it is passing it is ok to use | |
| 16:49:58 | sean-k-mooney | ack | |
| 16:50:12 | sean-k-mooney | so i think i would prefer to keep tempest uncapped until ti breaks | |
| 16:50:14 | elodilles | (well, i guess changes on tempest master can affect not only EM branches, but they are affected most likely) | |
| 16:50:30 | sean-k-mooney | elodilles: well nova uses microversion | |
| 16:50:40 | sean-k-mooney | so it should work form our point of view | |
| 16:50:53 | gmann | elodilles: for supported branches we make sure tempest does not break them but for EM it is not the case | |
| 16:50:57 | sean-k-mooney | chagnes to tempest should not break our stable branches expcti if there ar package dep issues | |
| 16:51:14 | gmann | plan is : by default devstack will cap the tempest in ussuri and project can override it in jobs | |
| 16:51:15 | bauzas | I need to timestop the conversation | |
| 16:51:15 | sean-k-mooney | which i guess is why this was done | |
| 16:51:41 | gmann | yeah, we can discuss it in qa or nova channel after meeting | |
| 16:51:49 | sean-k-mooney | +1 | |
| 16:51:51 | elodilles | +1 | |
| 16:51:52 | bauzas | gmann: sean-k-mooney: gibi: you're all free to continue the conversation after the meeting | |
| 16:51:57 | bauzas | cool | |
| 16:51:57 | gmann | sure | |
| 16:52:01 | bauzas | moving on quickly | |
| 16:52:08 | bauzas | #topic Open discussion | |
| 16:52:21 | bauzas | Uggla: do you want to discuss https://bugs.launchpad.net/nova/+bug/1959186 | |
| 16:52:22 | bauzas | ? | |
| 16:52:44 | bauzas | Uggla: you left this bug with comments on your triage etherpad | |
| 16:52:53 | Uggla | yep | |
| 16:53:18 | Uggla | It appears valid to me, but I would like a crosscheck. | |
| 16:53:26 | sean-k-mooney | i dont think it is | |
| 16:54:02 | sean-k-mooney | there is a long runnign knwon issue that you cant delete in use image form glance if it uses ceph | |
| 16:54:15 | sean-k-mooney | that only happens if you use raw images | |
| 16:54:27 | sean-k-mooney | at that enabel our copy on write shallow clone code path | |
| 16:54:34 | bauzas | sounds at least unrelated to nova | |
| 16:54:42 | sean-k-mooney | which i suspect is what is happening here with the snapshot | |
| 16:54:45 | bauzas | maybe valid but not on our side | |
| 16:54:52 | bauzas | right? | |
| 16:55:21 | dansmith_ | it's really desired behavior even | |
| 16:55:27 | sean-k-mooney | there have been some feature request in this area | |
| 16:55:39 | sean-k-mooney | some peopel woudl like too break the shallow copy | |
| 16:55:44 | dansmith_ | I think it'd be a feature on the glance side, IIRC | |
| 16:56:08 | sean-k-mooney | ya so they have not providded enough info in the bug | |
| 16:56:12 | sean-k-mooney | we do not know the image type | |
| 16:56:21 | dansmith | nova doesn't even know about the linkage after it's created right? so if the link is broken, nova is fine with it | |
| 16:56:21 | sean-k-mooney | to confirm wone way or another | |
| 16:56:39 | sean-k-mooney | am im not sure | |
| 16:57:00 | bauzas | dansmith: hence my point, unrelated to the project | |
| 16:57:04 | bauzas | => Opinion | |
| 16:57:14 | levy14 | have a feature proposal, but not in the agenda yet. may I ask here and gauge interest/feasibility? | |
| 16:57:15 | dansmith | bauzas: yeah | |
| 16:57:24 | sean-k-mooney | there is some metadata on teh image but i dont know if we read that when we create the new vm | |
| 16:57:29 | sean-k-mooney | or tack it on our side | |
| 16:57:43 | bauzas | sean-k-mooney: we can add glance as a service project in the bug report | |
| 16:57:50 | bauzas | and mark it invalid on our side | |
| 16:58:02 | bauzas | we'll see it coming back if that's really a nova bug | |
| 16:58:21 | bauzas | Uggla: works for you ? | |
| 16:58:26 | Uggla | yes | |
| 16:58:57 | bauzas | OK, sold | |
| 16:59:12 | bauzas | #agreed https://bugs.launchpad.net/nova/+bug/1959186 to be punted to Glance | |
| 16:59:56 | sean-k-mooney | ill do that and ask for more info in the bug | |
| 17:00:03 | bauzas | I wanted to discuss https://review.opendev.org/c/openstack/os-vif/+/840020 but we're at time | |
| 17:00:14 | bauzas | thanks all | |
| 17:00:16 | bauzas | #endmeeting | |
| 17:00:16 | opendevmeet | Meeting ended Tue May 17 17:00:16 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:00:16 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-17-16.02.html | |
| 17:00:16 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-17-16.02.txt | |
| 17:00:16 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-17-16.02.log.html | |
| 17:00:28 | bauzas | gmann: https://review.opendev.org/c/openstack/os-vif/+/840020 seems problematic to merge | |
| 17:00:39 | sean-k-mooney | bauzas: the failures are unrelated i think | |
| 17:00:45 | sean-k-mooney | there were db issues | |
| 17:00:54 | gmann | yeah let's see I did recheck on this | |
| 17:01:08 | sean-k-mooney | the patch is just remvoing lower constraitns there are no code changes | |
| 17:01:24 | bauzas | sean-k-mooney: ok | |
| 17:01:44 | bauzas | all good then | |
| 17:02:16 | sean-k-mooney | bauzas: i looked durign the metting thanks for bring it ot my attention i tought that merged already | |
| 17:02:26 | bauzas | np | |
| 17:02:32 | bauzas | happy to help | |
| 17:02:52 | gibi | levy14: I suggest to type your idea in here, or add it to the agenda for next week | |
| 17:03:05 | levy14 | My org found a lot of code that runs in VMs contains credentials in code or config files. I would like to be able to make calls (HTTP requests) to a secret store (Barbican) without providing credentials, and Nova to add them automatically, based on the VM's identity. Much like AWS instance profiles and Azure managed identities work. How should I proceed with this? | |
| 17:03:14 | levy14 | will try to add it to teh agenda for the next time | |
| 17:03:29 | bauzas | levy14: feel free to add it by yourself in https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | |
| 17:03:41 | bauzas | you only need LP creds | |
| 17:04:15 | levy14 | so no need to create a blueprint for it? | |
| 17:04:28 | bauzas | levy14: that's what we'll figure out at the meeting :) | |
| 17:04:59 | levy14 | cool, will add it. if any feedback here, will try to capture that too. | |
| 17:05:56 | Uggla | bauzas, leaving IRC, see you in 1h call me on my cell if needed. | |
| 17:06:09 | sean-k-mooney | levy14: that kind of sound like something that was propsoed before | |
| 17:06:12 | bauzas | Uggla: bien sûr et à toute :) | |
| 17:06:32 | sean-k-mooney | related to jwt tokenes or something like that | |
| 17:07:11 | levy14 | sean-k-moonehy: any idea why it is not yet available? any serious blocker? as we see it as a huge security improvement. | |
| 17:07:13 | sean-k-mooney | levy14: so you would lke to have the ablity to request that a set of barbican securest are automaticly injected wehn a vm is created | |
| 17:07:32 | sean-k-mooney | levy14: well you woudl have to opt into this behavior on a pervm basis | |