15:00:17 <bswartz> #startmeeting manila
15:00:18 <openstack> Meeting started Thu Jul 13 15:00:17 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:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:21 <openstack> The meeting name has been set to 'manila'
15:00:25 <tbarron> hi
15:00:26 <cknight> Hi
15:00:27 <bswartz> hello all
15:00:28 <vponomaryov> hello
15:00:29 <dustins> \o
15:00:31 <jungleboyj> @!
15:00:31 <_pewp_> jungleboyj (=ﾟωﾟ)ﾉ
15:00:40 <markstur> hi
15:00:42 <bswartz> omg the bot is here
15:00:42 <ganso> hello
15:00:48 <gouthamr> hello o/
15:00:50 <jprovazn> hi
15:00:52 <gouthamr> hah!
15:00:56 <gouthamr> @!
15:00:56 <zhongjun> hi
15:00:56 <_pewp_> gouthamr (^-^*)/
15:01:28 <bswartz> #topic announcements
15:01:49 <bswartz> first, a reminder that the Pike feature proposal freeze is TODAY
15:02:32 <bswartz> so anything new after today will automatically get punted to queens
15:02:47 <bswartz> we have more than enough work left to wrap up pike....
15:03:12 <bswartz> and that's most of what I wanted to talk about today
15:03:18 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:03:28 <bswartz> #topic feature freeze
15:03:46 <bswartz> #link https://launchpad.net/manila/+milestone/pike-3
15:04:02 <bswartz> there's still a bunch of work that needs review for pike-3
15:04:12 <bswartz> I'm in the process of getting launchpad in shape
15:04:30 <toabctl> hi
15:04:38 <kaisers_> o/
15:04:40 <bswartz> if you see anything missing on launchpad pls notify me
15:05:25 <bswartz> I'm sure I didn't get everything yet, but I prefer using launchpad to track priorities so we know how close we are to being done
15:05:26 <jprovazn> bswartz, can you change "Add messages resource for sending errors to users" to "needs code review"?
15:05:38 <tbarron> jprovazn: +1
15:05:42 <bswartz> done
15:05:45 <jprovazn> thanks
15:05:56 <bswartz> IMO the IPv6 stuff looks good
15:06:24 <bswartz> I missed a flake8 check on my last patch but I'll sort that out shortly
15:06:39 <bswartz> I'd like to merge the LVM multi-IP patch, then the IPv6 core patches
15:06:56 <bswartz> there will be microversion conflicts of course
15:07:15 <bswartz> please stay on top of microversion-conflict-related rebases the next 2 weeks
15:07:23 <tbarron> yeah, agreeing on an order for stuff we expect to merge may help reduce thrash
15:07:28 <bswartz> they're annoying but unavoidable
15:07:37 <tbarron> I agree that the ipv6 stuff is very close
15:07:47 <zhongjun> +1
15:07:59 <ganso> tbarron: using constants makes rebase a lot easier
15:08:11 <tbarron> ganso: ack
15:08:14 <bswartz> ganso: what do you mean?
15:08:42 <ganso> bswartz: define a constant with your change's microversion and use it everywhere you would put your microversion
15:08:55 <bswartz> ganso: for example?
15:09:14 <ganso> bswartz: cknight did that with revert from snapshot patch
15:09:16 <bswartz> it sounds like a reasonable idea, but it would be tough to get it right for clients and tempest too
15:09:17 <tbarron> ganso: do you have a review with this "best practice" for us to look at
15:09:35 <ganso> tbarron: I'll look for it
15:10:10 <tbarron> that said, if we merge the ipv6 stuff, then can we do the next one on the list next, etc.
15:10:19 <tbarron> it may help to co-ordinate efforts
15:10:49 <tbarron> of course if a reviewer has blocking objections, then we move the item to the end of the list
15:11:05 <tbarron> but for nits and small issues keep the order the same
15:11:23 <tbarron> reduce brownian motion
15:12:30 <bswartz> looks like we might need to add an agenda topic based on the channel discussion
15:13:08 <bswartz> so I'm going to make another pass at the launchpad milestone blueprints and bugs
15:13:17 <jungleboyj> tbarron: ganso  Would like to see Cinder go that way too.
15:13:18 <bswartz> when I think it's complete I'll post something in the channel
15:13:29 <jungleboyj> Had a todo to push that but it fell off my plate.
15:13:48 <amito-infinidat> Hi, we're writing the Infinidat driver. Is it realistic to push it to Pike or will it have to wait for Queens?
15:13:48 <bswartz> anything else related to the feature freeze?
15:14:35 <bswartz> amito-infinidat: where is the patch?
15:14:47 <zhongjun> amito-infinidat: Could you give us a link?
15:14:57 <ganso> tbarron, bswartz, jungleboyj: https://github.com/openstack/manila/blob/master/manila_tempest_tests/common/constants.py#L60
15:15:15 <ganso> tbarron, bswartz, jungleboyj: although, my memory failed me, cknight did that only for tempest tests
15:15:33 <amito-infinidat> we will create a review today or tomorrow
15:15:33 <tbarron> ganso: ty
15:15:45 <bswartz> amito-infinidat: in that case you missed this deadline: https://releases.openstack.org/pike/schedule.html#p-manila-nddeadline
15:15:47 <xyang2> ganso: with this change, you still need to update the patch though, but it will be just one place
15:15:56 <ganso> tbarron, bswartz, jungleboyj: but the idea is great to be used in the server code and minimize rebase effort
15:16:14 <bswartz> amito-infinidat: we'll be happy to consider that driver for queens
15:16:14 <amito-infinidat> bswartz: ok, so queens it is.
15:16:47 <jungleboyj> ganso:  ++
15:17:19 <bswartz> okay let's move on
15:17:34 <bswartz> #topic driverfixes
15:17:48 <bswartz> gouthamr created the new branches for us
15:18:00 <zhongjun> bswartz: Could you tag two bps to pike-3 : link: https://blueprints.launchpad.net/manila/+spec/share-usage-size      https://blueprints.launchpad.net/manila/+spec/ensure-share
15:18:02 <bswartz> but everything seems to be failing
15:18:07 <gouthamr> https://review.openstack.org/#/c/482785/ needs to merge
15:19:16 <bswartz> gouthamr: looks like someone forgot to his the workflow button
15:19:24 <bswartz> maybe we should poke the infra team
15:19:51 <gouthamr> bswartz: yep will do
15:20:03 <xyang2> bswartz: maybe they are waiting for you the PTL to +1 before +A?
15:20:43 <bswartz> xyang2: good point I added my +1
15:20:49 <vponomaryov> xyang2: no, it was required for branches creation
15:21:20 <bswartz> anyways once those branches are functioning we'll open them up to bug backports
15:21:33 <bswartz> gouthamr: as far as you know are any ACL changes needed?
15:21:49 <bswartz> who has power to +W stuff to driverfixes?
15:22:06 <gouthamr> bswartz: not that i know about... all core reviewers have +2/+W : should it be only manila-stable-maint, or something like that?
15:22:22 <bswartz> well
15:22:33 <bswartz> it *should* just be manila-stable-maint, but we need to add people to that group
15:22:37 <xyang2> in cinder. all cores have +2/+w power on driver fixes branch
15:23:31 <bswartz> the theory is that the members of the stable-maint group have a good track record of approving appropriate backports and rejecting inappapropriate backports
15:23:44 <bswartz> the same logic would apply to driverfixes
15:24:42 <bswartz> gouthamr: do you want to push an ACL update or should I?
15:25:03 <bswartz> I can also take this as a reminder to add members to manila-stable-maint
15:25:03 <gouthamr> bswartz: you can if you already know where it is
15:25:11 <jungleboyj> xyang2:  Is it everyone?
15:25:16 <bswartz> #action bswartz add ppl to manila-stable-maint
15:25:24 <bswartz> #action bswartz update ACLs for driverfixes
15:25:24 <jungleboyj> xyang2:  We didn't limit it to stable-maint?
15:25:44 <xyang2> jungleboyj: now you make me wonder.  let me check.:)
15:25:50 <gouthamr> bswartz: also, should third party CIs run on the driverfixes branches?
15:25:57 <gouthamr> bswartz: devstack can likely be broken, so, i think not.
15:26:19 <jungleboyj> gouthamr:  No, the shouldn't.
15:26:27 <bswartz> gouthamr: I think it would be recommended but not required
15:27:01 <bswartz> if you're not testing your changes then nobody will have confidence in them
15:27:12 <gouthamr> afais, vendor driver fixes must be limited to their driver and they should attest that it's qualified downstream, because we don't run tempest tests upstream..
15:27:21 <bswartz> but it's understood that testing obsolete branches is harder
15:28:31 <bswartz> anything else on driverfixes
15:28:32 <bswartz> ?
15:28:41 <gouthamr> nope... nothing from me
15:28:44 <tbarron> gouthamr: thanks
15:28:54 <gouthamr> once we fix the jenkins issues, i will update
15:29:11 <bswartz> #topic docs migration
15:29:32 <bswartz> so those of you reading the ML are aware of the effort to migrate docs
15:30:10 <bswartz> evidently it's related to the docs team having reduced resources
15:30:22 <tbarron> we were ahead of our time with our local docs :D
15:30:34 <jungleboyj> tbarron:  You lucky dogs!
15:30:55 <tbarron> jungleboyj: well, we still have to move the official stuff
15:30:56 <bswartz> well isn't there anything left to do?
15:31:18 <tbarron> bswartz: I was (mostly) joking.
15:31:22 <gouthamr> there is.. we have to move admin docs
15:31:24 <bswartz> I'm looking for a volunteer to work on this
15:31:26 <gouthamr> and CLI docs
15:31:41 <bswartz> where would we move the CLI docs to?
15:31:48 <bswartz> to python-manilaclient?
15:31:50 <gouthamr> and config ref (?)
15:32:06 <zhongjun> and driver config docs?
15:32:22 <jungleboyj> bswartz:  Yes, that is where the cli docs are supposed to go.
15:32:22 <tbarron> jungleboyj: didn't you do this for cinder?
15:32:33 <jungleboyj> tbarron:  I am in the process of doing it.
15:33:10 <gouthamr> #link: https://review.openstack.org/#/c/472275/
15:33:36 <tbarron> what is the deadline?
15:33:41 <jungleboyj> tbarron:  Trying to hint I could do it for Manila as well?
15:33:46 <jungleboyj> Needs to be done in Pike.
15:34:08 <tbarron> jungleboyj: maybe I can just look at each of your patches and make a corresponding one for manila then
15:34:19 <bswartz> it might happen very late in Pike for Manila
15:34:28 <zhongjun> jungleboyj: Pike l3 or  later?
15:34:42 <tbarron> bswartz: all NOTE that cinder has agreed that the 'move doc' patches don't have to *fix any content*
15:34:46 <bswartz> jungleboyj: if you don't want to work on it for manila maybe you can give advice to whoever does do it
15:34:58 <jungleboyj> zhongjun:  Before code freeze.
15:35:04 <tbarron> so no -1s and nitpicks on content, or fix this while you are in there
15:35:12 <jungleboyj> tbarron:  ++
15:35:17 * gouthamr tbarron: uh-uh, noway
15:35:23 <bswartz> jungleboyj: the P-3 milestone?
15:35:23 <gouthamr> :P
15:35:38 <tbarron> jungleboyj: is the before code freeze an OpenStack requirement or a cinder goal?
15:35:39 <jungleboyj> This is just to get the move.
15:35:47 <bswartz> that's unfortunately close and conflicts with stuff we actually care about
15:36:11 <jungleboyj> tbarron:  Well, the docs are gone from the web right now.
15:36:11 <bswartz> why not do it after the milestone?
15:36:22 <jungleboyj> Oh, you know what ...
15:36:41 <jungleboyj> These get published independent of a milestone I think.
15:36:51 <jungleboyj> So maybe code freeze doesn't matter.
15:36:58 <bswartz> I would rather do it around the RC1 timeframe
15:37:01 <xyang2> jungleboyj, bswartz: so I can +2/+A on cinder's driver fixes branch but I'm not a stable maintenance core: https://review.openstack.org/#/c/464311/
15:37:11 <bswartz> that's the traditional time for us to switch focus to docs problems
15:37:25 <jungleboyj> The docs meeting is right after this.  I will get clarification.
15:37:55 <bswartz> okay I just wanted to call attention to this community wide goal
15:38:14 <bswartz> okay let me sneak in some topics not on the agenda
15:38:23 <bswartz> #topic bug squash day
15:38:29 <jungleboyj> tbarron:  So are you going to look at doing the migration?
15:38:59 <bswartz> we discussed this 2 weeks ago and there was interest but nobody has indicated what times wouldn't work for them
15:39:00 <tbarron> jungleboyj: i am happy to copy your fine work if I don't have to do it for P-3
15:39:30 <jungleboyj> Ok.  I will get clarification on the timing.  Am here to support.
15:40:07 <bswartz> tbarron: yeah I think we'll all be too busy to do it before P-3 -- if there's a deadline then we will probably miss it
15:40:33 <bswartz> regarding bug squash day, I'd like to propose R-4 (the first week in August)
15:41:04 <bswartz> I know that's likely to conflict with people's vacations, but the backend of pike is fairly compressed
15:41:19 <tbarron> bswartz: unfort I have company meetings all that week but that shouldn't block others
15:41:22 <bswartz> the only realistic alternative would be R-3
15:41:42 <bswartz> but that's even more likely to conflict with vacations
15:42:27 <bswartz> so I hear tbarron is out for R-4
15:42:46 <bswartz> anyone else have a strong opinion for when we should plan a bug squash day?
15:42:57 <bswartz> the other question would be what day of the week
15:43:07 <bswartz> I would avoid monday and friday
15:43:30 <bswartz> maybe Wednesday is a good day for it?
15:43:34 <tbarron> bswartz: wait, r-4 is july 31-aug 4, it's r3 that I have to travel
15:43:48 <bswartz> so August 2 or August 9
15:44:15 <bswartz> August 2 would be better
15:44:28 <bswartz> and if that works for tbarron and nobody else objects, I'd like to just schedule it today
15:44:45 <tbarron> bswartz: +1
15:44:54 <bswartz> #link https://releases.openstack.org/pike/schedule.html
15:45:44 <bswartz> alright put manila bug squash on your calendars for August 2nd
15:46:12 <bswartz> #topic per-share-type quotas
15:46:28 <tbarron> hee hee
15:46:29 <bswartz> #link https://review.openstack.org/#/c/452158/
15:46:40 <bswartz> #link https://review.openstack.org/#/c/452158/32/manila/api/v2/quota_sets.py@84
15:46:57 <bswartz> what's going on here
15:47:03 <bswartz> gouthamr vponomaryov
15:47:35 <vponomaryov> bswartz: gouthamr proposed me to change API behaviour and I disagree with it
15:47:41 * tbarron imagines bswartz as ward cleaver
15:47:50 <gouthamr> the conversation is here: https://review.openstack.org/#/c/473464/11/manila/api/v2/quota_sets.py
15:48:02 <ganso> tbarron: lol
15:48:03 <bswartz> vponomaryov: what is the choice that needs to be made?
15:48:11 <bswartz> whether to modify old API behavior or not?
15:48:25 <zhongjun> It looks like we meet the same problem before ( export location feature)
15:48:28 <bswartz> tbarron: sorry I didn't watch that show
15:48:37 <vponomaryov> bswartz: it is related to "drop-garbage-by-default" approach we have in API
15:48:47 <gouthamr> so the patch modifies old APIs for the new quota set key
15:49:04 <gouthamr> if you use the new quota set on old APIs you get a 400
15:49:10 <bswartz> so the patch could theoretically break backwards compatibility, right?
15:49:15 <vponomaryov> bswartz: new change updates old APi to explicitly say that "new keys" are not allowed with old API
15:49:24 <bswartz> but in practice, would it?
15:49:51 <gouthamr> my problem was with special casing
15:49:53 <bswartz> I'm less concerned about theoretical backwards compatibility issues than real ones
15:49:59 <gouthamr> as zhongjun mentioned, we handled this in both the export_locations_filter and the "like" filter that she added
15:50:10 <vponomaryov> bswartz: keeping old behaviour will mean following: operator will provide new keys with old API and will get answer, not knowing it was not applied
15:50:19 <bswartz> that's why I take a strong stance that bugfixes shouldn't be microversioned unless the old behavior was desirable in some way
15:50:46 <vponomaryov> bswartz: so, yes, it is part of fixing "drop-garbage-by-default" approach
15:51:03 <zhongjun> yes, we discussed it in last meeting
15:51:06 <vponomaryov> that should have been done tillnow
15:51:26 <bswartz> so I'm leaning towards supporting vponomaryov's patch as is
15:51:37 <bswartz> gouthamr: explain the harm with this approach
15:51:56 <gouthamr> why apply special case fixes every time we introduce a new feature?
15:52:20 <vponomaryov> gouthamr: because we don't drop garbage now
15:52:21 <bswartz> gouthamr: you'd prefer that the change be to to reject ALL unsupported arguments?
15:52:22 <gouthamr> i agree we were consuming garbage and ignoring it, which is very confusing
15:52:26 <gouthamr> bswartz: yes
15:52:29 <vponomaryov> gouthamr: itis driven by technical debt
15:52:33 <bswartz> yeah I'd prefer that too...
15:52:35 <zhongjun> bswartz:  In last meeting, we agree with open a new bug to change this behavior and add microversion
15:52:40 <gouthamr> bswartz: at a new microversion, we can prevent sending garbage keys
15:52:42 <bswartz> still I don't see why that's related to this
15:52:51 <gouthamr> for now, just pop the key and log it if you must
15:52:56 <gouthamr> it's an admin API
15:53:25 <gouthamr> if you send a 400, you'll only confuse consumers..
15:53:30 <bswartz> it's an admin API but vponomaryov has a good point that admins could easily make a request and get confusing results
15:54:23 <bswartz> this would be a non-issue if we were rejecting garbage originally
15:54:28 <gouthamr> yes
15:54:31 <vponomaryov> gouthamr: as bswartz mentuioned, we should not keep backwards compat with "bugs"
15:55:20 <bswartz> vponomaryov: would you consider modifying your patch to reject all garbage starting with the new microversion? or would that be siginificant extra work?
15:55:52 <vponomaryov> bswartz: I would say that it should be done separately
15:55:56 <vponomaryov> bswartz: not in this patch
15:56:01 <bswartz> I don't want to block this patch on a minor issue like this, but if we split out the change and create an additional microversion then it's even more confusing
15:56:17 <vponomaryov> bswartz: here, I considered operator use case beforehand
15:56:34 <bswartz> vponomaryov: if we do it separately, would that other change be microversioned, or would it be retroactive?
15:57:15 <vponomaryov> bswartz: since, it will be bugfix that changes old behaviour...
15:57:38 <bswartz> you'd want to affect all old microversions?
15:57:59 <bswartz> my concern if we do it that way is that there might be legitimate backwards compatibility problems
15:57:59 <vponomaryov> bswartz: I don't have strong opinion on this
15:58:33 <gouthamr> changing 2xx to 4xx: reason for a microversion bump..
15:58:55 <bswartz> well I think we've agreed that this needs fixing, but nobody has time to work on that and it's not a good enough reason to block this new feature
15:59:50 <gouthamr> i don't mind committing this change in another patchset
15:59:56 <bswartz> I'm in favor of merging the feature as it, and then separately changing the API to start rejecting garbage, possibly only after some microversion or possibly retroactively (need to think about specific cases where backwards compatibility would be broken)
16:00:07 <vponomaryov> bswartz: only on restricting "valid keys" from new microversions on OLD ones
16:00:28 <bswartz> can everyone live with that?
16:00:51 <bswartz> we're out of time so please raise your objections in the channel
16:00:57 <bswartz> thanks everyone
16:01:02 <bswartz> #endmeeting