| opendevreview | melanie witt proposed openstack/nova master: Unit test exceptions raised duing live migration monitoring https://review.opendev.org/c/openstack/nova/+/859358 | 00:35 |
|---|---|---|
| *** hgy_ is now known as han-guangyu | 02:46 | |
| *** han-guangyu is now known as Guest1519 | 03:18 | |
| *** han-guangyu is now known as hgy111 | 05:38 | |
| *** hgy111 is now known as han-guangyu | 05:38 | |
| Uggla | gibi, bauzas, hello. I have a question about share_mapping deletion behavior. Assuming we cannot umount the share due to error. So we could be stuck in the state share cannot be deleted because it cannot be unmounted. What do you prefer a "force" option in the API or deleting it despite the error and warn the user that the umount was not properly done ? | 09:09 |
| bauzas | damn | 09:10 |
| bauzas | I'd prefer to return an error and still having the share status to be ACTIVE | 09:11 |
| gibi | Uggla: yeah what bauzas said. The DB record is cheap to keep so I would not optimize on removing that. | 09:11 |
| bauzas | Uggla: tbc, if we can't umount the share, then the user would need to ask again | 09:12 |
| Uggla | ok in that case it means the op need to fix the umount issue to remove the share. Do we agree on that ? | 09:14 |
| bauzas | honestly, I think so | 09:15 |
| bauzas | the user can't know why nova doesn't work | 09:15 |
| bauzas | so he could ask the operator to look at the problem | 09:15 |
| bauzas | forcing to just delete the DB value while we would still have the mount could be a problem for a host after some time | 09:16 |
| bauzas | and if the operator doesn't know that all the shares are still mounted, then he wouldn't see it until it could be a larger problem | 09:17 |
| Uggla | ok fyi this is the msg given to user: {"badRequest": {"code": 400, "message": "Share id e8debdc0-447a-4376-a10a-4cd9122d7986 mount error from server 36a6c053-78c6-4409-9a44-b1e81244e61e.\\nReason: Unexpected error while running command.\\nCommand: mount\\nExit code: 1\\nStdout: \'This is stdout\'\\nStderr: \'This is stderror\'."}} | 09:17 |
| Uggla | oops copy/paste the wrong one | 09:18 |
| Uggla | s/mount/umount/ | 09:18 |
| gibi | if the command line or the error does not leak infra information to the user then I'm OK with this response | 09:19 |
| tobias-urdin | should probably censor the command error and return a more generic error msg, had the same for ceph where it leaked the username in the error message returned to the user | 09:19 |
| tobias-urdin | gibi: was faster :p | 09:19 |
| bauzas | yeah agreed with tobias-urdin | 09:19 |
| gibi | just tiny bit :)\ | 09:19 |
| bauzas | I'd prefer to have a better error | 09:19 |
| bauzas | and, shouldn't be 400 | 09:19 |
| bauzas | that's not a *bad request* right? | 09:20 |
| gibi | bauzas: good point this cannot be fixed by fixing the request | 09:20 |
| gibi | so it is more like 500 | 09:20 |
| bauzas | Uggla: remind me something | 09:21 |
| bauzas | Uggla: do we have share statuses ? | 09:22 |
| Uggla | ok so do we agree that log should contains the reason (mount, stderr, stdout ...) | 09:22 |
| bauzas | for the log, yes | 09:22 |
| Uggla | yep we have a share_mapping status status | 09:22 |
| bauzas | not for the error message to the user :) | 09:22 |
| bauzas | like, say a user is asking to delete a share for an instance | 09:23 |
| bauzas | he/she calls nova API for "deleting the share mapping" | 09:23 |
| bauzas | he eventually gets "sorry, nay" | 09:23 |
| bauzas | then the share mapping still exists | 09:24 |
| bauzas | he then asks again "please delete my share mapping" | 09:24 |
| bauzas | nova continues to tell "sorry, nay again" | 09:24 |
| bauzas | then, the user would ask the operator to tell him/her "meh, can't delete my share mapping" | 09:24 |
| gibi | ^^ +1 | 09:25 |
| bauzas | then the operator looks at the share mapping by the logs and see | 09:25 |
| bauzas | 'oh man, this mapping UUID got an exception" | 09:25 |
| bauzas | and then he/she says "oh, f*** that's why, this crazy umount didn't work" | 09:25 |
| bauzas | that's how I see it | 09:26 |
| Uggla | bauzas, sounds good to me and easier to manage. :) | 09:26 |
| bauzas | the better would be to see the share mapping requests in the server actions list | 09:27 |
| bauzas | Uggla: https://docs.openstack.org/api-ref/compute/#list-actions-for-server | 09:27 |
| bauzas | but I don't think this is possible | 09:27 |
| bauzas | ideally, if the operator could get the request ID of the "delete share mapping" call, that would be loving | 09:28 |
| bauzas | and again, that's a question about whether we want to have a share mapping deletion to be synchronous or async | 09:28 |
| * bauzas can't remember exactly what we said | 09:28 | |
| Uggla | sync | 09:29 |
| bauzas | then 500 | 09:29 |
| Uggla | ok | 09:29 |
| bauzas | gibi: remind me, do we have a way to see the image properties an instance got ? | 09:33 |
| bauzas | https://docs.openstack.org/api-ref/compute/?expanded=show-server-details-detail#show-server-details can't see them in the API ref | 09:33 |
| bauzas | it will just give you the image UUID | 09:33 |
| gibi | we copy them over to sysmeta but that is not visible on the API I guess | 09:34 |
| bauzas | auniyal__: ^ | 09:34 |
| auniyal__ | I have this a server | 09:34 |
| auniyal__ | (Pdb) server | 09:34 |
| auniyal__ | {'id': '2d867afe-0e2d-480b-82e9-e19fcd7b16d5', 'links': [{'rel': 'self', 'href': 'http://c6ac6857-c7be-439e-ba5f-43639cd09e84/v2.1/servers/2d867afe-0e2d-480b-82e9-e19fcd7b16d5'}, {'rel': 'bookmark', 'href': 'http://c6ac6857-c7be-439e-ba5f-43639cd09e84/servers/2d867afe-0e2d-480b-82e9-e19fcd7b16d5'}], 'OS-DCF:diskConfig': 'MANUAL', 'security_groups': [{'name': 'default'}], 'adminPass': 'SoXFm9gf3ksh'} | 09:34 |
| auniyal__ | (Pdb) | 09:34 |
| gibi | so the end user needs to use the image UUID and look up theimage in gerrit | 09:34 |
| gibi | in glance | 09:34 |
| gibi | not gerrit /o\ | 09:34 |
| bauzas | gibi: context is, auniyal__ is creating a BFV instance with some properties | 09:34 |
| bauzas | gibi: and after this, snapshoting the instance | 09:35 |
| bauzas | but when snapshoting, the quiesce property doesn't exist | 09:35 |
| bauzas | my two guesses are : | 09:35 |
| bauzas | 1/ the fixture can create a fake instance that needs to adjust its properties | 09:35 |
| bauzas | 2/ the snapshot command doesn't really pull the image properties of the original image | 09:36 |
| auniyal__ | in server object, there are 2 links, one "rel": self, and other "rel": bookmark ? | 09:37 |
| gibi | I would verify 2/ in devstack first. maybe we have a bug on snapshot? | 09:37 |
| bauzas | gibi: indeed we have | 09:37 |
| auniyal__ | gibi, in here - https://paste.opendev.org/show/bV01d0abp2GEVT5Bk4up/ | 09:39 |
| bauzas | auniyal__: remind me the snapshot bug report ? | 09:39 |
| bauzas | gibi: and agreed on the need for a devstack testing | 09:39 |
| auniyal__ | bug: https://bugs.launchpad.net/nova/+bug/1980720 | 09:39 |
| auniyal__ | in pastebin, at line 83 - properties | 09:40 |
| gibi | bauzas: I mean we have another more generic bug on snapshot where we simply not copy over image properties to snapshots | 09:42 |
| gibi | maybe? | 09:42 |
| auniyal__ | I belive, require_quiensce is getting set - because later my control, does come here - https://opendev.org/openstack/nova/src/commit/aad31e6ba489f720f5bdc765c132fd0f059a0329/nova/compute/api.py#L3471 | 09:42 |
| auniyal__ | but then failed - saying - nova.exception.QemuGuestAgentNotEnabled: QEMU guest agent is not enabled | 09:43 |
| bauzas | gibi: yeah that's my guess #2 | 09:44 |
| bauzas | but that needs to be verified | 09:44 |
| bauzas | eventually found the bug report... | 09:44 |
| bauzas | gibi: https://bugs.launchpad.net/nova/+bug/1980720 | 09:44 |
| gibi | auniyal__: can you track down from where the QemuGuestAgentNotEnabled is raised? | 09:45 |
| bauzas | this is specific to quiesce, but I guess no properties are given | 09:45 |
| bauzas | gibi: yeah we did | 09:45 |
| bauzas | and this is when you quiesce on the snapshot | 09:45 |
| gibi | bauzas: but that only complain about the error message not on the error it self. the report says there is no qemu agent running, so the error is expected | 09:46 |
| bauzas | https://github.com/openstack/nova/blob/512fbdfa9933f2e9b48bcded537ffb394979b24b/nova/virt/libvirt/driver.py#L3244 | 09:46 |
| bauzas | yeah | 09:46 |
| bauzas | anyway, I need to stop by now | 09:46 |
| bauzas | let's discuss this this afternoon | 09:46 |
| gibi | so that does not prove we have a bug in snapshot that failes to copy some image properties | 09:47 |
| gibi | bauzas: ack | 09:47 |
| * bauzas goes sweating | 09:47 | |
| gibi | bauzas: have a nice one | 09:48 |
| opendevreview | Amit Uniyal proposed openstack/nova stable/yoga: Adds check if blk_dev_info has correct flavor.swap https://review.opendev.org/c/openstack/nova/+/859246 | 09:52 |
| opendevreview | Amit Uniyal proposed openstack/nova stable/wallaby: Adds check if blk_dev_info has correct flavor.swap https://review.opendev.org/c/openstack/nova/+/859247 | 09:53 |
| auniyal__ | gibi, QemuGuestAgentNotEnabled is coming from https://github.com/openstack/nova/blob/512fbdfa9933f2e9b48bcded537ffb394979b24b/nova/virt/libvirt/driver.py#L3223 | 10:28 |
| gibi | auniyal__: could you check image_meta.properties there? is it only hw_qemu_guest_agent missing or os_require_quiesce too? | 10:30 |
| auniyal__ | yes, thats also missing | 10:32 |
| auniyal__ | this is a object, - https://paste.opendev.org/show/bD0rlumubeiQ6Yeowaiw/ | 10:33 |
| auniyal__ | in this - https://paste.opendev.org/show/bV01d0abp2GEVT5Bk4up/ | 10:33 |
| auniyal__ | property is preset in image at line 57 | 10:33 |
| auniyal__ | s/preset/present/ | 10:34 |
| gibi | auniyal__: this point to the direction that we have an issue saving the image properties when we are doing the snapshot | 10:38 |
| auniyal__ | gibi: in here - https://paste.opendev.org/show/bV01d0abp2GEVT5Bk4up/ | 10:43 |
| auniyal__ | before line 88, we have server object, later from this object only we retrieve these image property | 10:44 |
| auniyal__ | *must be | 10:44 |
| auniyal__ | so is there a way, we can check here itself, if propeties gets attached or not, | 10:45 |
| auniyal__ | before calling snapshot | 10:45 |
| auniyal__ | here, https://github.com/openstack/nova/blob/512fbdfa9933f2e9b48bcded537ffb394979b24b/nova/objects/image_meta.py#L114 | 10:47 |
| gibi | auniyal__, bauzas: as far as I see we create some of the image metadata during snapshot here https://github.com/openstack/nova/blob/aad31e6ba489f720f5bdc765c132fd0f059a0329/nova/virt/libvirt/driver.py#L2994 but there is no sign that we intended to copy image properties over to the snapshot. We did copy os_type interestingly but not the rest. The os_type was added there as a bug fix | 10:49 |
| gibi | https://review.opendev.org/c/openstack/nova/+/42877 So now I'm wondering if we want to copy everything there or not | 10:49 |
| gibi | auniyal__: you can try to copy the two image prop your fix need there https://github.com/openstack/nova/blob/aad31e6ba489f720f5bdc765c132fd0f059a0329/nova/virt/libvirt/driver.py#L2994 to see if that helps | 10:51 |
| auniyal__ | gibi, actually this get called https://github.com/openstack/nova/blob/aad31e6ba489f720f5bdc765c132fd0f059a0329/nova/api/openstack/compute/servers.py#L1342 | 11:29 |
| auniyal__ | at this place also - properties are not set | 11:31 |
| auniyal__ | instance.image_meta.properties.get('hw_qemu_guest_agent') | 11:31 |
| bauzas | gibi: good point, that was my guess #2 | 13:03 |
| gibi | ahh this is volume backed snapshot. But then the instance is volume booted, so where qemu_guest_agent is coming from during the original boot from volume? | 13:33 |
| opendevreview | Bence Romsics proposed openstack/nova stable/ussuri: Fix unplugging VIF when migrate/resize VM https://review.opendev.org/c/openstack/nova/+/859433 | 13:34 |
| gibi | I'm confused that we talk about image properties but the instance is booted from volume so there might be no image at all involved | 13:34 |
| opendevreview | Bence Romsics proposed openstack/nova stable/train: Fix unplugging VIF when migrate/resize VM https://review.opendev.org/c/openstack/nova/+/859434 | 13:35 |
| rubasov | hi Nova folks: may I ask for reviews on these two backport series? both merged on master long ago, just taking the backports further: https://review.opendev.org/q/I2c195df5fcf844c0587933b5b5995bdca1a3ebed https://review.opendev.org/q/I3cb39a9ec2c260f422b3c48122b9db512cdd799b | 13:38 |
| *** dasm|off is now known as dasm | 13:46 | |
| Uggla | gibi, bauzas, sorry coming back to this morning discussion. I'm afraid we can have a "deadlock" if we fail to mount a share, we may fail to umount it as well, and we could be stuck with a record. So maybe admin need something to remove this record in the DB ? | 14:27 |
| gibi | Uggla: do you mean the unmount fails *because* we failed to mount the share in the first place? | 14:29 |
| Uggla | I think we could have such kind of situation. | 14:29 |
| Uggla | yes | 14:30 |
| Uggla | and today if a share_mapping is already in the DB, there is an error --> no attempt to mount it again. | 14:31 |
| Uggla | I could change that, to allow to mount it again if it is in error. | 14:31 |
| Uggla | the idea is to discuss how to go out of this if it happens without deleted the db record in the db itself. | 14:35 |
| Uggla | s/deleted/deleting | 14:35 |
| Uggla | I would like also to discuss the behavior starting a vm if some share_mapping are in error. Should I prevent the vm from starting up or start it and do not mount the error shares and warn about it ? | 14:39 |
| gibi | these are good questions | 14:39 |
| Uggla | gibi, fyi also I have changed the behavior from what you saw in the previous code. | 14:40 |
| gibi | so today a ShareMapping in error does not mean that the instance is in ERROR to? | 14:40 |
| gibi | too | 14:40 |
| Uggla | today 1- VM should be stopped, 2- Attach a share --> error --> share_mapping in status error in DB. | 14:41 |
| Uggla | So here if the user starts the VM, I'm in favor of starting it and do not mount the faulty shares. | 14:43 |
| gibi | ack | 14:43 |
| Uggla | User can still see the reason why the shares are not mounted because the share_mapping has a error status. | 14:44 |
| Uggla | *have | 14:44 |
| Uggla | *an | 14:44 |
| gibi | so at 2- nova tries to mount the share to the host the VM is on? | 14:45 |
| gibi | and that mount can fail | 14:46 |
| gibi | and 2- is sync so it does two thing i) puts the ShareMapping in ERROR ii) sends back http 500 to the user | 14:46 |
| Uggla | yep except vm is off. | 14:48 |
| gibi | and I guess if the VM is not on any host (never scheduled or it is shelved_offloaded) then we don't allow to attach a share | 14:49 |
| Uggla | yep with this version the vm should exist and be powered off (shelve is not allowed.) | 14:49 |
| gibi | cool | 14:49 |
| gibi | so the only way to re-try the mount of the failes ShareMapping is to detach and then attach the share again. But you are worried what if detach fails at unmount. I think that is fine. If the system is in that bad shape then the admin needs to intervene | 14:51 |
| gibi | i'm not sure what is the exact low lever scenario when the mount fails and leaves the host in a state where unmount is not possible, but I think we don't have to automate a fix for that right now | 14:52 |
| gibi | if it turns out there a common case where mount then unmount fails, then probably there will be a common solution for that, and then we can add that common solution to our unmount codepath to try | 14:53 |
| Uggla | exactly, but I'm afraid that the only solution for admin will be to remove the share in the DB itself. Not really convenient. | 14:54 |
| gibi | no, the admin can fix the host in a way that the next detach share call that tries the unmount will succeed | 14:54 |
| gibi | s/can/should be able to/ | 14:54 |
| gibi | so we need to allow detach share to be called on an ShareMapping in error | 14:55 |
| gibi | to re-try the unmount | 14:55 |
| Uggla | gibi, yes we can detach a share in error. | 14:55 |
| gibi | the that is our release valve, they can hit detach repeatedly until it succeeds :) | 14:56 |
| gibi | I mean admin can tweak the host and re-try the unmount via detach :) | 14:56 |
| Uggla | yep, probable resolution will be to mount the share manually to have a "correct" state --> then the detach should umount properly. | 14:57 |
| Uggla | ok I'll go in this way, we could still change later. thx gibi . | 14:59 |
| gibi | Uggla: also we can implement unmount in a way that if it sees no mounted share then it returns OK so the admin can just clean up a bad mount then let unmount see that no mount left to remove | 15:00 |
| Uggla | gibi, you are right ! I need to better check what happen in that case with the current code as I reused it. Maybe it is already handled properly like this. | 15:04 |
| gibi | ack | 15:05 |
| bauzas | gibi: Uggla: sorry was at the school with kid | 15:20 |
| * bauzas looking at the discussion | 15:21 | |
| Uggla | bauzas, no worries. | 15:27 |
| bauzas | Uggla: so yeah, if we have a state for the share, would be nice | 15:28 |
| Uggla | bauzas, yep we have the status | 15:29 |
| Uggla | so error are "tracked" in the db. | 15:30 |
| Uggla | *errors | 15:30 |
| bauzas | cool | 15:33 |
| bauzas | reminder : nova meeting in 10 mins | 15:50 |
| bauzas | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue Sep 27 16:00:18 2022 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'nova' | 16:00 |
| bauzas | hello, hola, hi, bonjour | 16:00 |
| justas_napa | Hi | 16:00 |
| justas_napa | I'd like to propose a topic | 16:01 |
| elodilles | o/ | 16:01 |
| justas_napa | I'd like to discuss the actions needed to add support for Napatech SmartNIC in Nova | 16:01 |
| bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:01 |
| bauzas | justas_napa: add your topic at the end of ^ | 16:01 |
| bauzas | and we'll discuss it during the open discussion topic | 16:02 |
| gibi | o/ | 16:03 |
| bauzas | ok, let's start and people will join | 16:03 |
| bauzas | #topic Bugs (stuck/critical) | 16:03 |
| bauzas | #info No Critical bug | 16:03 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 5 new untriaged bugs (+0 since the last meeting) | 16:03 |
| bauzas | I looked at them and I'd like to discuss about two bug reports | 16:03 |
| bauzas | but let's do this after the other pointds | 16:04 |
| bauzas | #link https://storyboard.openstack.org/#!/project/openstack/placement 26 open stories (+0 since the last meeting) in Storyboard for Placement | 16:04 |
| bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:04 |
| bauzas | so, about the bugs, | 16:04 |
| bauzas | #link https://bugs.launchpad.net/nova/+bug/1955035 | 16:04 |
| bauzas | looks to me an incomplete bug report as we need to verify whether it's also a problem for devstack | 16:05 |
| bauzas | thoughts ? | 16:05 |
| gibi | I haven't looked at it | 16:07 |
| bauzas | I have another bug report | 16:07 |
| bauzas | #link https://bugs.launchpad.net/nova/+bug/1981562 | 16:07 |
| bauzas | I think we could also ask the reporter to verify the comment provided by melwitt | 16:08 |
| gibi | sure the later can be put in Incomplete with a comment about that ^^ | 16:08 |
| bauzas | OK, I'll do it | 16:09 |
| bauzas | anyway, that's it for me | 16:09 |
| bauzas | elodilles: can then you got the bug baton for this week ? | 16:10 |
| Uggla | o/ | 16:10 |
| elodilles | bauzas: well, i meant last week that the *following* weeks will be a bit busy to me o:) | 16:10 |
| elodilles | i mean, hopefully it will be a calm period, but still, we have the release next week ;) | 16:11 |
| elodilles | so i'd rather skip one more week | 16:11 |
| elodilles | sorry for not writing it clearly last week :S | 16:12 |
| bauzas | elodilles: okay, then I can continue to look about the bug reports next week | 16:12 |
| bauzas | #info bug baton is continued to be used by bauzas for this week | 16:13 |
| elodilles | thanks & sorry :S | 16:13 |
| bauzas | any other bugs, folks ? | 16:13 |
| bauzas | elodilles: np at all | 16:13 |
| bauzas | moving on | 16:15 |
| bauzas | #topic Gate status | 16:15 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:15 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly Placement periodic job status | 16:15 |
| bauzas | #link https://zuul.openstack.org/builds?job_name=tempest-integrated-compute-centos-9-stream&project=openstack%2Fnova&pipeline=periodic-weekly Centos 9 Stream periodic job status | 16:15 |
| bauzas | #link https://zuul.opendev.org/t/openstack/builds?job_name=nova-emulation&pipeline=periodic-weekly&skip=0 Emulation periodic job runs | 16:15 |
| bauzas | all the runs are good ^ | 16:16 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:16 |
| bauzas | as a reminder, | 16:16 |
| bauzas | #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures | 16:16 |
| bauzas | moving on | 16:16 |
| bauzas | #topic Release Planning | 16:18 |
| bauzas | (sorry, got a call) | 16:18 |
| bauzas | #link https://releases.openstack.org/zed/schedule.html | 16:18 |
| bauzas | #info RC2 delivered on last Friday | 16:19 |
| bauzas | #info Zed GA planned next week | 16:19 |
| bauzas | #link https://etherpad.opendev.org/p/nova-zed-rc-potential Zed RC tracking etherpad | 16:19 |
| bauzas | honestly, I think for us that Zed is done | 16:19 |
| gibi | \o/ | 16:19 |
| bauzas | soooo | 16:19 |
| bauzas | (no regressions I've seen btw.) | 16:19 |
| bauzas | time to discuss about Antelope | 16:20 |
| bauzas | #topic PTG planning | 16:20 |
| bauzas | #link https://etherpad.opendev.org/p/nova-antelope-ptg Antelope PTG etherpad | 16:20 |
| bauzas | #link https://ptg.opendev.org/ptg.html PTG schedule | 16:20 |
| bauzas | I'll create a email for asking folks to provide their topics before next week | 16:21 |
| bauzas | so, we could organize the planning | 16:21 |
| bauzas | obviously, we could have other topics after next week, but I'd prefer to have a lot of them by next week | 16:22 |
| gibi | ack | 16:22 |
| bauzas | so, please do this if you want to discuss | 16:22 |
| bauzas | also, I said last week I was starting to draft the operators etherpad | 16:22 |
| bauzas | so | 16:23 |
| gibi | also would be nice to have a countdown til the PTG, we have 4 weeks til the PTG if I count well | 16:23 |
| bauzas | #link https://etherpad.opendev.org/p/oct2022-ptg-operator-hour-nova | 16:23 |
| bauzas | gibi: hah, good point | 16:23 |
| bauzas | #info 4 weeks before the PTG | 16:23 |
| elodilles | (i count only 3 weeks) | 16:23 |
| bauzas | #undo | 16:23 |
| opendevmeet | Removing item from minutes: #info 4 weeks before the PTG | 16:23 |
| bauzas | #info 3 weeks before the PTG | 16:24 |
| bauzas | that depends on how you count but yeah | 16:24 |
| gibi | yeah | 16:24 |
| gibi | then I lost a week :/ | 16:24 |
| bauzas | #link https://releases.openstack.org/antelope/schedule.html#a-ptg | 16:24 |
| *** mloza2 is now known as mloza | 16:24 | |
| * gibi need to set aside some time to prepare for the PTG | 16:24 | |
| bauzas | me too, I'd like to look at the open specs | 16:25 |
| bauzas | anyway | 16:25 |
| bauzas | about the operators etherpad, I just created a few topics as you see | 16:25 |
| bauzas | the same ones we had from Berlin | 16:25 |
| bauzas | if you want to add more topics for asking operators, add them | 16:26 |
| bauzas | (keeping in mind we have two operator hours on Tues and 1 hour on Wed) | 16:26 |
| bauzas | anything to mention about the PTG ? | 16:27 |
| bauzas | looks not | 16:29 |
| bauzas | #topic Review priorities | 16:29 |
| bauzas | #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+(label:Review-Priority%252B1+OR+label:Review-Priority%252B2) | 16:29 |
| bauzas | nothing to tell about those | 16:29 |
| bauzas | moving on | 16:30 |
| bauzas | #topic Stable Branches | 16:31 |
| bauzas | elodilles: time is yours | 16:31 |
| elodilles | #info stable/yoga is unblocked openstacksdk fix has merged | 16:31 |
| elodilles | #info stable/stein (and older) are blocked: grenade and other devstack based jobs fail with the same timeout issue as stable/train was previously | 16:31 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:31 |
| elodilles | and that is all from me | 16:31 |
| bauzas | ok | 16:32 |
| bauzas | thanks all for unblocking the yoga branch | 16:32 |
| elodilles | yepp, thanks to openstacksdk team | 16:33 |
| bauzas | ok, anything to add ? | 16:34 |
| bauzas | ok, eventually the last topic then | 16:34 |
| bauzas | #topic Open discussion | 16:34 |
| bauzas | #link https://review.opendev.org/c/openstack/nova-specs/+/859290 Add support of Napatech SmartNICs | 16:35 |
| bauzas | justas_napa: tell us more | 16:35 |
| justas_napa | So maybe I'll start with a quick intro | 16:35 |
| *** mloza is now known as atmark | 16:35 | |
| justas_napa | I'm Justas Poderys, product architect working on Napatech LinkVirtualization products | 16:35 |
| justas_napa | We have been running OpenStack on our SmartNICs for over a year now, and internally support (via patches) everything from Victoria to Zed | 16:36 |
| justas_napa | Going forward we'd like to enable OpenStack to work with Napa's smartnics out of the box | 16:36 |
| justas_napa | for that we would like to add a VIF type corresponding to Napatech SmartNIC | 16:36 |
| justas_napa | ein a simmilar fashion like Netronomes Agillio | 16:37 |
| justas_napa | But at the same time we do not need a new VNIC type | 16:37 |
| bauzas | do you work with Neutron ? | 16:37 |
| justas_napa | Yes | 16:37 |
| bauzas | so I guess you also have a neutron spec | 16:37 |
| justas_napa | We have extremely small update to Neutron, but yes, we will do a Neutron spec as well | 16:38 |
| bauzas | this doesn't look a lot of change for nova, right? | 16:38 |
| bauzas | we already support *some* smartnic experiments | 16:39 |
| justas_napa | no, I think it's less than 50 lines | 16:39 |
| *** atmark is now known as mloza | 16:39 | |
| *** mloza is now known as atmark | 16:39 | |
| bauzas | justas_napa: I guess you already know about what Nova supports by the Wallaby release ? | 16:40 |
| justas_napa | We will publish all changes to Nova and Os-Vif on OpenDev in the next few days | 16:40 |
| justas_napa | bauzas What do you mean? | 16:40 |
| bauzas | sorry, wrong release | 16:41 |
| bauzas | justas_napa: I was talking of https://specs.openstack.org/openstack/nova-specs/specs/xena/implemented/sriov-smartnic-support.html | 16:41 |
| *** atmark is now known as mloza | 16:41 | |
| bauzas | oh wait no, my bad | 16:41 |
| *** mloza is now known as atmark | 16:41 | |
| bauzas | again, wrong spec | 16:41 |
| bauzas | https://specs.openstack.org/openstack/nova-specs/specs/yoga/implemented/integration-with-off-path-network-backends.html | 16:42 |
| bauzas | anyway, I just pointed out the existing specs | 16:42 |
| bauzas | afaics, this is just a review ask | 16:43 |
| bauzas | so, we'll review it | 16:43 |
| bauzas | justas_napa: would you want to discuss your topic during the PTG ? | 16:43 |
| bauzas | in case we have concerns | 16:43 |
| justas_napa | Sure, I can do that | 16:43 |
| bauzas | thanks | 16:44 |
| bauzas | if you can't do, no worriezs | 16:44 |
| justas_napa | Re: off-path networking backed - we are in the progress of integrating Intel Big Spring Canyon platform to du just that | 16:44 |
| bauzas | justas_napa: and you don't need to be on the whole PTG times | 16:44 |
| bauzas | justas_napa: we could just ping you when we are at the topic | 16:44 |
| justas_napa | sure | 16:45 |
| bauzas | thanks | 16:45 |
| justas_napa | So what's the path from here: 1. We puiblish code changes and ask for review in channel? | 16:45 |
| justas_napa | and then PTG? | 16:45 |
| bauzas | anyone having questions or thoughts for this ? | 16:45 |
| bauzas | justas_napa: indeed | 16:45 |
| justas_napa | cool. | 16:45 |
| bauzas | we will review your spec first, but if you have implementation changes, that would be nice | 16:46 |
| bauzas | as if we have concerns, we could just look at your changes | 16:46 |
| justas_napa | Yes, we have implemetation changes as well, since we are running it internally anyway | 16:46 |
| gibi | I agree with bauzas | 16:46 |
| bauzas | to understand what you need | 16:46 |
| justas_napa | btw - is it OK to bring one more topick to PTG. Specifically, how to support Packed Ring Libvirt option (packed=on) and which project should implement that. | 16:47 |
| bauzas | justas_napa: I guess you know how to depend on neutron changes ? | 16:47 |
| bauzas | justas_napa: yeah, no worries | 16:47 |
| bauzas | the PTG is here for discussing | 16:47 |
| justas_napa | Yes, I'm aware that we need changes in Nova *and* Neutron to make this work | 16:48 |
| bauzas | justas_napa: my only concern is about how to test your nova changes if you need an os-vif release | 16:48 |
| bauzas | as you can't Depends-On | 16:48 |
| bauzas | gibi: correct for os-vif, right? | 16:48 |
| bauzas | I meant, can we depend-on os-vif patches ? | 16:49 |
| gibi | I'm not sure either | 16:49 |
| justas_napa | I'll put this also as TBD item for our dev team | 16:49 |
| bauzas | justas_napa: do you understand about my question ? | 16:49 |
| bauzas | justas_napa: if you upload three changes, each for a different repo | 16:50 |
| gibi | bauzas: it depends on how the zuul job is set up. Are we testing with released os-vif lib or are we taking master all the time? | 16:50 |
| bauzas | justas_napa: in general, you can depend a gerrit cvhange on another one | 16:50 |
| justas_napa | Yes, I understand the issue of cross-project dependancy | 16:50 |
| gibi | bauzas: if the former, then the a DNM nova patch on top of the nova series could configure zuul to use the later method + add a Depends-On to the os-vig patch | 16:51 |
| justas_napa | and that our change is not atomic across the projects | 16:51 |
| bauzas | justas_napa: but here, the question is that for some libraries, we maybe use a specific release and not using master | 16:51 |
| bauzas | gibi: yeah, that would work | 16:51 |
| bauzas | justas_napa: do you understand what gibi is explaining ? | 16:52 |
| justas_napa | OK, I understand the issue, but I'm not sure I can offer a solution. | 16:52 |
| bauzas | justas_napa: well, we maybe have a solution, that's the point | 16:52 |
| justas_napa | One way is to use our ci/cd setup where we runn all regression tests and have control of releases of all projects | 16:52 |
| bauzas | anyway, we should be discussing this in the spec | 16:53 |
| bauzas | justas_napa: are you saying you could provide a third-party CI for nova/neutron ? :D | 16:53 |
| bauzas | this would be lovely | 16:53 |
| justas_napa | not sure what you mean 3rd party | 16:54 |
| justas_napa | but we have our own ci/cd pipeline running integration tests with our changes | 16:54 |
| bauzas | ok, then we'll discuss this in the spec and we can also provide you some links if you want | 16:54 |
| justas_napa | to ensure we do not break anything with our OS patches | 16:55 |
| bauzas | justas_napa: are you running tempest tests ? | 16:55 |
| justas_napa | yes | 16:55 |
| bauzas | cool, then that's something we need to discuss then | 16:55 |
| bauzas | anyway, I guess we're done about your topic | 16:55 |
| bauzas | we'll continue discussing | 16:56 |
| justas_napa | sure, thanks for all questions and comments | 16:56 |
| bauzas | folks, any other item to bring before we end the meeting ? | 16:56 |
| bauzas | looks not | 16:56 |
| bauzas | thanks all | 16:57 |
| bauzas | #endmeeting | 16:57 |
| opendevmeet | Meeting ended Tue Sep 27 16:57:04 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:57 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-09-27-16.00.html | 16:57 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-09-27-16.00.txt | 16:57 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-09-27-16.00.log.html | 16:57 |
| elodilles | thanks o/ | 16:57 |
| gibi | o/ | 16:58 |
| JayF | bauzas: o/ We need to meet up and discuss timing for joint Ironic<>Nova PTG session. | 18:45 |
| JayF | bauzas: unsure what timezone you're in, but if you're asleep/AFK right now, just DM me and we can figure it out async | 18:45 |
| stephenfin | JayF: bauzas is in France so CET. You'll catch him tomorrow | 18:59 |
| JayF | ack; I figured, not a big deal, took me a couple of days to voluntell the right people I needed them in that session and get scheduling deets :D | 19:00 |
| *** dasm is now known as dasm|off | 21:31 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!