15:00:18 <cknight> #startmeeting Manila
15:00:18 <openstack> Meeting started Thu Mar 31 15:00:18 2016 UTC and is due to finish in 60 minutes.  The chair is cknight. 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 <gouthamr> hello o/
15:00:22 <openstack> The meeting name has been set to 'manila'
15:00:25 <cknight> Hi all
15:00:26 <jseiler_> hi
15:00:27 <tbarron> hi
15:00:27 <ganso> hello
15:00:27 <Yogi1> Hello
15:00:28 <toabctl> hi
15:00:29 <tpsilva> hello
15:00:31 <dustins> \o
15:00:38 <zhongjun_> hi
15:00:39 <xyang1> hi
15:00:39 <ameade> o/
15:00:40 <Poornima> Hello :)
15:00:53 <cknight> Our illustrious PTL is on vacation today.
15:01:09 <vponomaryov> hi
15:01:10 <cknight> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:01:33 <markstur_> hi
15:01:50 <cknight> #topic Mitaka release status
15:01:54 <cknight> We haven't seen any bugs in RC1 that would merit an RC2 release.
15:02:34 <jarrpa> howdy!
15:02:36 <cknight> And today is the last day to request an RC2 re-spin, and Ben is the only one who can request it, so RC1 is likely to be the release build.
15:02:47 <cknight> Thanks to everyone for testing RC1.
15:03:05 <cknight> #topic Design summit planning
15:03:25 <cknight> The final schedule confirms 2 fishbowls, 4 working sessions, 1 half-day meetup for Manila.
15:03:49 <cknight> Anyone can propose summit topics on the etherpad, and voting is open there now.
15:03:55 <gouthamr> #link https://etherpad.openstack.org/p/manila-newton-summit-topics
15:04:26 <cknight> #topic Manila documentation
15:04:30 <cknight> gouthamr: you're up
15:04:36 <gouthamr> thanks cknight
15:04:56 <gouthamr> alright, its mostly a bunch of questions i had regarding documentation in Manila
15:05:18 <gouthamr> when we add new features, where do we add documentation for it?
15:05:50 <gouthamr> i had a tough time figuring out all the places and the limitations.. i was wondering if we have a plan and a direction for devs to follow
15:05:59 <dustins> And at what time? On code commit? Before release?
15:06:13 <gouthamr> dustins: +1, that too
15:06:19 <Poornima> +1
15:06:37 <gouthamr> so we have a devref in tree.. and an adminref
15:06:46 <vponomaryov> gouthamr: you always can add docs to "openstack/manuals" and similar projects
15:06:59 <gouthamr> our configref lives alongside the rest of openstack in openstack-manuals
15:07:19 <gouthamr> and there's this other guide, cloud_admin_guide
15:07:26 <gouthamr> where we seem to have some of our documentation
15:07:53 <cknight> There was a big push to create / update Manila docs during Liberty, but I'm not aware of an index to where they all live and what content goes where.  Perhaps we need such a meta-doc for Manila devs.
15:07:56 <gouthamr> so that begs the question.. shouldn't we coordinate this for everything that we add
15:08:29 <gouthamr> #link http://docs.openstack.org/admin-guide-cloud/shared_file_systems.html
15:08:41 <gouthamr> #link http://docs.openstack.org/developer/manila/devref/
15:08:43 <vponomaryov> gouthamr: in good way yes, created feature? - create all related things or delegatet them
15:09:00 <cknight> gouthamr: Yes, and we should remain consistent with how the other projects handle docs.
15:09:21 <gouthamr> vponomaryov: yes, but when most of the documentation gets added, it seems to be in devref
15:09:32 <gouthamr> vponomaryov: many a times, that doesn't make semantic sense to me...
15:09:43 <vponomaryov> gouthamr: devref is good "sandbox"
15:09:56 <gouthamr> vponomaryov: like using a new driver.. or understanding common capabilities
15:10:02 <gouthamr> and who supports what
15:10:38 <gouthamr> vponomaryov: so do we collate all the information sometime and publish it in the right places?
15:11:07 <ameade> what about the doc liaison idea?
15:11:13 <vponomaryov> gouthamr: I did so in https://review.openstack.org/#/c/297758/
15:11:18 <cknight> #link https://wiki.openstack.org/wiki/CrossProjectLiaisons#Documentation
15:11:45 <dustins> ameade: I was thinking the same
15:11:48 <ameade> i'm sure the others have insight here
15:11:57 <ameade> (other liaisons)
15:12:26 <gouthamr> vponomaryov: awesome.
15:12:40 <gouthamr> vponomaryov: but do you plan on doing that every release?
15:12:40 <markstur_> for the driver pages each vendor has assigned someone.  Trying to find that wiki.
15:12:42 <gouthamr> vponomaryov: :D
15:13:11 <vponomaryov> gouthamr: for three releases further ))
15:13:51 <gouthamr> vponomaryov: lets find some docs liaison/s to coordinate this
15:13:53 <gouthamr> :)
15:13:57 <cknight> vponomaryov: thanks for taking the lead on updating the docs for Mitaka
15:14:00 <markstur_> https://wiki.openstack.org/wiki/Documentation/VendorDrivers
15:14:17 <cknight> Is there a volunteer to serve as Manila docs liaison?
15:14:23 <dustins> I'm game
15:14:36 <cknight> dustins: Thanks!
15:14:50 <dustins> No problem! :)
15:14:57 * gouthamr dustins always finds ways to end my rants :)
15:15:00 <cknight> #agreed dustins is the Manila docs liaison.
15:15:01 <markstur_> dustins, 3D
15:15:12 <gouthamr> Dustin the Documentation Dude
15:15:28 * dustins was really hoping no one was paying attention to that
15:15:30 <dustins> :P
15:15:54 <gouthamr> dustins
15:15:55 <cknight> dustins: I suggest the first thing you can do to help everyone else is to write a short doc that is a roadmap to manila docs for us developers.
15:16:11 <dustins> cknight: I was already outlining it my my head
15:16:20 <gouthamr> dustins: always happy to help. i can brain dump my findings regarding the docs so far
15:16:37 <dustins> gouthamr: Sounds great, thanks, gouthamr!
15:16:38 <cknight> gouthamr: You also had thoughts about release notes?
15:16:44 <gouthamr> cknight: yes
15:16:56 <gouthamr> we did not add a lot of renos in Mitaka
15:17:03 <cknight> #link http://docs.openstack.org/developer/reno/usage.html
15:17:13 <gouthamr> i was hoping as a community, we can do renos in Newton seriously
15:17:44 <gouthamr> its really easy to add a reno.. thanks for the link cknight
15:17:45 <cknight> gouthamr: +1  It's really trivial to add a one-liner release note using reno.
15:17:50 <vponomaryov> gouthamr: this thing appeared silently without notification and so on, here is result
15:18:21 <gouthamr> vponomaryov: true
15:18:35 <cknight> vponomaryov: Yes, there was a fire drill at the end of Liberty to add reno support.  But we didn't discuss it as a community.
15:19:25 <cknight> gouthamr: What is the guideline for knowing when to add a reno?
15:19:46 <cknight> gouthamr: It seems not every patch needs one.
15:19:49 <gouthamr> cknight: anything that's a new feature needs a release note
15:20:07 <cknight> gouthamr: What about significant bug fixes?
15:20:14 <gouthamr> cknight: i think that too
15:20:25 <vponomaryov> gouthamr: do you have link to th elist of such things?
15:20:26 <cknight> gouthamr: And does that include new driver features?
15:20:41 <dustins> cknight: It probably should
15:21:59 <cknight> gouthamr: I'd like to see a short list somewhere that makes it reasonably objective when to add a release note.  Can you do that?
15:22:06 <gouthamr> cknight: yes
15:22:18 <gouthamr> cknight: i'll find stuff and add it to the wiki and ping on the channel
15:22:31 <gouthamr> cknight: we can point devs to it in reviews too
15:22:48 <cknight> gouthamr: Thanks.  Given that, we can bring it up next week and ask for agreement among core reviewers to look for renos.
15:22:49 <markstur_> Thanks!
15:22:53 <dustins> gouthamr: And I'll help you out with that as well
15:22:57 <gouthamr> thanks dustins
15:23:05 <cknight> gouthamr: Anything else on docs?
15:23:07 <gouthamr> cknight: sure thing
15:23:27 <gouthamr> cknight: nope. i guess that's all the ranting for today. :) Please look out for replication docs
15:23:35 <cknight> #topic Managing/unmanaging replicated shares and snapshots
15:23:37 <markstur_> Is there enough for a doc/reno topic at summit?
15:23:42 <cknight> you're still up, gouthamr
15:23:52 <gouthamr> cknight: thank you
15:24:09 <cknight> markstur_: We could discuss it in the meetup.  Please propose that if you like.
15:24:13 <gouthamr> markstur_: not sure.. i will do the digging on the community policy regarding renos and maybe dustins will bring up stuff too
15:24:39 <dustins> most likely :D
15:24:44 <gouthamr> alright, so about manage/unmanage
15:25:24 <gouthamr> in the review cycle, vponomaryov pointed to me that managing a share with a share type that has the replication_type extra spec does not work as required
15:25:59 <gouthamr> i.e, you can manage a share with the share type, but for replication to work, the replication_type key must be copied to the share model
15:26:12 <gouthamr> this is being done in the create share workflow, but not the manage workflow
15:26:31 <gouthamr> ganso fixed a similar bug (for snapshot_support extra spec) recentky
15:26:39 <gouthamr> s/recentky/recently
15:27:27 <gouthamr> so the question was how to handle manage/unmanage for shares that need to support replication
15:27:53 <gouthamr> as of Mitaka, manage ignores your request
15:28:07 <gouthamr> as stated earlier..
15:28:29 <gouthamr> however, i don't think it is straightforward to allow managing shares that should support replication..
15:28:52 <gouthamr> because, 1) the share may already have replicas that manila doesn't know about
15:28:53 <vponomaryov> gouthamr: why? namaged original share and crated replica
15:29:04 <vponomaryov> s/namaged/managed/
15:29:13 <vponomaryov> s/crated/created/
15:29:22 <gouthamr> vponomaryov: yes.. what about when it has replicas already?
15:29:45 <markstur_> seems like already has snapshots case
15:29:58 <markstur_> a bit
15:30:01 <gouthamr> vponomaryov: if you allow admins to manage a share that has replicas, the user can then add more replicas and switch replication relationships
15:30:12 <gouthamr> markstur_: probably true...
15:30:51 <markstur_> but that doesn't mean we have to follow the manage-snapshots design to manage-replicas. --  just to consider it
15:30:51 <vponomaryov> gouthamr: share driver should be smart enough to get to know whether it can manage share or not
15:30:58 <cknight> vponomaryov: If replicas already exist, then the driver managing the active instance may not be able to discern enough info (such as the host values) to report all the needed replica info to manila.
15:32:09 <gouthamr> cknight: +1 i know NetApp driver can check and report things to Manila if necessary.. but then, what should it report?
15:32:15 <cknight> gouthamr: Assuming we support managing replicated shares, which I think we should, we could only allow it (at first) for shares that don't have any existing replicas.
15:32:25 <tbarron> cknight: so are you saying the driver should decide whether to fail the operation or that it can figure out how to do it?
15:32:50 <cknight> tbarron: manage is already that way.  the driver is allowed to fail a manage operation for any reason.
15:33:02 <tbarron> cknight: right
15:33:13 <cknight> tbarron: manage is an admin-only operation, so drivers can be very strict about what may be managed.
15:33:16 <Poornima> oops sorry lost network
15:33:28 <tbarron> so some drivers might know how to do it even if the share has a replica already
15:33:34 <vponomaryov> cknight, gouthamr: For example, ZFSonLinux driver performs replication itself, so, in case of this driver it is completely ok to manage sharethat was used in replciation earlier
15:34:03 <vponomaryov> s/itself/by itself/
15:34:38 <cknight> vponomaryov: Could that driver determine the host@backend#pool values for each existing replica?
15:35:19 <vponomaryov> cknight: such info is provided in manage API
15:35:28 <tbarron> i'm thinkng that instead of the manager deciding to fail if there are pre-existing replicas that decision could be left to the driver
15:35:56 <cknight> tbarron: sure, but we would have to design the interface to allow that.
15:36:10 <gouthamr> vponomaryov: i don't fully understand that, how will Manila know the host strings to provide for every replica? the API needs to change?
15:36:37 <tbarron> cknight: agree
15:36:41 <vponomaryov> cknight, gouthamr: I talking about manageing "single" share, that could be in replciation
15:36:51 <vponomaryov> s/I/I am/
15:37:06 <gouthamr> vponomaryov: yes.. as long as the share did not have replicas before, this sounds logical
15:37:10 <vponomaryov> could be in replication earlier
15:37:27 <vponomaryov> gouthamr: in case of ZFSonLinux driver it does not matter
15:37:37 <gouthamr> vponomaryov: we're talking about how to bring those replicas into manila's management
15:38:01 <gouthamr> vponomaryov: as they are..
15:38:23 <vponomaryov> gouthamr: then we should have new "discover replicas" mechanism
15:38:48 <vponomaryov> gouthamr: and if we have all replica hosts under manila control then just register them
15:39:36 <vponomaryov> gouthamr: same about snapshots for replicated shares
15:39:36 <gouthamr> vponomaryov: if not, LOG errors and don't bother creating the replica record?
15:40:01 <vponomaryov> gouthamr: we create Db record right now
15:40:03 <gouthamr> vponomaryov: i still dunno how the driver can get hold of the host/pool string
15:40:26 <vponomaryov> gouthamr: "manage API" requires this string
15:40:35 <vponomaryov> gouthamr: host@backend#pool
15:41:00 <gouthamr> vponomaryov: yep.. currently, we can only manage a single share instance..
15:41:13 <gouthamr> vponomaryov: with one host string and one export location
15:41:40 <vponomaryov> so, if we want to manage replciated shares we need "discover replicas" mechanism, that's all, all other questions are only implementation details
15:41:48 <cknight> vponomaryov, gouthamr:  Either way, it's more work.  That's why we could consider a multi-step approach: manage replicated shares with no replicas in Newton, manage replicated shares with existing replicas later.  I think adding DHSS=True support for replication is more important that the more complicated manage operation.
15:42:06 <gouthamr> cknight: yes, i agree.
15:42:40 <cknight> gouthamr: I don't see this topic on the summit etherpad, so if it's not urgent I think we could discuss it there.
15:43:02 <gouthamr> cknight: sure thing. i'll submit a change with what you suggested.. we can discuss this further.
15:43:11 <gouthamr> thanks vponomaryov tbarron cknight
15:43:16 <cknight> gouthamr: Thanks.  Anything else on this topic?
15:43:36 <gouthamr> cknight: nope...
15:43:42 <cknight> #topic Open discussion
15:43:58 <Poornima> Hi cknight gouthamr any upcoming plan's for manila tempest api's
15:44:28 <gouthamr> Poornima: you mean manila_tempest_tests?
15:44:32 <cknight> Poornima: Not sure what you are asking.  Can you be more specific?
15:44:34 <vponomaryov> Poornima: tempest APIs? it does not have APIs
15:44:34 <Poornima> yep
15:45:23 <gouthamr> Poornima: do you want to suggest something?
15:45:24 <Poornima> are all tempest test covered https://github.com/openstack/manila/blob/master/manila_tempest_tests/tests/api/ ?
15:45:51 <cknight> Poornima: We are always adding Tempest tests, and we're working to resolve issues and improve their design.  We should have nearly complete coverage of Manila APIs, but more tests are usually welcome.
15:46:23 <Poornima> cknight, great where can i check the missing one
15:46:25 <cknight> Poornima: Where we are more deficient is in the scenario tests.  If you are looking for somewhere to contribute, that would be a good place.
15:46:31 <vponomaryov> Poornima: tests are evolving with Manila
15:47:01 <Poornima> yeah cknight vponomaryov I was looking in those to start contributing
15:47:25 <cknight> Poornima: API tests don't guarantee that backends actually work with real data.  Scenario tests do that, and someday when the scenario tests are reliable we expect to ask vendor CI systems to begin running them.
15:47:44 <cknight> Poornima: Great, and thanks for being willing to contribute.
15:48:03 <gouthamr> thank you Poornima! :)
15:48:19 <Poornima> My pleasure :)
15:48:44 <cknight> Any other topics for today?
15:49:25 <cknight> Going once…
15:49:49 <cknight> OK, we'll leave it there.  Thanks, everyone!
15:49:54 <cknight> #endmeeting