Earlier  
Posted Nick Remark
#openstack-nova - 2022-07-05
16:33:58 sean-k-mooney main issue is reloading context i have not worked on it since febuary
16:34:02 bauzas me too
16:34:23 bauzas but, given Berlin, I think this would be a net win to have it in Nova
16:34:29 sean-k-mooney Uggla's spec i think is close it have one issue with it but it could be adressed in a followup
16:34:35 bauzas cool
16:34:42 bauzas let's wrap on the spec discussion
16:34:50 bauzas I'll need to leave the chair soon
16:34:55 bauzas and we can follow up tomorrow
16:35:03 bauzas #topic Review priorities
16:35:09 bauzas #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+label:Review-Priority%252B1
16:35:25 bauzas #link https://review.opendev.org/c/openstack/project-config/+/837595 Gerrit policy for Review-prio contributors flag. Waiting for approval
16:35:53 bauzas we should ping the project-config cores
16:36:05 bauzas #link https://docs.openstack.org/nova/latest/contributor/process.html#what-the-review-priority-label-in-gerrit-are-use-for Documentation we already have
16:36:16 sean-k-mooney i can do that after the meeting
16:36:20 bauzas thanks
16:36:32 bauzas #topic Stable Branches
16:36:34 bauzas elodilles: your time
16:36:43 elodilles #info stable nova releases are out: yoga (25.0.1), xena (24.1.1) and wallaby (24.1.1)
16:36:51 elodilles #info stable/train is blocked, fix exists but hasn't merged yet due to intermittent failures
16:37:05 elodilles #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:37:14 elodilles that's it, to be quick
16:37:37 bauzas thanks
16:38:02 bauzas elodilles: as again, don't be afraid of pinging me for reviews
16:38:06 bauzas #topic Open discussion
16:38:11 bauzas (bauzas) Team Sign-up for the next PTG
16:38:15 bauzas so, official ask
16:38:16 gibi yes please
16:38:23 gibi :)
16:38:31 bauzas should we have a PTG room ?
16:38:39 bauzas which would be physical this time ?
16:38:46 bauzas :)
16:38:47 gibi can we have a window on the room? :)
16:38:57 bauzas I don't know the logistics yet
16:39:16 bauzas I can imagine the Foundation asking the teams to be agile and proposing some remote live connection
16:39:23 sean-k-mooney i would be happy with one in dark basment if it has white bords
16:40:00 sean-k-mooney yes if we have an ok netowrk
16:40:04 bauzas there is a remarks/feedback field in the survey
16:40:05 sean-k-mooney we can likely have a remote stream too
16:40:07 bauzas https://openinfrafoundation.formstack.com/forms/oct2022_ptg_team_signup
16:40:13 bauzas I'll fill it up
16:40:22 bauzas but I could mention those two things
16:40:27 gibi to stream it we need mics and optional a camera
16:40:42 sean-k-mooney yep neutron have done that in the past
16:40:45 bauzas yeah and everytime we tried, this was a hard experience
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

Earlier   Later