| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-11 | |||
| 19:28:31 | sean-k-mooney | o/ | |
| 19:28:32 | gibi | o/ | |
| 19:28:37 | stephenfin | ciao | |
| 20:03:13 | sean-k-mooney | ok so i have a small bug here https://review.opendev.org/c/openstack/nova/+/770533/10/nova/virt/libvirt/host.py#1237 so ill respin that patch and add testing to make sure claiming the PF handels the VDPA devices correctly | |
| 20:06:32 | openstackgerrit | melanie witt proposed openstack/nova master: Dynamically archive FK related records in archive_deleted_rows https://review.opendev.org/c/openstack/nova/+/773834 | |
| 21:09:04 | openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: tests: Add functional test for vDPA device https://review.opendev.org/c/openstack/nova/+/780112 | |
| 21:09:11 | stephenfin | sean-k-mooney: so that's not done, but you should be able to see where it's going. I'll finish it in the morning ^ | |
| 21:10:40 | sean-k-mooney | thanks | |
| 21:10:47 | stephenfin | sean-k-mooney: nw. Don't forget to file the FFE email :) | |
| 21:11:19 | sean-k-mooney | i fixed the bug i had and now im testing the PF issue that gibi asked about | |
| 21:11:40 | sean-k-mooney | ill send the email yeas | |
| #openstack-nova - 2021-03-12 | |||
| 01:26:16 | openstackgerrit | sean mooney proposed openstack/nova master: libvirt: Add guest generation for vDPA https://review.opendev.org/c/openstack/nova/+/770532 | |
| 01:26:16 | openstackgerrit | sean mooney proposed openstack/nova master: libvirt: Add vDPA nodedev parsing https://review.opendev.org/c/openstack/nova/+/770533 | |
| 01:26:17 | openstackgerrit | sean mooney proposed openstack/nova master: pci: Add vDPA vnic to PCI request mapping and filtering https://review.opendev.org/c/openstack/nova/+/778350 | |
| 01:26:18 | openstackgerrit | sean mooney proposed openstack/nova master: add hw:mlock extra spec https://review.opendev.org/c/openstack/nova/+/778347 | |
| 05:34:47 | openstackgerrit | Yongli He proposed openstack/nova master: smartnic support - functional tests https://review.opendev.org/c/openstack/nova/+/780147 | |
| 08:11:51 | gibi | sean-k-mooney: ack, looking | |
| 08:13:22 | gibi | yonglihe: hi! Is it possible to test the smartnic series in a devstack with the fake cyborg driver? | |
| 08:14:16 | yonglihe | functional test it is. devstack, we need real hw for that. | |
| 08:15:31 | yonglihe | except that, the devstack have some feature to accept the VM stuck to a none-exit pci devices as succeefuly state(that expected off cause). | |
| 08:16:32 | yonglihe | If we also use a faked libvirt, that workable. | |
| 08:20:17 | yonglihe | gibi: btw, othe comments gonna take me 2 or 3 days hard work. | |
| 08:21:37 | gibi | yonglihe: so the devstack + cyborg fake driver solution doesn't work as the fake driver returns nonexistent pci device and that cannot be added to the VM. thank make sense. | |
| 08:21:44 | gibi | yonglihe: which comment is the hard one? | |
| 08:22:11 | yonglihe | code reactors. | |
| 08:22:16 | yonglihe | refactors | |
| 08:22:34 | yonglihe | but we have solutions for that. | |
| 08:25:27 | yonglihe | The one need decouple the flavor arq from port-arq need more force, that cofused everyone. | |
| 08:25:36 | gibi | I see | |
| 08:26:04 | gibi | alex_xu: will you be around in the next week to review the smartnic series ? | |
| 08:26:09 | yonglihe | but we could use port uuid instead of instace uuid as arq consumer, that will much more clear | |
| 08:26:23 | gibi | hm that sounds like a good idea | |
| 08:31:39 | alex_xu | gibi: yes, I will be there to review the smartnic series | |
| 08:31:47 | gibi | alex_xu: thanks | |
| 08:32:20 | alex_xu | np | |
| 08:32:50 | gibi | yonglihe: how do you feel can you propose the fixes not later than Wednesday next week? | |
| 08:33:56 | yonglihe | Your Wednesday, thats sounds ok for me. | |
| 08:35:58 | gibi | Ok | |
| 08:50:31 | bauzas | good morning Nova | |
| 08:51:47 | bauzas | have we discussed on FFEs ? | |
| 08:52:26 | bauzas | nvm http://lists.openstack.org/pipermail/openstack-discuss/2021-March/020772.html | |
| 08:53:27 | gibi | bauzas: yepp, and we have two requested on the ML | |
| 08:53:38 | bauzas | I see the smartnic ones | |
| 08:53:45 | bauzas | hence my question | |
| 08:53:51 | gibi | bauzas: sean-k-mooney requested one for the vdpa too | |
| 08:54:00 | bauzas | oh, the vdpa one | |
| 08:54:23 | gibi | if you read the scrollback then you see my discussion with yonglihe and alex_xu about the smartnic one | |
| 08:54:39 | gibi | from this morning | |
| 08:54:41 | bauzas | the vdpa one got eyes on it yesterday AFAICT | |
| 08:54:51 | gibi | bauzas: yes, and we found a bug | |
| 08:54:51 | bauzas | but what about the smartnic one ? | |
| 08:55:14 | gibi | bauzas: so the vdpa one is pretty close as sean-k-mooney fixed the bug during the night | |
| 08:55:40 | gibi | bauzas: for vdpa we need a patch that blocks unsupported operations like live-migrate, and needs a reno | |
| 08:55:42 | bauzas | merging stuff on today seems reasonable to me provided we kinda verify we don't really change a lot | |
| 08:56:12 | bauzas | like, adding new stuff looks good to me, but for example, asking to have a new ovo field, no | |
| 08:56:14 | gibi | I think we have a good chance to approve the vdpa one today | |
| 08:56:26 | bauzas | gibi: ok, and for smartnic ? | |
| 08:56:33 | gibi | that is a bigger step | |
| 08:56:35 | bauzas | gibi: I can try to look at it | |
| 08:56:38 | bauzas | hah | |
| 08:56:44 | gibi | I had various comments yesterday | |
| 08:56:54 | bauzas | I'll quickly look at the series | |
| 08:57:14 | gibi | yonglihe thinks the hard parts of that can be fixed not later than Wednesday | |
| 08:57:26 | gibi | bauzas: and alex_xu confirmed that he will be around to review | |
| 08:57:35 | bauzas | because as i said, if they want to modify some RPC APIs or want to change ov.o objects or DB, then I wouldn't be super happy | |
| 08:57:52 | bauzas | gibi: well, Wednesday is a bit late, no ? :- | |
| 08:57:53 | bauzas | :( | |
| 08:58:01 | gibi | it is a stretch | |
| 08:58:25 | bauzas | again, my concern is not really about when, but rather about what's modified | |
| 08:58:26 | gibi | bauzas: when you say no new ovo field do you mean we should not merge anything after tomorrow that changes an ovo? | |
| 08:58:31 | bauzas | yes | |
| 08:58:34 | bauzas | or a RPC API | |
| 08:58:37 | bauzas | or a DB upgrade | |
| 08:58:39 | bauzas | or... | |
| 08:58:46 | bauzas | or a API microversion | |
| 08:59:15 | gibi | there is no DB/RPC change in vdpa or smartnic | |
| 08:59:20 | gibi | but both changes ovo | |
| 08:59:23 | bauzas | because merging those while we're already close to RC1 means that if we see problems, it could be difficult to just revert the changes | |
| 08:59:24 | gibi | smartnic adds field https://review.opendev.org/c/openstack/nova/+/771363/13/nova/objects/network_request.py | |
| 08:59:36 | bauzas | /o\ | |
| 08:59:52 | bauzas | if we merge those ovo changes today, I'm OK | |
| 09:00:05 | bauzas | what I'm not OK it to merge ovo changes like next week | |
| 09:00:08 | gibi | vdpa adds enum value https://review.opendev.org/c/openstack/nova/+/777481/8/nova/objects/fields.py | |
| 09:00:19 | bauzas | I know for vdpa | |
| 09:00:20 | gibi | bauzas: fair point | |
| 09:00:36 | gibi | then I think smartnic needs to be deferred | |
| 09:00:56 | gibi | I'm not happy to merge the ovo change today without seeing the whole series coming together | |
| 09:00:57 | bauzas | again, it's more a question about how to be reverting if we merge them next week and we see problems | |
| 09:01:09 | bauzas | gibi: yeah :( | |
| 09:01:20 | gibi | and you have a valid point about the risk in ovo | |
| 09:01:43 | bauzas | but for example, I could be OK with merging a new config option on Monday | |
| 09:01:58 | bauzas | Wednesday is late | |
| 09:02:11 | bauzas | but, at least if we see problems, it's simple to just revert | |
| 09:02:35 | bauzas | people could tell it's simple to revert ovo changes | |
| 09:02:50 | bauzas | but the problem here is that master is down then | |
| 09:03:07 | gibi | what do you mean by down? | |
| 09:08:43 | bauzas | gibi: I mean that if we would want to revert an ovo patch, this would mean that we absolutely need to be sure that we don't merge other ovo changes after this one | |
| 09:08:55 | bauzas | we can pretend it never existed but there is a high risk of tangling | |
| 09:09:19 | bauzas | hence me being super conservative about such changes to be merged while we're so close from RC1 | |
| 09:09:45 | gibi | tanglig by having two different ovo object with the same version | |