Earlier  
Posted Nick Remark
#openstack-nova - 2021-03-11
19:27:11 gibi OK, then I will check where we are tomorrow morning
19:27:15 sean-k-mooney i can email the list and formally request one if you like
19:27:22 gibi sean-k-mooney: yes please
19:27:27 sean-k-mooney ok will do
19:27:37 gibi you can refer to me and stephenfin as supporters for the FFE
19:27:51 gibi this is really close and it is useful
19:28:06 gibi so I'm willing to spend timeon this tomorrow and early next week
19:28:09 sean-k-mooney ok ill wait for the irc logs to catch up and ill also link to this conversation
19:28:12 gibi to get it approvaed
19:28:18 gibi sean-k-mooney: sure
19:28:24 sean-k-mooney gibi++
19:28:24 gibi OK, I'm leaving now
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 vDPA nodedev parsing https://review.opendev.org/c/openstack/nova/+/770533
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: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 bauzas but what about the smartnic one ?
08:54:51 gibi bauzas: yes, and we found a bug
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

Earlier   Later