Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-07-05
16:41:10 bauzas I'll leave some notes
16:41:17 bauzas that's it for me, I need to leave
16:41:21 gibi bauzas: o/
16:41:28 gibi so we have one more thing on the agenda
16:41:29 sean-k-mooney it works fine for neutron as far as i can tell but they more have the stream so people can listen and then respond via etherpath/irc
16:41:31 bauzas I have another item to discuss but let's punt it for next week
16:41:35 gibi (bauzas) Opportunities for low-hanging-fruits, anyone ? (only if we have time left)
16:41:39 gibi ahh OK
16:41:41 gibi then it is punted
16:41:44 bauzas thanks
16:41:52 gibi does anyone here has an extra topic for today?
16:41:58 bauzas gibi: feel free to wrap the meeting
16:42:02 gibi bauzas: will do
16:42:10 bauzas ++
16:42:17 sean-k-mooney not really but i will think about low haning fruit for the next one
16:42:49 gibi OK, so if nothing else today then I will close the meeting
16:42:54 gibi thanks for all joining
16:42:58 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-07-05-16.00.log.html
16:42:58 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-07-05-16.00.txt
16:42:58 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-07-05-16.00.html
16:42:58 opendevmeet Meeting ended Tue Jul 5 16:42:58 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:42:58 gibi #endmeeting
16:43:08 gibi sean-k-mooney: so we can go back to the tag, mount_tag question
16:43:13 sean-k-mooney sure
16:43:22 sean-k-mooney i updated my comment with my resoning in the review
16:43:31 gibi I'm cheking...
16:43:54 sean-k-mooney https://review.opendev.org/c/openstack/nova-specs/+/833669/10/specs/zed/approved/libvirt-virtiofs-attach-manila-shares.rst#365=
16:44:28 sean-k-mooney my concern is basically if we change the backend mechanium in the future or a differnt virt driver wants to support this
16:44:38 sean-k-mooney im not sure we want to overload tag
16:45:42 sean-k-mooney if you and bauzas are ok with that we can proceed as is and it can always be changed in a microversion later
16:46:00 sean-k-mooney so it might be premature optimisation for a case we will never support
16:46:10 Uggla sean-k-mooney, I can still change it
16:46:53 sean-k-mooney Uggla: if we argree to change it what i propose is i +w the spec as it is and you can adress it and other nits in a follow up patch
16:47:30 Uggla it is just a matter of renaming from tag to mount_tag (sorry I read it really fast so far).
16:47:48 sean-k-mooney Uggla: well renaming but also keeping tag
16:48:18 gibi sean-k-mooney: replied
16:48:41 sean-k-mooney tag would be optional and used for device role tagging and mount_tag would be used to configure the mount
16:49:07 gibi so my point is to use 'tag' for device tagging, and document that libvirt with virtio_fs automatically use this tag also for mount_tag
16:49:20 gibi as I don't see why would the user want to set two tags
16:49:31 gibi one device tag and one mount_tag to different value
16:50:25 Uggla sean-k-mooney, so adding 1 more field. I guess that's ok to do it. Doing it right now will avoid db migration.
16:51:19 sean-k-mooney gibi: the only concern i have with that is the high level device role tag is normally optional
16:51:38 gibi can we generate the mount tag from the manial share uuid?
16:51:45 gibi if it is not provided?
16:51:47 sean-k-mooney where as the mount_tag woudl be required unless we default to the manila share id so i guess thats ok
16:52:13 sean-k-mooney gibi: that depned on the lenght requriement for ti at teh virtio fs level
16:52:22 sean-k-mooney but a uuid is 36charters long
16:52:25 sean-k-mooney that shoudl be ok
16:52:35 gibi as we have a single device tag per device I think it is use to identify the device, also mount_tag is used to identify the share in the guest, so I don't think we need two divergent identity for a single device
16:52:36 sean-k-mooney i think we said it woudl be 64
16:53:20 sean-k-mooney ok you have convinced me that im either over thinking it or that we can adress it in the future with a microverion if needed
16:53:46 sean-k-mooney so let go with just tag as optional today and default to the manila share id which is what the spec says
16:54:07 Uggla sean-k-mooney, \o/
16:55:01 gibi sean-k-mooney: thanks
16:56:07 sean-k-mooney gibi: i also agree with your clarification regarding attach/error
16:56:38 sean-k-mooney anyway i have send it to hte gate but we likely should do a followup for the nits
16:56:39 gibi ack, that is just a nit
16:56:59 gibi agree to do just a follow up
16:58:45 sean-k-mooney gibi: should we abandon https://review.opendev.org/c/openstack/nova-specs/+/802034 and of abanon it a m2
16:58:53 sean-k-mooney Migrate Instance Between Projects
16:59:07 sean-k-mooney it has not been updated since yoga
16:59:36 sean-k-mooney if we were to porceed with it im usre we would need a lot of work that wont happne in zed
16:59:56 gibi I think we should abandon all the old open specs at m2
17:00:04 sean-k-mooney i guess there is no harm in leaving it till then ya
17:00:05 gibi I think I suggested this to bauzas before
17:00:29 gibi it can always be restored but it cleanes up gerrit
17:00:39 gibi I have to drop now. see you tomorrow o/
17:01:02 sean-k-mooney o/
17:10:59 opendevreview Merged openstack/nova-specs master: libvirt: Allow Manila shares to be directly attached to instances https://review.opendev.org/c/openstack/nova-specs/+/833669
17:16:15 sean-k-mooney Uggla:^
#openstack-nova - 2022-07-06
03:56:51 opendevreview OpenStack Proposal Bot proposed openstack/python-novaclient master: Imported Translations from Zanata https://review.opendev.org/c/openstack/python-novaclient/+/848804
06:30:00 gibi good morning
07:23:12 bauzas good morning
07:53:12 bauzas gibi: yeah, scrolled above, indeed I was thinking about abandoning the Yoga specs after Zed spec approval freeze
08:10:39 gibi ack
12:50:07 sean-k-mooney dansmith: bauzas can you confrim the logic asserted in the commit https://review.opendev.org/c/openstack/nova/+/845335 i belive they are correct but i dont know if we had those returns for a reason
12:50:52 bauzas oh that
12:51:04 bauzas yeah, simple and trivial fix I discussed with ratailor__
12:51:18 sean-k-mooney ya rajesh is correct casts shoudl not return anything
12:51:29 bauzas sean-k-mooney: I think it was just a copy/paste problem
12:51:36 bauzas when people created those calls
12:51:37 sean-k-mooney and techinaly beofre and after this call if you assinged the result to avar the content would be None
12:51:50 sean-k-mooney ya ok that what i assumed too
12:51:53 bauzas cctxt.cast() retunrs None anyone
12:51:56 bauzas anyway*
12:52:20 sean-k-mooney yep and the default result fo a fucntion that does not return is None
12:52:25 sean-k-mooney if you assign it to a var
12:52:33 sean-k-mooney so i dont think this changes the interface in any way
12:52:50 sean-k-mooney just being extra carful since its in the rpc api
12:56:22 bauzas sean-k-mooney: proof of evidence https://github.com/openstack/oslo.messaging/blob/f1b47b6ba8ee4888f6cba1efac0fbf747c5406e6/oslo_messaging/rpc/client.py#L476
12:56:34 bauzas sorry, took me a while, my laptop is burning CPU
12:58:00 sean-k-mooney hehe ya i know it does not have a return
12:58:38 sean-k-mooney the other reason i was +1 and not +2 is the lack of a bug
12:58:46 sean-k-mooney bauzas: so without adding that we cant backport
12:59:29 bauzas sean-k-mooney: mmmm, I'm maybe wrong, but we don't need to file a bug report for backporting to stable branches
12:59:43 bauzas I can verify the stable policy tho
13:00:03 sean-k-mooney i tought that was a requirement but if not i guess its fine
13:00:10 sean-k-mooney this does not really fix anything
13:00:20 sean-k-mooney so its not really something i would backport
13:00:27 sean-k-mooney unless it help with a differnt issue

Earlier   Later