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