Earlier  
Posted Nick Remark
#openstack-nova - 2021-03-11
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
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
09:12:23 gibi yonglihe: bauzas had a point above about the ovo change being risky close to RC1 and I think his point is valid. I'm affraid we have to defer the smartnic series to X
09:12:40 gibi alex_xu: ^^
09:12:52 bauzas I'll review the series this morning
09:13:02 bauzas it's fair to look at the change before cutting the rope
09:13:39 yonglihe gibi: got, that's reasonable. likely, we could merge smartnic in very ealry stage of X

Earlier   Later