| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-25 | |||
| 09:55:51 | openstackgerrit | Wenping Song proposed openstack/nova master: Nova supports password encrypted VNC https://review.opendev.org/c/openstack/nova/+/622336 | |
| 10:10:19 | openstackgerrit | Wenping Song proposed openstack/nova master: Nova supports password encrypted VNC https://review.opendev.org/c/openstack/nova/+/622336 | |
| 10:15:33 | brinzhang | stephenfin, melwitt: the noVNC patch changed the auth_type with *VENCRYPT*, addressed your comment, pls recheck | |
| 10:15:50 | stephenfin | ack | |
| 11:14:56 | openstackgerrit | Merged openstack/nova master: libvirt: add IP address to libvirt guest metadata https://review.opendev.org/c/openstack/nova/+/750552 | |
| 12:51:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: neutron: Rework how we check for extensions https://review.opendev.org/c/openstack/nova/+/705792 | |
| 12:51:26 | openstackgerrit | Stephen Finucane proposed openstack/nova master: neutron: Remove references to out-of-tree 'qos-queue' extension https://review.opendev.org/c/openstack/nova/+/754448 | |
| 13:13:12 | sean-k-mooney | gibi: im planning to repin the first patch in the port numa affintiy series wich implemnt the sriov half today. ater i do that im going to try and quickly file a patch for https://bugs.launchpad.net/nova/+bug/1915255 will you have time to look at those if i ping you later | |
| 13:13:13 | openstack | Launchpad bug 1915255 in OpenStack Compute (nova) victoria "[Victoria] nova-compute won't start on aarch64 - raises PciDeviceNotFoundById" [Medium,Triaged] | |
| 13:13:36 | sean-k-mooney | bauzas: maybe i could premtivly line you up as a second core to review them when they are ready. | |
| 13:19:23 | sean-k-mooney | stephenfin: by the way one thing to keep in mind with the neutron extensions is that just becaue neutron reports an extension is avialable does not mean its actully enabled in neutron | |
| 13:19:42 | sean-k-mooney | we might want to document that somewhere | |
| 13:20:18 | sean-k-mooney | if an exetion is not found its definetly not support but if it is it may or may not be supproted because they do not really filter properly | |
| 13:20:22 | sean-k-mooney | its a bit of a mess | |
| 13:20:51 | sean-k-mooney | i still like your change just which neutorn reported only the extentions that will work. | |
| 13:21:43 | sean-k-mooney | we had a cross project discussion on this in the ptg in the past where i was suggesting adding a new api to report it in a more sane way but that was just brain storming | |
| 13:21:57 | sean-k-mooney | i dont expect this to change in the near term | |
| 15:05:24 | sean-k-mooney | bauzas: am i right in thinking that ovo changes wont impact your rpc bump patches provided im not changing any of the calls | |
| 15:05:33 | bauzas | no | |
| 15:05:54 | bauzas | remotable classmethods don't need to have new RPC versioning | |
| 15:06:05 | sean-k-mooney | oh no i ment | |
| 15:06:16 | sean-k-mooney | adding a field to an ovo wont conflict with your work | |
| 15:06:17 | bauzas | because they already have versions ;) | |
| 15:06:26 | bauzas | sean-k-mooney: yup, that too | |
| 15:06:29 | sean-k-mooney | cool | |
| 15:07:04 | sean-k-mooney | just wanted to make sure the the ovo change im doing for vdpa wont conlfict. in anyway | |
| 15:08:22 | bauzas | sean-k-mooney: I can review your change | |
| 15:08:52 | bauzas | but tbc, just remember that o.vo objects are transformed when passed to the RPC API | |
| 15:09:07 | sean-k-mooney | i have not posted them yet so im guessing it will be after you finsih for the day. they will be there for you on monday in anycase | |
| 15:09:18 | sean-k-mooney | bauzas: oh i know | |
| 15:09:30 | sean-k-mooney | they are backlevel to the max suported version of the dest | |
| 15:10:08 | sean-k-mooney | non of the feautes im working on are ment to work in the mixed deployment anyway | |
| 15:11:03 | sean-k-mooney | i just wanted to make sure i was not writing patches that would confilct with your rpc one since that will be a pain to write and keep current | |
| 15:16:40 | bauzas | sean-k-mooney: just bump the compute service and you'll hit my face | |
| 15:17:07 | bauzas | but I don't think you'll need to change the RPC calls, right? | |
| 15:17:22 | bauzas | just how the objects are passed | |
| 15:17:23 | sean-k-mooney | correct i dont | |
| 15:17:31 | bauzas | anyway, that's fine | |
| 15:17:36 | sean-k-mooney | i just need to add a new value to the dev_type field for vdpa | |
| 15:17:41 | bauzas | we should work on bumping the APIs only after FF | |
| 15:17:45 | sean-k-mooney | in the PciDevice object | |
| 15:18:03 | bauzas | but given we had a long day from the last bump, I preferred to work on it sooner than later | |
| 15:18:18 | sean-k-mooney | for the port numa work i only need the request_networksin in the request spec which you already added | |
| 15:18:24 | bauzas | and I was right, I'm facing weirdo bugs | |
| 15:18:27 | sean-k-mooney | so no object or rpc change there | |
| 15:18:33 | bauzas | ++ | |
| 15:50:49 | gibi | nova weekly meeting starts in 9 minutes in #openstack-meeting-3 | |
| 16:01:19 | stephenfin | bauzas: Think you could add https://review.opendev.org/c/openstack/nova/+/756552 to your review queue also? 0:) | |
| 16:03:08 | bauzas | stephenfin: ack, CC'd | |
| 16:37:45 | sean-k-mooney | did the nova meeting finish already? | |
| 16:38:24 | gibi | sean-k-mooney: yepp | |
| 16:38:42 | gibi | sean-k-mooney: did you missed it? | |
| 16:38:57 | sean-k-mooney | yep having a downstream conversation | |
| 16:39:00 | sean-k-mooney | was about to join | |
| 16:39:38 | gibi | sean-k-mooney: sorry we run out of topics early so I closed it | |
| 16:39:47 | sean-k-mooney | thats ok | |
| 16:39:54 | gibi | sean-k-mooney: is there anything you wanted to raise? | |
| 16:40:31 | sean-k-mooney | kind of we have a downstram bz filed for one of nova default polices | |
| 16:40:36 | sean-k-mooney | https://bugzilla.redhat.com/show_bug.cgi?id=1933047 | |
| 16:40:38 | openstack | bugzilla.redhat.com bug 1933047 in openstack-nova "Provider Networks have to be shared or Nova will fail to create a server with "not allowed to create an interface on external network"" [Unspecified,New] - Assigned to nova-maint | |
| 16:41:09 | sean-k-mooney | im not really sure im comforatble changeign that behavior downstrema only but its not really a bug in my view either | |
| 16:41:26 | sean-k-mooney | on the other hand that policy may not be required anymore. | |
| 16:41:35 | sean-k-mooney | so i wanted to get more input | |
| 16:45:57 | gibi | sean-k-mooney: hm if the provider net was created with --project for a specific tenant then I would expect that tenant can boot a VM on that net | |
| 16:46:09 | sean-k-mooney | it can | |
| 16:46:15 | sean-k-mooney | if its not an external network | |
| 16:46:20 | sean-k-mooney | at least i think it can | |
| 16:46:26 | sean-k-mooney | the issue here is its both | |
| 16:47:37 | gibi | OK then I don't have enough knowledge on the networking side of this. | |
| 16:48:04 | gibi | sean-k-mooney: ooh we have a nova policy for this | |
| 16:48:19 | sean-k-mooney | thats ok. external networks are network whose subnets are sued for floating ip and neutron router gateway ports | |
| 16:48:27 | sean-k-mooney | gibi: yes we do | |
| 16:48:39 | sean-k-mooney | i dont think neutron supported this when we added the policy | |
| 16:48:50 | gibi | so the admin when creates the external net for a tenant can give the tenant servers_policies.NETWORK_ATTACH_EXTERNAL rights in nova, and then it will work | |
| 16:49:23 | sean-k-mooney | via custom plolicy rules yes | |
| 16:50:01 | gibi | then it is a config issue on the admin side | |
| 16:50:11 | gibi | the admin only did half of the work to provide the access for the tenant | |
| 16:50:21 | sean-k-mooney | yep | |
| 16:50:36 | sean-k-mooney | the issue is we do not supprot custom policy in our product | |
| 16:50:37 | gibi | would that be a good answer for your BZ? | |
| 16:50:42 | gibi | aaah | |
| 16:50:43 | gibi | I see | |
| 16:50:50 | sean-k-mooney | so we are being asked is this policy valid anymore | |
| 16:50:54 | sean-k-mooney | and can it be removed | |
| 16:51:19 | sean-k-mooney | im trying to understand if there is a usecase for this now or should we allow neutron to enforce this | |
| 16:51:46 | sean-k-mooney | my concern is that the precednce around policy changes is to have a deprecation cylce | |
| 16:52:16 | sean-k-mooney | meaning we could only change or remove this in xena even if we deperacted its current value this cycle | |
| 16:52:56 | sean-k-mooney | we can support this for a customer explicty via a supprot excption downstream | |
| 16:53:18 | sean-k-mooney | im just not sure im comfortable changing the default downstream without fully understaind all the implication of that policy | |
| 16:57:12 | gibi | I don't have the networking background to decide on if having a tenant attaching to an external net is a valid use case | |
| 16:57:42 | sean-k-mooney | ya i think we are going to start a mailing list post on this topic | |
| 16:59:01 | gibi | good idea | |
| 17:11:23 | sean-k-mooney | gibi: thanks for looking by the way | |
| 17:11:31 | gibi | no problem | |
| 18:16:23 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: Bump the Compute RPC API to version 6.0 https://review.opendev.org/c/openstack/nova/+/761452 | |
| 18:16:55 | bauzas | oh f**** we just merged interface attach which conflicts with ^ | |
| 18:17:06 | bauzas | I'm a sad panda | |
| 18:17:33 | bauzas | oh man, wait | |
| 18:20:57 | sean-k-mooney | didnt that merge a few days ago | |
| 18:20:57 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: Bump the Compute RPC API to version 6.0 https://review.opendev.org/c/openstack/nova/+/761452 | |