15:02:42 <bswartz> #startmeeting manila
15:02:42 <openstack> Meeting started Thu May  5 15:02:42 2016 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:46 <gouthamr> hello o/
15:02:47 <openstack> The meeting name has been set to 'manila'
15:02:48 <bswartz> hello all
15:02:48 <tbarron> hi
15:02:49 <ganso> hello
15:02:50 <aovchinnikov> hi
15:02:53 <jseiler__> hi
15:02:56 <dustins> \o
15:02:57 <vponomaryov> hello
15:03:00 <tpsilva> hello
15:03:01 <markstur_> hi
15:03:02 <bswartz> sorry I'm late - was composing ML post
15:03:20 <xyang1> hi
15:03:31 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:03:32 <zhongjun_> hi
15:03:34 <rraja> hi
15:03:54 <bswartz> so the agenda is funny today
15:04:04 <bswartz> we had a long list of topics for Austin which we simply ran out of time to cover
15:04:23 <bswartz> I've taken the items we didn't get to and put them into the meeting agenda
15:04:40 <bswartz> we don't get to all of them, but I hope to cover a few of them today, and eventually cover all of them
15:05:10 <bswartz> #topic Documentation update
15:05:20 <bswartz> dustins: go ahead
15:05:29 <dustins> thanks, bswartz
15:05:54 <dustins> So gouthamr and I have started going though the driver interface and tidying it up
15:06:27 <dustins> And it sounds like we have a volunteer for looking at the errors and warnings for the in-tree docs
15:06:40 <dustins> As well as for the API Reference reworking
15:07:04 <dustins> gouthamr is tackling the creation of the Docs topic branch in Gerrit for all of our efforts
15:07:16 <bswartz> the API Ref rework should be largely mechanical though right?
15:07:25 <dustins> And I'm going to have a gander at the CLI Reference when I get the chance
15:07:26 <gouthamr> bswartz: mostly
15:07:28 <dustins> Yes
15:07:39 <bswartz> we've just converting the format and moving them, no rewriting the content
15:07:47 <gouthamr> bswartz: yep
15:08:10 <gouthamr> ofcourse, there are gaps.. share migration and replication APIs need documentation..
15:08:29 <dustins> we're keeping track of all of our efforts/volunteers/etc through the etherpad we showed at the Summit
15:08:36 <gouthamr> we'll adopt RST and then work on those gaps
15:08:40 <bswartz> gouthamr: what happened to the replication API ref we wrote for mitaka?
15:08:41 <gouthamr> #link #link https://etherpad.openstack.org/p/manila-docs-improvement-newton
15:09:26 <gouthamr> bswartz: was halfway through it, learning my way through docbooks and stuff, and then the docs team brought up the rework..
15:09:34 <bswartz> I see
15:09:37 <gouthamr> bswartz: we'll get that in as part of the rework
15:09:40 <dgonzalez> so i volunteered to do the api-ref stuff. Should i put my name somewhere in the etherpad?
15:09:41 <bswartz> so that work is still TBD
15:09:51 <gouthamr> dgonzalez: i did that for you :)
15:09:58 <dustins> dgonzalez: I think we've got you in there :D
15:09:59 <dgonzalez> gouthamr: a thanks :)
15:10:02 <bswartz> dgonzalez: thanks for volunteering to help
15:10:19 <gouthamr> yes, thank you dgonzalez
15:10:30 <dgonzalez> no problem, glad to help :)
15:10:31 <gouthamr> As you can see on the etherpad though... we're looking for more volunteers
15:11:19 <gouthamr> So, please help out..
15:11:35 <gouthamr> we need to scrub through docs, find gaps and fill them in
15:11:43 <dustins> There's a lot to do, and not a lot of time to do it
15:12:12 <bswartz> dustins: what's driving the deadline here?
15:12:20 <dustins> Newton :)
15:12:23 <gouthamr> bswartz: Newton! :)
15:12:49 <gouthamr> lol. this is a major factor for our project maturity stats.. we hope to catch up on those numbers in newton
15:13:00 <bswartz> but specifically, the doc team has a plan to relocate the api refs within newton, correct?
15:13:09 <gouthamr> bswartz: yes..
15:13:18 <bswartz> they could change their plans if they wanted to, or we could do something else less compliant if we wanted to
15:13:19 <gouthamr> bswartz: not just the api-ref, but the install-guide as well
15:13:32 <bswartz> okay
15:13:53 <gouthamr> for those interested in maturity stats - https://www.openstack.org/software/project-navigator/
15:14:05 <bswartz> clearly we want to follow the docs team's guidelines, but we should avoid letting that generate a huge pile of work
15:14:17 <bswartz> I don't like the idea of rewriting docs which were already written
15:14:43 <gouthamr> bswartz: +1 no rewrites, mostly update, fill gaps
15:14:51 <bswartz> anything else?
15:14:56 <gouthamr> yes
15:14:57 <dustins> I'm good
15:15:13 * dustins passes the ball to gouthamr
15:15:25 <gouthamr> I would like to emphasize that configref has to be kept up-to-date
15:15:34 <bswartz> ah yes
15:15:36 <gouthamr> and this is the responsibility of driver maintainers
15:16:02 <bswartz> well the driver portion of the config ref has to be the responsibility of driver maintainers
15:16:17 <dustins> We will help out with this, but ultimately it is the responsibility of the driver maintainers
15:16:19 <gouthamr> bswartz: +1
15:16:37 <bswartz> I also want to see the "compatibility matrix" disappear from the devref and be replaced with appropriate information in the config ref
15:17:17 <bswartz> I think one person could do the initial transplant, but then the maintenance of that going forward would need to be handled by driver maintianers
15:17:56 <bswartz> does anyone have an issue with that plan?
15:18:08 <vponomaryov> not only driver maintainers
15:18:15 <vponomaryov> we also have manila-wide options
15:18:30 <bswartz> vponomaryov: yes that's what I was referring to above
15:18:48 <bswartz> the manila options part of the config ref should be maintained by this team
15:19:25 <bswartz> okay I think we can move on...
15:19:44 <bswartz> I'm going to jump ahead because I don't understand this agenda item
15:19:49 <bswartz> #topic BP Specs
15:19:58 <bswartz> tbarron: can you explain this a bit more?
15:20:22 <tbarron> Now we have bp specs.  We need to evolve a culture
15:20:32 <tbarron> where they work effectively.  I just
15:20:35 <bswartz> tbarron: you mean the specs repo?
15:20:37 * gouthamr smiles away
15:20:42 <tbarron> yes
15:20:43 <vponomaryov> why we cannot use wiki?
15:20:47 <bswartz> okay so some updates about that
15:20:57 <tbarron> I just wanted to call attention to that email about
15:21:03 <bswartz> the specs repo is created, but the skeleton isn't merged yet, so please don't add any specs yet
15:21:14 <tbarron> how the perils some other projects have run into.
15:21:19 <bswartz> the ML post I'm composing is about the unclear licensing for the specs repo
15:21:37 <bswartz> but yes, we do need to discuss the specs repo and how it should be used
15:22:04 <tbarron> from my POV we don't need a long discussion on that aspect today.
15:22:18 <bswartz> so if people show up and write a spec without intending to write code, I will be very upset
15:22:21 <tbarron> but that email was posted today and it seemed timely.
15:23:41 <bswartz> In can be very helpful to have problems in need of solutions described clearly in spec-format, but when you put it in the manila-specs repo, you're asking the core team to review your spec -- and we do that review under the assumption that an implementation will be forthcoming
15:24:02 <bswartz> so if you wand to write specs and not implement them, please put them somewhere else
15:24:33 <vponomaryov> bswartz; each spec has assignee
15:24:46 <vponomaryov> bswartz: so one writes spec, other develops
15:24:53 <bswartz> there are lots of ways the specs repo could end up going wrong -- I've outlined a few of them before
15:25:01 <bswartz> and this ML post outlines some more of them
15:25:34 <bswartz> vponomaryov: yes -- as long as the assignee will work on it in the release for which the spec is submitted, I think that's fine
15:26:13 <bswartz> thanks for the link tbarron
15:26:23 <tbarron> np
15:26:30 <bswartz> I like the swift suggestions for an "ideas" wiki where people who have ideas can propose them
15:26:45 <bswartz> the specs repo is not an idea dumping bucket
15:26:52 <tbarron> +1
15:27:10 <bswartz> okay is ameade around by any change?
15:27:13 <bswartz> chance*
15:27:20 <ameade> sorta
15:27:31 <ganso> bswartz: the gerrit for the specs repo may be
15:27:39 <xyang1> bswartz: did mike say wiki will go away?
15:27:43 <ganso> bswartz: but once approved, the idea should be developed :)
15:27:44 * tbarron passes ameade some coffee
15:27:49 <bswartz> ameade: user messages?
15:28:00 <ameade> for manila? yessir
15:28:03 <bswartz> #topic User messages
15:28:21 <bswartz> we weren't able to cover this in austin
15:28:25 <ameade> lets port over user messages from cinder
15:28:44 <bswartz> ameade: how far along is that effort?
15:28:50 <ameade> merged
15:28:57 <bswartz> cool
15:29:00 <vponomaryov> ameade: any link?
15:29:01 <tbarron> ameade: +1
15:29:30 <ameade> #link https://review.openstack.org/#/c/298052/
15:29:33 <bswartz> xyang1: who is mike?
15:29:38 <ameade> devref change is most useful
15:29:42 <xyang1> bswartz: thingee
15:29:42 <vponomaryov> ameade: ty
15:29:50 <bswartz> I hope the wiki doesn't go away
15:30:04 <bswartz> I didn't heard about that
15:30:07 <ameade> i can port this today
15:30:22 <ameade> if we are cool with taking the exact same changes
15:30:25 <xyang1> bswartz: alright I don't remember details, better not to spread rumors
15:30:28 <ameade> then we can extrapolate into oslo soon
15:30:34 <ameade> because glance is interested
15:30:56 <bswartz> ameade: why not put it in oslo first and then import into manila?
15:31:04 <bswartz> pull it into manila first seems like ultimately more work
15:31:12 <vponomaryov> +1
15:31:24 <ameade> i can try to visualize how that will be
15:31:40 <ameade> but the reason is because it's not obvious what will go into oslo
15:31:54 <bswartz> well I can see this going into manila directly
15:32:01 <bswartz> some changes will be needed in the port
15:32:09 <bswartz> due to differences between cinder and manila
15:32:18 <ameade> yeah should be straight forward
15:32:25 <ameade> and do we want it experimental?
15:32:30 <ameade> cinder didnt have experimental
15:32:45 <bswartz> that would be an interesting discussion
15:32:52 <bswartz> is there a spec people can read?
15:33:12 <bswartz> because I could imagine this not being experimental
15:33:26 <ameade> #link https://review.openstack.org/#/c/273938/
15:33:28 <ameade> cinder spec
15:33:57 <tbarron> it's tech debt IMO, not sure there's a point in making it experimental.
15:34:02 <ameade> +1
15:34:08 <ameade> esp since it's concrete in cinder
15:34:12 <bswartz> #link https://specs.openstack.org/openstack/cinder-specs/specs/newton/summarymessage.html
15:34:21 <bswartz> ^ more readable link
15:34:24 <ameade> +1
15:34:37 <ameade> bit slow today, still out sick
15:34:41 <ameade> darn conference colds
15:35:45 <bswartz> okay well if you're not worried about the potential-double-effort of porting this to manila, then porting it to oslo, then retrofitting manila to use oslo then let's go ahead and propose the feature
15:36:19 <ameade> it will give putting it in oslo more weight too
15:36:49 <bswartz> okay anything else to discuss on this?
15:37:19 <bswartz> #topic experimental features in UI
15:37:36 <bswartz> vponomaryov: this was your topic
15:37:55 <vponomaryov> ok
15:37:57 <xyang1> bswartz: sorry to side track. thingee said infra wants to move away from wiki due to spam. it will be moved to etherpad in next 6 months: https://etherpad.openstack.org/p/newton-infra-wiki-upgrades
15:38:09 <bswartz> personally I think experimental features need GUI support for us to get the feedback/testing of the features
15:38:24 <bswartz> xyang1: gah! I'm opposed
15:38:24 <vponomaryov> it is general question: "do we want to support "experimental" APIs in Manila UI"?
15:38:44 <tbarron> will they be "declared" as experimental in the UI
15:38:46 <tbarron> ?
15:38:58 <bswartz> vponomaryov: what kind of technical challenges will we face if we implement experimental features in the UI plugin?
15:39:15 <vponomaryov> bswartz: if it changes, we lose support
15:39:21 <vponomaryov> bswartz: manila Ui becomes broken
15:39:22 <tbarron> and (I know this is anohter topic) can they be hidden if a cloud-operator wants that?
15:39:32 <bswartz> tbarron: I'm hoping we can add switches to turn them on/off
15:39:44 <ganso> bswartz: +1
15:39:46 <bswartz> tbarron: yeah that would be my preference
15:39:46 <vponomaryov> tbarron: it can be part of implementation - possibility to disable
15:39:47 <tbarron> I think that's essential
15:40:26 <vponomaryov> but contract of experimental APIs "allow them to be changed" breaks Manila UI
15:40:47 <vponomaryov> so, it is lottery if change APis )
15:40:59 <ganso> vponomaryov: wouldn't they need to be adjusted in manila-ui according to change?
15:41:14 <bswartz> yes we reserve the right to break the UI's usage of experimental features
15:41:14 <vponomaryov> manila Ui uses concrete APi versions
15:41:26 <vponomaryov> ganso: ^
15:41:28 <bswartz> thus it's important to make those features disableable
15:41:34 <markstur_> then version mismatch would still be a problem (even with fixes)
15:42:14 <bswartz> the fix when you combine a UI version with a server version that's not compatible should be to disable the broken features
15:42:19 <vponomaryov> I am leaning to not supporting experimental features in UI
15:42:20 <ganso> vponomaryov: I think breaking manila-ui can be expected with experimental features, the switch on/off should avoid breaking the main API though
15:42:32 <bswartz> ideally this will motivate us to make features non-experimental as quickly as possible
15:42:41 <vponomaryov> ganso: it will be bad user experience
15:42:48 <bswartz> because we'll experience pain when we break things
15:43:26 <bswartz> I still prefer UI breakage to not having a way to redesign something we're unhappy with
15:43:34 <vponomaryov> bswartz; poll for add/skip it for UI?
15:44:08 <bswartz> vponomaryov: perhaps in addition to the on/off switch we implement a version check and automatically switch off if the version is not an expected value
15:44:20 <bswartz> switch off the experimental UI feature
15:44:36 <gouthamr> ^ that sounds like a nicer way to get around breakages
15:44:46 <vponomaryov> bswartz: for example, in case of share groups, CGs will just be removed
15:44:51 <bswartz> thus users who wanted to have a UI for experimental features would be forced to ruin specific versions of manila-ui
15:45:04 <gouthamr> bswartz: but if i switch it on, i'll still have a terrible experience?
15:45:18 <markstur_> in some cases experimental UI is only a prototype --  pulled from gerrit
15:45:24 <markstur_> ^ that's easy
15:45:27 <vponomaryov> gouthamr: yes, you will need to live with it all your life ))
15:45:31 <bswartz> gouthamr: it would be forced to off if the version doesn't match
15:45:55 <gouthamr> understood. +1
15:46:04 <bswartz> because we don't offer backwards compatibility for experimental features either
15:46:11 <vponomaryov> bswartz: it is not strictly related to versions
15:46:21 <gouthamr> bswartz: we try hard to maintain them though.. as i have seen so far..
15:46:22 <vponomaryov> bswartz: we break version-relation using experimental APIs
15:46:34 <bswartz> yes that's the whole point
15:46:46 <bswartz> okay I think we have an idea of how to proceed here
15:47:05 <bswartz> the question will be how easily can we introduce manila-ui config switches for admins to enable/disable these features?
15:47:32 <vponomaryov> easy
15:47:33 <bswartz> the UI might end up with a bunch of if/then/else clauses to handle different feature combinations
15:47:52 <vponomaryov> but why do we want to add something that is going to be changed soon?
15:48:17 <bswartz> well remember when we implement an experimental feature, we HOPE that we won't need to change it
15:48:32 <vponomaryov> now CGs will be removed for sure
15:48:37 <bswartz> and the reason we merge it into master instead of keeping it in a dev branch is because we want feedback from actual users
15:48:59 <bswartz> in order to get feedback we need to give users a way to use the feature
15:49:26 <bswartz> CGs is a good example of something we tried that didn't work out
15:49:55 <bswartz> we're glad CGs is experimental, but we hope that what happens with CGs is a rare occurence
15:50:37 <bswartz> okay I think we have time to cover one more topic
15:50:48 <bswartz> #topic Share/snapshot size mismatch
15:51:04 <bswartz> vponomaryov: you proposed this topic too
15:51:19 <vponomaryov> bswartz: yes, htere was bugreport
15:51:27 <bswartz> #link https://bugs.launchpad.net/manila/+bug/1468642
15:51:29 <openstack> Launchpad bug 1468642 in Manila "Share size is not consistent between share_snapshots table and shares " [Low,In progress] - Assigned to zhongjun (jun-zhongjun)
15:51:45 <vponomaryov> #link https://bugs.launchpad.net/manila/+bug/1468642
15:52:24 <vponomaryov> so, we should decide what do we do with snapshow size when we resize share?
15:52:33 <bswartz> I think the trick here is just to agree on the semantics we want to define for snapshot size
15:52:36 <vponomaryov> source share for that snapshot
15:53:09 <bswartz> as we define snapshot semantics we also need to be clear about how to handle cases when there has been a resize since the snapshot was taken
15:53:46 <bswartz> for example, if I create share of 2GB, then take snapshot, then resize share to 4GB, then revert to snapshot -- what is the size of the snapshot?
15:53:49 <bswartz> ERR
15:53:54 <bswartz> what is the size of the share*
15:54:02 <ganso> should be 2GB, IMO
15:54:11 <ganso> this does not look like a bug to me o_O
15:54:27 <bswartz> as long as we all agree, there is no problem
15:54:30 <vponomaryov> bswartz, ganso: you propose to revert share size too?
15:54:35 <vponomaryov> reverting share to snapshot?
15:54:49 <bswartz> this implies that we need to store the share size with every snapshot -- do we currently do that?
15:54:58 <ganso> vponomaryov: yes, should revert to exact state
15:55:17 <ganso> bswartz, vponomaryov: but even out of "revert to snapshot" context, does not seem like a bug
15:55:52 <vponomaryov> ganso: if I am able to shrink share, then it is good experience to shrink existing snapshots too
15:56:00 <ganso> bswartz: I am not sure if currently the snapshot has its own size or if it derives from Share model
15:56:18 <bswartz> vponomaryov: what if some of the snapshots contain more data than the share currently does?
15:56:24 <ganso> vponomaryov: why?
15:56:41 <vponomaryov> oh, right
15:56:41 <fitodua18> l
15:56:55 <bswartz> ganso: https://github.com/openstack/manila/blob/master/manila/db/migrations/alembic/versions/162a3e673105_manila_init.py#L230
15:56:57 <tpsilva> ganso: it has
15:57:00 <vponomaryov> then it is really ok to not change snapshot size
15:57:19 <ganso> tpsilva: yup
15:57:41 <tpsilva> I think that's the reason that column exists... to store the size of the share in the moment the snapshot was taken
15:57:42 <bswartz> okay so I get the feeling there's no bug here
15:57:57 <bswartz> we just need to make sure that when we revert, we also revert the size
15:57:58 <vponomaryov> bswartz: better refer to current models, not migrations
15:58:10 <vponomaryov> bswartz: it can be changed with some other migration
15:58:10 <bswartz> sorry
15:58:19 <ganso> I saw the model, it has snapshot.size
15:58:24 * bswartz was lazy trying to find link quickly
15:58:33 <bswartz> okay
15:58:36 <bswartz> #topic open discussion
15:58:38 <bswartz> any last things?
15:58:49 <bswartz> I will carry over remaining agenda items to next week
15:58:49 <vponomaryov> so, we agreed that we do not change snapshot size and when we revert share to snapshot we revert share size to snapshot's?
15:59:00 <zhongjun_> I have one.
15:59:10 <bswartz> vponomaryov: yes I agree, and I think ganso does
15:59:19 <bswartz> zhongjun_: just 1 minute!
15:59:31 <tbarron> I think we have to use the old size (snapshot's size) b/c current size might be smaller and the snapshot data might not fit.
15:59:40 <zhongjun_> Does we need to fix the capabilities_and_extra_specs.rst doc about driver can only report one provision(thin or think)in a pool?
15:59:44 <tbarron> we may have deleted data since then
15:59:52 <tbarron> and shrunk the share
15:59:56 <gouthamr> zhongjun_: driver can report both
16:00:00 <bswartz> zhongjun_: I think we covered that case in the doc
16:00:02 <zhongjun_> Because the capability list has been supported, and driver also implement report the capabilities:"'thin_provisioning': [True, False]".
16:00:09 <gouthamr> zhongjun_: we have capability lists in manila
16:00:18 <zhongjun_> yes
16:00:21 <bswartz> drivers can report [True] [False] or [True, False]
16:00:30 <vponomaryov> zhongjun_: your case is "both"
16:00:32 <zhongjun_> change this word "If an array can technically support both thin and thick provisioning in a pool,
16:00:33 <zhongjun_> the driver still needs to programmatically determine which to use. ".
16:00:35 <zhongjun_> in doc
16:00:51 <bswartz> you use the value from the share type, when creating the new share
16:00:51 <gouthamr> zhongjun_: we need to improve that doc
16:00:53 <bswartz> share types cannot have both
16:01:05 <bswartz> okay we're past time
16:01:09 <bswartz> thanks all
16:01:13 <gouthamr> tc!
16:01:15 <bswartz> #endmeeting