15:00:27 <bswartz> #startmeeting manila
15:00:27 <openstack> Meeting started Thu Jun 22 15:00:27 2017 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:30 <openstack> The meeting name has been set to 'manila'
15:00:30 <bswartz> hello all
15:00:34 <jprovazn> hi
15:00:36 <gouthamr> hi
15:00:37 <ganso> hello
15:00:37 <dustins> \o
15:00:42 <zhongjun> hello
15:00:44 <vponomaryov> hello
15:00:46 <markstur> hi
15:00:59 <tbarron> hi
15:01:03 <xyang1> Hi
15:01:03 <jungleboyj> o/
15:01:52 <bswartz> once again, no announcements this week
15:02:01 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:02:12 <bswartz> I wanted to start off today with
15:02:16 <bswartz> #topic IPv6 status
15:02:47 <bswartz> I have finally been able to shut out distractions and start to focus on this again
15:02:53 <cknight> Hi
15:02:54 <bswartz> I have 2 new LVM driver patches up
15:03:21 <bswartz> where do we stand on testing and implementation for ipv6?
15:03:28 <vkmc> o/
15:03:38 <bswartz> zhongjun: do you have a list of patches that are required?
15:03:48 <zhongjun> I have many patchs about IPv6 https://review.openstack.org/#/q/owner:jun.zhongjun2%2540gmail.com+status:open
15:04:23 <raissa> hi
15:04:35 <bswartz> #link https://review.openstack.org/#/c/406776/
15:04:40 <bswartz> #link https://review.openstack.org/#/c/312321/
15:04:45 <bswartz> #link https://review.openstack.org/#/c/328932/
15:04:51 <bswartz> ^ these are the ones I've been looking at
15:05:13 <zhongjun> First we need to focuse on this: https://review.openstack.org/#/c/406776/
15:05:31 <zhongjun> focus
15:06:11 <bswartz> what about https://review.openstack.org/#/c/476057/
15:07:06 <zhongjun> gate job: https://review.openstack.org/#/c/476057/
15:07:23 <bswartz> okay that can't merge until a bunch of other patches merge
15:07:29 <zhongjun> add ipv4 and ipv6  in lvm export ips config
15:07:31 <bswartz> but we should make it a priority for that to be able to pass
15:08:16 <bswartz> so everyone is still on board with the plan to have a single job for testing both ipv4 and ipv6 right? and centos will be required to actually turn on the v6 tests?
15:08:28 <tbarron> +1
15:08:45 <gouthamr> +1
15:08:53 <bswartz> okay
15:08:53 <zhongjun> We can test both ipv6 and ipv4 after merge gate job
15:09:34 <zhongjun> +1
15:09:44 <bswartz> the main thing left for me then is to add more unit tests coverage on my patch and get it merged so we can start merging zhongjun's stuff
15:10:26 <bswartz> I'm going to keep pushing for this to move quickly
15:10:36 <bswartz> we can't be still working on ipv6 at the end of p-3
15:10:56 <bswartz> anything else related to ipv6 that we should discuss today?
15:10:59 <zhongjun> agree
15:11:28 <bswartz> okay moving on...
15:11:29 <bswartz> #topic Driver fixes to branches beyond stable/R-1
15:11:42 <bswartz> gouthamr: you're up
15:11:54 <gouthamr> bswartz: thanks
15:12:20 <gouthamr> okay, we identified a few bugs in our drivers that go way back to many older releases
15:12:48 <gouthamr> but when we fix such bugs, backports to these fixes are only limited to ocata
15:13:25 <gouthamr> but i'd like to ideally backport them to newton too... but what stops me would be the backport policy around stable branches
15:13:42 <gouthamr> in cinder, i'm able to propose such backports to "driverfixes" branches
15:13:49 <tbarron> so this issue was discussed in cinder; do you have a solution for this issue in cinder?
15:13:51 <tbarron> jinx
15:14:06 <jungleboyj> tbarron:  Yes.
15:14:20 <jungleboyj> We have the driverfixes branch for each release.
15:14:20 <gouthamr> teh point being distributors are probably looking at those branches to pick up vendor driver fixes? (unsure)
15:14:23 <bswartz> +1 for driverfixes
15:14:39 <jungleboyj> gouthamr:  They should be.  The driver vendors are at least.
15:14:57 <gouthamr> jungleboyj: nice... so, can we start doing that in manila..
15:15:27 <jungleboyj> bswartz:  Gave it a plus 1.  :-)  Would make sense to keep Manila consistent if others agree.
15:15:50 <zhongjun> +1 It also good for me
15:16:06 <bswartz> "R-1" mean previous release, not Rocky milestone-1
15:16:20 <gouthamr> the community would need to sign up to maintain such branches.. and we'll run bitrot jobs on those like cinder does..
15:16:23 <gouthamr> haha happens just once in 26 times bswartz
15:16:30 <ganso> bswartz: thanks, that had gotten me confused
15:16:47 <tbarron> it seems like a good idea, I thought I'd ask how the cinder solution has been working out for our distro
15:16:51 <jprovazn> so vendors then cherry-pick from "driverfixes" whatever they need?
15:17:14 <jungleboyj> jprovazn:  Right.
15:17:22 <gouthamr> jprovazn: yes... vendors can propose fixes into those branches and its up to the distros from there on out..
15:17:28 <jungleboyj> tbarron:  That is a good question.  I wonder if the distros have been making use of it.
15:17:36 <tbarron> jprovazn: driver vendors would put their patches there; vendors would pull from there
15:17:44 <tbarron> distros would pull from there
15:18:06 <bswartz> jprovazn: the theory is that distros would follow that branch and see new patches merge -- distros can follow master today but it's harder to know which bug need backporting at all, and also backport some changes can be hard -- in the driverfixes branch all the merge conflicts would be dealt with already
15:18:20 <gouthamr> +1.. instead of each driver vendor maintaining their own manila forks someplace else
15:18:31 <bswartz> the major challenge is testing -- the branch would be officially untested
15:19:23 <bswartz> IIRC cinder just runs basic bitrot jobs on driverfixes
15:19:23 <gouthamr> untested with tempest tests...
15:19:24 <jungleboyj> bswartz:  Right.  We had to accept that.  The assumption is that the vendors are testing well if they are pushing up patches.
15:19:36 <ganso> pardon my ignorance but what does "bitrot jobs" mean?
15:19:43 <gouthamr> ganso: py27, unittests
15:19:44 <bswartz> well it would be between the distros and the vendors to assure quality
15:19:46 <tbarron> i think we supported this idea for cinder, i just want to check how it worked out, were there any unanticipated consequences, etc.
15:19:50 <ganso> gouthamr: oh, just that
15:19:53 <ganso> gouthamr: thanks
15:20:15 <zhongjun> so we don't need to run our CI too?
15:20:20 <jungleboyj> tbarron:  I am not aware of any.
15:20:20 <gouthamr> tbarron: eharney has had me push some changes into cinder's driverfixes branches ...
15:20:37 <bswartz> zhongjun:  IMO vendors could run CI if they chose too, or not
15:20:49 <tbarron> gouthamr: thanks, eharney is in another meeting right now and is ignorminng my PM on the subject :)
15:20:53 <tbarron> so +1
15:20:53 <bswartz> running CI on ancient releases is a challenge for a variety of reasons
15:21:16 <gouthamr> zhongjun: not a requirement, no.. we're assuming that someday devstack will stop supporting these old branches
15:21:23 <bswartz> distros happen to specialize at testing and supporting very old things (thanks RedHat/SUSE/etc)
15:21:24 <gouthamr> zhongjun: and most CIs run devstack
15:21:40 <xyang1> tbarron: eharney is probably already pulling fixes from Cinder driverfixes then
15:22:43 <bswartz> okay so the concrete actions proposed here are:
15:22:50 <jungleboyj> xyang1:  ++
15:23:11 <bswartz> * create the branch for newton (since ocata is still open)
15:23:23 <bswartz> * setup gate jobs
15:23:47 <bswartz> * announce that our policy for this branch will match cinder's current policy
15:24:00 <bswartz> is that all we need
15:24:02 <bswartz> ?
15:24:20 <gouthamr> +1
15:24:46 <vponomaryov> only newton?
15:24:47 <bswartz> and gouthamr is volunteering to the branch and gate stuff?
15:24:50 <vponomaryov> why not mitaka?
15:24:55 <bswartz> good point
15:25:00 <gouthamr> vponomaryov: i'd like to do mitaka too
15:25:02 <bswartz> why not mitaka?
15:25:09 <bswartz> what about liberty?
15:25:09 <jungleboyj> Makes sense.
15:25:16 <xyang1> Cinder has mistakable
15:25:22 <ganso> what about kilo? :P
15:25:25 <vponomaryov> bswartz: we have stable/mitaka, but not stable/liberty
15:25:42 <xyang1> Mitaka
15:25:43 <gouthamr> mistakable sounds good xyang1 :)
15:25:44 <vponomaryov> xyang1:"mistakable" ^_^
15:26:00 <xyang1> Autocomplete:)
15:26:04 <bswartz> vponomaryov: the proposal is that a driverfixes branch would be needed as soon as the stable branch became closed to non-critical bugfixes
15:26:14 <jungleboyj> @!
15:26:25 <bswartz> jungleboyj: looks like the bot isn't here
15:26:26 <gouthamr> table-flip-bot
15:26:32 <vponomaryov> bswartz: I see, I meant that we have some reference branch in that case
15:26:34 <jungleboyj> Awwww, no pewp bot
15:26:43 <gouthamr> he ded
15:26:53 <bswartz> probably just doesn't know about this channel
15:27:13 <jungleboyj> bswartz:  Also, should document that you are supporting this process.
15:27:24 <bswartz> vponomaryov: yes the driverfixes branch would always fork from the stable branch at whatever time the stable branch closes to non-critical bugfixes
15:27:36 <bswartz> jungleboyj: after the branches exist I'll do the announcement
15:27:44 <gouthamr> okay
15:27:53 <jungleboyj> bswartz:  Ok.
15:28:20 <gouthamr> #action: gouthamr will propose driverfixes/mitaka and driverfixes/newton branches and project-config changes to run bitrot jobs
15:28:31 <bswartz> and it's worth noting that critical bugfixes and security bugfixes should go into both the stable branch and the driverfixes branch as long as both branches are active
15:29:01 <bswartz> does cinder currently do this? ^
15:29:35 <jungleboyj> bswartz: Good point.  We should be doing that.  I need to make sure we are.
15:29:42 <jungleboyj> I will follow up on that.
15:29:44 <ganso> bswartz: the order of merging could diverge and cause cherry-picks into stable branches not suceed cleanly
15:29:56 <bswartz> ganso: yes
15:30:10 <bswartz> maintaining branches causes many issues
15:30:23 <bswartz> that would be the main argument against doing this exercise
15:30:32 <bswartz> but I think we believe the benefit is worth the cost
15:30:53 <ganso> bswartz: I guess we just gotta be extra careful... we don't rebase stuff on our repos/branches
15:31:28 <bswartz> anything else on this topic?
15:31:42 <bswartz> #topic Open Discussion
15:31:42 <gouthamr> nope..
15:31:47 <bswartz> any other topics for today?
15:31:51 <zhongjun> I have a simple one
15:32:11 <bswartz> yes?
15:32:12 <zhongjun> As we did it before, we just pop the parameter in old API version when we add a new parameter in API.  such as: we add  'is_public' in manage API.   Do we really need to raise BadRequest in old API?
15:32:12 <zhongjun> 22:45  such as: https://github.com/openstack/manila/blob/master/manila/api/v2/shares.py#L187
15:32:46 <vponomaryov> #link https://review.openstack.org/#/c/461712/29..32/manila/api/v2/shares.py
15:33:04 <vponomaryov> ^ this is the point of question
15:33:22 <zhongjun> Should we check, whether these keys are provided or not. If they are provided with old API , then need to raise "BadRequest"
15:33:51 <gouthamr> okay zhongjun: this is not a simple one
15:33:57 <vponomaryov> "these keys" are the ones that are supported by newer API and not supported by existing OLD one
15:34:25 <bswartz> do we have this problem because we're not rejecting extraneous inputs today?
15:34:31 <gouthamr> yes
15:34:44 <zhongjun> gouthamr: :) It could be a big change for API
15:34:51 <gouthamr> we have known for a while that sending invalid inputs doesn't blow up some of our APIs
15:34:51 <bswartz> I thought there was an effort some time back to validate requests and reject anything that doesn't strictly match what's allowed
15:35:02 <gouthamr> and for one, queries on all of our APIs
15:35:31 <gouthamr> you can send any filter key you want iirc and you'll not see 400 BadRequest
15:35:40 <gouthamr> vponomaryov: is that wrong? ^^
15:35:50 <bswartz> if there are places were we allow garbage input today, then the correct thing to do is to fix those places to throw errors and to microversion those changes
15:35:52 <vponomaryov> gouthamr: I consider it a bug, yes
15:36:20 <gouthamr> vponomaryov: then the fix needs to be generic.. i disagree that we add new query parameters and only disallow those in older versions
15:36:21 <bswartz> however for backwards compatibility, older microversions should continue to allow garbage
15:36:29 <vponomaryov> gouthamr: bug wiiiith looooong grey beard
15:36:53 <gouthamr> vponomaryov: and such a fix should begin at a new microversion
15:37:09 <xyang1> gouthamr: +1
15:37:36 <bswartz> we can be more nuanced here though
15:38:01 <bswartz> allowing garbage is only desirable if there is a conceivable reason such garbage would have been sent in an otherwise valid request
15:38:05 <vponomaryov> yes, big nuance is that we have keys that are supported in other microversions and common garbage
15:38:36 <bswartz> if the garbage indicates a broken client then it's probably kinder to actually generate an error and let the user know their client is broken
15:39:50 <bswartz> I'm trying to understand the change in question and the comments here: https://review.openstack.org/#/c/461712/29..32/manila/api/v2/shares.py
15:39:53 <gouthamr> (GIGO :) you can't stop all madness.. only some of it)
15:40:27 <zhongjun> gouthamr: +1 haha
15:40:40 <bswartz> gouthamr: as you know I have no problem breaking backwards compatibility when the old behaviour was clearly wrong
15:40:46 <gouthamr> okay, my point there being vponomaryov wanted older microversions to be changed for the query params: export_location_id and export_location_path
15:41:05 <bswartz> where we need to be careful is when we might break something that currently works fine
15:41:47 <zhongjun> We have many places now, do we need to fix it? if it is a bug
15:42:15 <bswartz> it's always a bug if we accept garbage
15:42:38 <bswartz> the question is whether to fix those bugs by disallowing the garbage always or only after a certain version
15:42:51 <gouthamr> bswartz: we used to accept, but ignore.. so zhongjun's previous patch just popped those out of the request dictionary
15:42:54 <zhongjun> ok, we always accept garbage ：）
15:43:14 <gouthamr> bswartz: so it maintained backwards compatible behavior that garbage will be ignored
15:43:32 <bswartz> okay that sounds like a good thing
15:43:43 <gouthamr> bswartz: i agree with vponomaryov that we should never ignore garbage (and we should throw it back at the requestor.. :P)
15:43:44 <bswartz> I'm still confused about who is arguing for what
15:44:21 <gouthamr> bswartz: but that fix should be from a new version.. :)
15:44:28 <bswartz> WHY IS THERE SO MUCH GARBAGE?!?
15:44:49 <bswartz> gouthamr: generally speaking, yes
15:44:51 <jungleboyj> We are a wasteful society.
15:44:51 <vponomaryov> I am ok with error'ing for garbage, but not making it a blocker for existing features
15:44:52 <zhongjun> May be we alway copy code
15:45:24 <vponomaryov> zhongjun: new API dir for new microversions? )))
15:45:29 <bswartz> zhongjun: are you clear on what you need to do?
15:45:49 <ganso> as long as old microversions still work for the parameters that weren't garbage before, I see no problem
15:45:49 <bswartz> I think this can be solved with an if statement
15:45:59 <zhongjun> bswartz: ok, just cleaning garbage from me
15:46:05 <ganso> btw
15:46:10 <bswartz> if version >= new version:
15:46:15 <ganso> I figured maybe a change like this could be worthy of v3
15:46:15 <bswartz> garbage is an error
15:46:27 <gouthamr> ganso: YOU EVIL YOU
15:46:40 <bswartz> v3 will be needed when we change the versioning scheme itself
15:46:41 <ganso> gouthamr: lol
15:46:59 <bswartz> until then we march towards 2.99999999999999999999999999
15:47:09 <vponomaryov> ganso: you tried ))
15:47:29 <ganso> vponomaryov: and failed
15:48:07 <bswartz> okay other topics?
15:48:30 <bswartz> I'm working on a new helper for NFS https://review.openstack.org/476239
15:49:09 <bswartz> it's not passing tests yet but I hope it will make things more reliable when its done
15:49:09 <gouthamr> dejavu
15:49:39 <gouthamr> bswartz: this is unrelated to teh ipv6 changes in LVM?
15:49:46 <tbarron> i like its size
15:49:55 <gouthamr> tbarron: heh, no unit tests
15:50:11 <bswartz> gouthamr: it's not strictly necessary, but I think it might be desirable
15:50:55 <bswartz> gouthamr:  unit tests after it passes functional tests
15:51:25 <bswartz> anyways I'll ask for reviews when that's actually working
15:51:29 <ganso> bswartz: it is clearly visible that you don't do TDD
15:52:12 <bswartz> ganso: that's true
15:52:16 <bswartz> I'm not trendy
15:52:41 <tbarron> gouthamr: it's about a third the size in functional code of what it replaces, let's see if it has the same functioinality
15:52:56 <tbarron> well, bswartz is a trendy dresser
15:53:02 <gouthamr> haha..
15:53:34 <bswartz> okay I think we're done
15:53:36 <bswartz> thanks all
15:53:40 <zhongjun> thanks
15:53:47 <bswartz> #endmeeting