Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-06-04
16:37:26 bauzas you're saying you would get the detail from the cinder connection info
16:37:31 bauzas do we already have that ?
16:37:53 sean-k-mooney if we add a new compute service version for this and a min compute service version check i think that woudl resolve most if not all the upgrade concerns
16:38:07 marlinc Yes so we have an internal Cinder driver for our own storage platform which does give that property in the cinder connection info, we didn't have change anything in Cinder itself
16:38:12 bauzas I would honestly then recommend to write a spec
16:38:26 sean-k-mooney marlinc: is there an upstream driver that support this
16:38:31 bauzas there could be some upgrade and compatibility concerns I may see
16:38:36 sean-k-mooney marlinc: without that we can proceed with this in nova
16:38:47 sean-k-mooney we do not add supprot for out of tree drivers in other project
16:38:49 marlinc No there is currently no upstream driver that has this
16:39:12 bauzas then we can't just modify nova to blindly check anything that's not upstream
16:39:22 sean-k-mooney so implementing this in the lvm or a diffent intree cinder driver would likely be a requirement if we did this for cinder only
16:39:29 bauzas spec it is
16:39:49 bauzas and I guess you probably need to discuss that with the cinder folks
16:40:24 marlinc Oke I will look into creating a spec and also see if I can get this implemented in a in-tree driver
16:41:13 bauzas thanks
16:41:26 bauzas ping me anytime if you require assistance on the paperwork process
16:41:27 marlinc I'm going to have to see how to implement the min compute service version check and bump
16:41:42 sean-k-mooney marlinc: i would proably add it to the lvm driver personally, i think it woudl be relvitly simple to do
16:41:58 bauzas before doing anything with version checks, please check with the cinder folks about populating the rotation rate into the connection info details
16:42:14 bauzas yeah, lvm seems the easiast approach
16:42:25 marlinc (Also actually the functional test for live migration, honestly I have never implemented something so complex as I have no experience at all with the testing framework and how it works in Nova)
16:42:26 bauzas but that's not my own garden :)
16:42:48 marlinc Especially since there is no existing volume based live migration functional I could see
16:42:54 bauzas marlinc: once you get a go from the cinder folks about exposing the rotation rate, come to me
16:43:03 sean-k-mooney marlinc: if cinder accpet the enhancement we can revisit that and or help you with that
16:43:07 marlinc Alright
16:43:20 bauzas cool
16:43:23 bauzas moving on then
16:43:26 marlinc Thank you, I'll update our internal ticket
16:43:44 bauzas marlinc: I assume you know how to reach the cinder folks?
16:44:36 marlinc Well, I'm going to assume #openstack-cinder and I'll check their contribution documentation
16:44:39 bauzas I have no potential design disapproval on using a specific connection info detail for setting the right value in the xml
16:45:00 sean-k-mooney marlinc: yep thats the correct channel
16:45:05 bauzas but you'll need to write a nova spec for explaining that it'll require a recent enough cinder and new computes
16:45:19 sean-k-mooney by the way there may be a usecase here for nova local storage too.
16:45:22 marlinc I was maybe a bit afraid though about the special rotation_rate 1 that is libvirt specific
16:45:23 bauzas and testing will be interesting to be discussed in the spec proocess
16:45:40 marlinc But that is probably something for the spec
16:45:52 bauzas the rotation rate is storage specific
16:46:07 bauzas how you tune it for the guest is libvirt specific indeed
16:46:34 marlinc That is why, right now we return rotation_rate 1 for SSDs, however that might not be smart from a cinder -> nova integration perspective
16:46:42 marlinc It is a magic value
16:46:56 sean-k-mooney well really your tryign to say "this is an ssd" or not
16:46:58 bauzas we're overtime and we still have two topics to discuss
16:47:05 sean-k-mooney afnd there may be better way to express that
16:47:15 bauzas but I think we may need to discuss that from a cross-project perspective
16:47:19 sean-k-mooney ya lets continue this converatoin after the meeting
16:47:23 marlinc Yes that is right now the primary use case though we also use it to set it to 7200 for HDDs
16:47:32 marlinc Alright thank you
16:47:38 bauzas next one then (3 of 4)
16:47:45 bauzas Luzi: floating ip behavior (assign fip: https://bugs.launchpad.net/neutron/+bug/2060808 , remove fip: https://bugs.launchpad.net/nova/+bug/2060812)
16:47:47 Luzi these two bugs describe changes with the neutron handling of floating ips (compared to the deprecated nova code). 1. one allows allocating a floating ip to a vm even if it is attached to another vm ("stealing" it). The 2. one does not check the VM when removing a floating ip, resulting in always removing the ip (even if the vm-name was correct, and the ip a mistake)
16:48:17 bauzas are you asking for reviews on the nova patch ?
16:48:24 Luzi I raised that at the PTG with Neutron, but they wanted Nova poeple to look over it, and tell, whether you want to change these bahaviors or not
16:48:33 bauzas oh my bad
16:49:08 Luzi (i normally don't have time to attend the Nova meetings)
16:49:31 Luzi I would be glad if you could check out these bugs again and give your input on it
16:49:56 bauzas Luzi: well, it's hard to comment those bugs on a limited timeframe
16:50:09 Luzi yeah, we can discuss this on launchpad also
16:50:11 bauzas could you please go back to the nova channel on another time ?
16:50:15 Luzi sure
16:50:31 bauzas Luzi: well, what's your timezone, please remind me ?
16:50:39 Luzi UTC-1
16:51:09 bauzas okay, would that work if you would ping us again on tomorrow UTC afternoon ?
16:51:34 Luzi yeah i can do taht
16:51:43 bauzas thanks
16:52:01 bauzas last one
16:52:05 bauzas kgube: re-proposed extend volume completion spec: https://review.opendev.org/c/openstack/nova-specs/+/917133
16:52:12 kgube Hi, this is just a review request
16:52:27 bauzas cool, we'll review all the proposed specs indeed
16:52:40 kgube The spec has been reproposed from last cycle and not much has changed
16:52:49 bauzas I think I need to remember the exact situation we had last cycle
16:53:06 bauzas and why this didn't get enough traction
16:53:18 bauzas I think we were basically awaiting cinder's feedback, right?
16:53:21 kgube The cinder dependencies had to get merged
16:53:31 bauzas yah that
16:53:42 bauzas and the cinder spec was accepted ?
16:53:47 kgube but cinderclient now supports the feature
16:54:05 bauzas okay, so where are we exactly on the cinder side ?
16:54:17 bauzas everything eventually got merged ?
16:54:46 kgube well, there are some cinder changes left, but they depend on the nova change again
16:54:55 bauzas yeah
16:54:58 bauzas I remember that
16:55:09 bauzas but okay, that's on our plate now
16:55:21 bauzas I'll then review the spec reproposal
16:55:27 sean-k-mooney they depend on https://review.opendev.org/c/openstack/nova/+/873560 right
16:55:28 kgube thanks!
16:55:38 sean-k-mooney which was waiting for the cinder client release
16:55:42 sean-k-mooney which has now happened
16:55:42 bauzas yeah
16:55:46 bauzas exactly
16:56:00 sean-k-mooney ok then if that can be rebased
16:56:05 bauzas I don't see anything controversial but I'll just doublecheck
16:56:09 kgube yeah, i still need to fix the build for this
16:56:12 sean-k-mooney we can review and then cidner can complete the rest
16:56:14 bauzas before blindly reapproving
16:56:36 bauzas cool
16:56:49 bauzas I think the dust has settled then
16:57:03 bauzas are we good with wrapping up the meeting then ?

Earlier   Later