15:00:19 <bswartz> #startmeeting manila
15:00:20 <openstack> Meeting started Thu May 19 15:00:19 2016 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:24 <openstack> The meeting name has been set to 'manila'
15:00:41 <toabctl> hi
15:00:41 <cknight1> Hi
15:00:42 <gouthamr> hello o/
15:00:43 <bswartz> hello
15:00:44 <ganso> hello
15:00:44 <tpsilva> hello
15:00:45 <aovchinnikov> hi
15:00:46 <sgotliv_> o/
15:00:48 <jseiler> hi
15:00:51 <dustins> hey \o
15:00:55 <xyang2> hi
15:00:57 <vponomaryov> Hello
15:01:02 <markstur_> hi
15:01:21 <zhongjun_> hi
15:01:22 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting
15:01:56 <bswartz> just a few leftover discussion topics from design summit
15:02:11 <bswartz> I'll save those for after the specific topics people proposed
15:02:23 <bswartz> #topic share backup
15:02:41 <bswartz> zhongjun_: you're up
15:02:50 <zhongjun_> thanks
15:02:54 <zhongjun_> I saw the record about discussion share backup. but it is not a conculution.
15:03:06 <tbarron> hi
15:03:07 <bswartz> which discussion?
15:03:07 <zhongjun_> so, There are two ideas(Not very detailed, just a direction) for the share backups, please see which one is suitable for manila?
15:03:07 <zhongjun_> or which one is definite not suitable for manila.
15:03:22 <bswartz> we haven't discussed share backup in details since the winder midcycle meetup
15:03:23 <zhongjun_> 1. Smaug(openstack project)+Manila+Swift(or something else)
15:03:24 <zhongjun_> Use swift as a smaug's backup plugin, Use smaug calling manila's APIs(such as share-list, share-instances-export-location) to obtain share information. then creating a backup in smaug.
15:03:24 <zhongjun_> 2. Add backup APIs in Manila Data service, let manila own have backup capacity.
15:04:53 <bswartz> personally I see both options as valuable
15:05:15 <bswartz> given that (2) will be a lot of work it seems like (1) is more likely to happen sooner
15:05:19 <mkoderer> hi
15:05:53 <zhongjun_> The benifit of use first idea: it not only backup share but also backup manila config and database, etc.
15:05:59 <ganso> it seems to me that the development in (1) is creating a plugin in Smaug
15:06:12 <sgotliv_> does it mean we recommend to use Smaug for manila backups?
15:07:00 <bswartz> I don't know enough about smaug yet to understand what it can do for a project like manila
15:07:15 <tbarron> is (1) written up somewhere so we can study it in more detail?
15:07:23 <dustins> tbarron: +1
15:07:31 <bswartz> however if they have ideas for backing up shared file systems I think we should be supportive and helpful
15:08:04 <mkoderer> how is this related to freezer? https://wiki.openstack.org/wiki/Freezer
15:08:22 <bswartz> I also don't know anything about freezer
15:08:28 <sgotliv_> I believe smaug compete with freezer
15:08:38 <sgotliv_> I am kind of learning them both these days
15:08:58 <bswartz> I believe that regardless of what backup or DR services are built on top of Manila, users will get a better experience if we build backup / DR features into manila itself
15:09:09 <bswartz> therefore we should do both
15:09:11 <gouthamr> it would be nice to hash 1) out in a manila-spec (now that we can't create new Wiki pages)
15:09:13 <mkoderer> ok we have too many projects in OpenStack...
15:09:18 <zhongjun_> tbarron: The smaug have a video demo, but I forget the link, I will find it and put it to wiki.
15:09:22 <gouthamr> i'm also interested in restore :)
15:09:26 <bswartz> share replication was designed with that belief in mind
15:09:27 <sgotliv_> mkoderer, +1
15:09:40 <zhongjun_> link: https://wiki.openstack.org/wiki/smaug
15:09:44 <sgotliv_> i can post a link later
15:09:49 <sgotliv_> lol
15:09:56 <sgotliv_> zhongjun_, thanks
15:09:59 <dustins> mkoderer: +1
15:10:43 <zhongjun_> gouthamr: In smaug, use heat to restore openstack  environment.
15:10:47 <bswartz> when we discussed share backup at the midcycle one of the arguments against doing it was that many other backup tools exist and many of those are going to be way better than anything we build into manila unless we spend large amounts of time on a manila backup feature
15:11:27 <xyang2> https://www.youtube.com/watch?v=_tVYuW_YMB8
15:11:33 <bswartz> I still think it's worth developing some kind of backup framework with minimal capabilities just to have a standard interface
15:11:36 <xyang2> smaug
15:11:43 <dustins> and if we have projects that provide backup functionality, why reinvent the wheel?
15:11:45 <zhongjun_> xyang2: thanks xyang
15:11:55 <bswartz> but we won't be able to compete with other solutions that focus 100% on backup
15:12:00 <toabctl> dustins: +1
15:12:53 <sgotliv_> I believe these projects use API provided by backed component
15:12:56 <ganso> if there is an openstack service and is focused on it, a plugin for it makes sense
15:13:05 <dustins> ganso: +1
15:13:10 <ganso> they would be reinventing the wheel, not us hehe
15:13:11 <bswartz> dustins: there are some kinds of things that can only be done properly with low level access to the storage -- the kind of thing that requires code in the storage drivers to implement
15:13:15 <tbarron> zhongjun_: i'm a little bit familiar with smaug but i haven't seen anything about filesystem backup in particular yet
15:13:39 <bswartz> those can only be implemented as features in projects that have storage drivers (AKA cinder, manila, glance, etc)
15:13:56 <zhongjun_> tbarron: It will, I will do
15:14:03 <bswartz> services that layer on top of these services will be limited in what they can achieve through the common interface
15:14:10 <dustins> bswartz: Indeed, tricky to balance a general approach versus exposing value in the underlying storage back end
15:14:38 <bswartz> that's why I say we should do both
15:14:42 <ganso> bswartz: I wouldn't say only done properly in the backend, but more efficiently in most cases. Backup can still be done properly through the storage interface (NFS shares for instance)
15:14:43 <tbarron> zhongjun_: i'd be interested in seeing a spec for integration with smaug
15:15:26 <bswartz> ganso: you probably recall some people at the migration talk in austin saying it was important to them that their backups were bit-exact
15:15:26 <zhongjun_> bswartz: +1
15:15:26 <dustins> tbarron: ditto
15:15:58 <bswartz> that kind of guarantee can only be provided at the storage driver level -- you can't do that in a generalized way
15:16:27 <tbarron> in cinder's case i believe smaug intends to use standard cinder api which allows for backend driver optimizations
15:16:33 <zhongjun_> tbarron, dustins: Oh, that's sounds good.
15:16:34 <tbarron> for volume backup
15:16:41 <dustins> Hmm, perhaps we could do a Smaug-based solution just to cover everything for now, then we can add the "special sauce" in another release?
15:16:44 <tbarron> for dbase backup, etc., difft story
15:16:49 <bswartz> tbarron: backups of volumes is fundamentally easier than backups of file systems
15:17:01 <tbarron> bswartz: +1
15:17:51 <tbarron> for filesystems we have metadata issues like with migration
15:17:53 <bswartz> zhongjun_: did we answer you qusetion?
15:17:54 <tbarron> for one thiing
15:18:00 <bswartz> question*
15:18:36 <zhongjun_> bswartz: yes, the answer is two idea is ok?
15:18:48 <zhongjun_> s/idea/ideas
15:19:02 <bswartz> yes I don't want to discourage either approach
15:19:13 <bswartz> if people want to work on both, then that's great
15:19:36 <bswartz> personally I'd like to spend time on manila backup -- there are just too many other important problems to solve first
15:19:39 <zhongjun_> bswartz: That's great, thanks
15:19:41 <bswartz> let's move on
15:19:49 <bswartz> #topic snapshot restore
15:19:56 <cknight1> I'm working on the Snapshot Restore feature we agreed to at Summit.
15:20:00 <bswartz> cknight1: you're up
15:20:08 <cknight1> I had a working POC before we left Austin, and the spec is in review.
15:20:15 <cknight1> #link  https://review.openstack.org/#/c/315695/
15:20:25 <bswartz> do people like the name "Snapshot restore" better than "revert to snapshot"?
15:20:25 <cknight1> Most of it seems non-controversial, but there is a question about the REST API.
15:20:53 <cknight1> bswartz: Your question is germane to mine!
15:20:57 <cknight1> There are two objects involved, the share being reverted, and the snapshot being restored.
15:21:09 <cknight1> In any case, the API must be explicit about which snapshot is being restored.
15:21:19 <bswartz> when I think of restoring snapshots I imagine creating a new share from a snapshot
15:21:37 <vponomaryov> +1 for "revert to snapshot"
15:21:40 <cknight1> If the API is on the share, then the snapshot must be specified in the body.
15:21:44 <bswartz> when I think of reverting to a snapshot I think of modifying an existing share
15:22:01 <ganso> cknight1: +1 for "snapshot restore"
15:22:04 <cknight1> If the API is on the snapshot, then the share need not be specified because Manila can infer it from the snapshot.
15:22:19 <cknight1> I chose the latter because it is simpler to invoke, it matches the GUI tools I'm familiar with where the restore action is on the snapshot, and the client code is smaller.
15:22:38 <bswartz> can't the action be on the snapshot but we call it something like snapshot revert?
15:22:40 <markstur_> bswartz, +1 (the 2 names suggest different meanings)
15:22:41 <cknight1> But in the extremely unlikely case where the API layer can find the specified snapshot but not the share, the server would have to return a 500 because something went very wrong in the server.  I'm not aware of any code that returns 500-series errors today, so it would be something new.
15:22:52 <bswartz> revert makes is obvious that you're going backwards
15:23:05 <ganso> cknight1: also, you don't need to touch the share API since this is mostly a change to snapshots API
15:23:26 <cknight1> bswartz: That's true.  Personally, I don't feel strongly about it.
15:23:27 <zhongjun_> cknight1: +1 for "snapshot restore/revert"
15:23:35 <vponomaryov> action is applied to a share, it should be "shares" API
15:24:03 <bswartz> vponomaryov: if we do that then the caller has to specify the share ID in the URL and the snapshot ID in the body
15:24:17 <bswartz> that's more work for the caller than just specifying the snapshot ID in the URL
15:24:24 <ganso> bswartz: in fact no, we agreed we always revert to latest
15:24:24 <vponomaryov> why?
15:24:29 <vponomaryov> we allow only latest snapshot
15:24:33 <vponomaryov> no need to provide it
15:24:44 <vponomaryov> ganso: )
15:24:54 <ganso> bswartz: so, if we do not need to do /snapshots/snapshot-id/restore, then it makes sense to be /shares/share-id/revert
15:24:59 <ganso> revert will know what to do
15:25:01 <bswartz> well the user has to specify which snapshot he expects to be restored in case a new shapshot call races with the revert call
15:25:02 <ganso> because it is the latest
15:25:14 <ganso> bswartz: we should avoid such races
15:25:29 <bswartz> that sort of race is unavoidable
15:25:49 <vponomaryov> bswartz: who will create snapshots when it should be reverted?
15:25:54 <bswartz> if I list the snapshots, then invoke share revert, and another snapshot was taken between those 2 operations, I might be very confused
15:25:55 <vponomaryov> bswartz: it is not use case
15:26:28 <xyang2> since we are modifying the share, shares api seems more appropriate
15:26:43 <bswartz> in that case we would at least need to return the UUID of the snapshot we did revert to
15:26:53 <bswartz> if the caller doesn't specify it
15:27:05 <vponomaryov> bswartz: return some data - ok
15:27:10 <bswartz> to prevent surprises
15:27:28 <dustins> Yeah, something just saying "I used this snapshot to restore from" would be handy
15:27:30 <cknight1> bswartz:  We're changing data, so I think the API should be very explicit about what snapshot is being restored.
15:27:40 <toabctl> cknight1: +1
15:27:41 <dustins> cknight1: agreed
15:27:53 <cknight1> bswartz:  I don't think the server should pick the latest one itself, since that can lead to a surprise.
15:27:58 <bswartz> yeah I lean towards explicitness so we can report more accurate errors
15:28:02 <toabctl> and there can be 2 admins + one creating a new snapshot and one reverting
15:28:15 <cknight1> bswartz:  In my POC, I check that the specified snapshot is actually the latest one.
15:28:18 <vponomaryov> cknight1: manila can store value of latest snapshot in share model
15:28:19 <dustins> Yes, that way we can error out saying that the snapshot specified was not the most recent
15:28:19 <ganso> cknight1, bswartz: why wouldn't share's status prevent this scenario? if we have statuses with locks
15:28:26 <bswartz> worst case is you get an error
15:28:27 <vponomaryov> cknight1: that can be visible via "share show"
15:28:42 <bswartz> ganso there is unknown time between when an admin looks at the list of snapshots and invokes the revert call
15:28:48 <bswartz> it could be seconds or minutes or hours
15:28:50 <ganso> bswartz: if a snapshot is created, even though it is in "Creating" then it is latest, but share status will be "snapshotting"
15:29:05 <ganso> bswartz: oh I see, two users under the same tenant
15:29:17 <bswartz> yes
15:29:18 <ganso> bswartz: like, one user is taking a snapshot and the other is reverting
15:29:34 <toabctl> ganso: yes
15:29:46 <bswartz> if that were to happen, the revert call should error out explaining that the specified snapshot is no longer the latest snapshot
15:29:52 <ganso> bswartz: so if we need the snapshot parameter there is no real advantage between usage of either API
15:29:57 <bswartz> then the admins can get together and figure out what they want to do
15:30:15 <cknight1> So what I'm hearing is that most feel this should be an action on the share as far as the REST API is concerned.
15:30:24 <bswartz> I'm hearing though that for semantic reasons people prefer it's a share action
15:30:33 <bswartz> cknight1: yes definitely
15:30:48 <cknight1> And the CLI should be 'revert-to-snapshot' instead of 'snapshot-restore'.  Right?
15:30:58 <bswartz> it might be slightly less RESTful but it's more clear what's going on
15:31:02 <markstur__> +1
15:31:02 <dustins> "restore this share to this snapshot" rather than "with this snapshot restore this share"
15:31:03 <ganso> cknight1: +1
15:31:14 <vponomaryov> cknight1: +1
15:31:19 <bswartz> yes revert-to-snapshot seems very clear
15:31:33 <dustins> cknight1: +1
15:31:41 <cknight1> OK, I'll make it happen.  Thanks, everyone!
15:31:53 <bswartz> the revert-to-latest-snapshot (with no snapshot arg) is also interesting but a little scary to me
15:32:06 <cknight1> bswartz: yes, too scary
15:32:17 <bswartz> okay
15:32:23 <bswartz> let's move on
15:32:28 <bswartz> #topic specs
15:33:00 <bswartz> ganso asked earlier today about spec deadlines, and requirements for specs
15:33:14 <bswartz> I don't believe we agreed on any deadlines, or requirements for specs
15:33:29 <bswartz> we have the specs repo, and people are already using it, which is great
15:33:35 <ganso> ok so bswartz and I were discussing today about specs priority, I think it is a good idea that N1 has specs prioritized because if we are following this idea of working with specs, specs block implementation if they are not approved
15:34:13 <bswartz> however where we left things in Austin was that specs are still optional and we encourage them but don't require them
15:34:47 <bswartz> for the purpose of reviews I do think ganso has a point
15:34:50 <tbarron> we need to avoid being too waterfall here, it would be good to be able to refine specs and refine code in parallel
15:35:19 <bswartz> if a developer is waiting for feedback on his ideas before writing the code then we should prioritize reviewing the spec and providing the feedback
15:35:21 <markstur__> +1 for in parallel
15:35:23 <tbarron> where the code doesn't get merged in the end if it diverges significantly from spec
15:35:48 <ganso> I think they should not be enforced, according to what we discussed in Austin, it seems the main value of specs for Manila, is to have feedback on design and implementation before investing a lot of work in it and having to change too late in the cycle
15:35:54 <bswartz> we shouldn't force developers to wait, but in ganso's case it sounds like he doesn't want to start coding the wrong thing
15:36:04 <tbarron> understood
15:36:07 <ganso> there are proposals that do not need specs, or that they may not need too much feedback or refining
15:36:20 <xyang2> if we could get code merged before spec is merged, that will be better, so spec will not be out of sync with code
15:36:24 <ganso> so specs aggregate more if they used
15:37:23 <ganso> xyang2: that would be good also, but then we need to consider the spec approved even though not merged
15:37:32 <bswartz> ganso: in the past the way we've stimulated feedback was to bring up specific topics during these weekly meetings and ask for feedback
15:37:37 <xyang2> ganso: yes, it is tricky
15:38:04 <xyang2> ganso: the code will almost always go out of sync with spec if spec is merged first
15:38:10 <bswartz> ganso: if you're looking for feedback on your spec I suggest we just bring it up here and agree to give you yes or no decisions by some date
15:38:22 <ganso> bswartz: sometimes people find out that they disagree with design or find a potential flaw when we are too close to FF
15:38:26 <xyang2> ganso: but if spec is not merged, people may not want to +2 the code
15:38:55 <mkoderer> I would merge specs and after that merge the code and update documentation accorindgly
15:39:02 <bswartz> okay let's not get too wrapped up in the meaning of a merged spec
15:39:14 <bswartz> I think we agreed that we can modify specs after they're merged
15:39:15 <ganso> xyang2: then we need a social rule for this, so it makes sense and we do not get stuck not being able to merge a code because spec was not merged hehe
15:39:25 <mkoderer> I don't see any issue in outdated specs as long the documenation is up to date
15:39:37 <xyang2> mkoderer: that's fine too.  just need to remember to update the spec afterwards
15:39:38 <ganso> mkoderer: +1
15:39:40 <bswartz> I dislike the ceremonial "merging of the spec" to mean that the idea is somehow blessed and approved
15:39:45 <vponomaryov> mkoderer: docs up-to-date is utopia
15:39:48 <xyang2> ganso: agree
15:40:01 <tbarron> bswartz: +1
15:40:07 <mkoderer> vponomaryov: would also mean: spec up-to-date is utopia ;)
15:40:10 <bswartz> I think we should try to reach consensus and merge specs but that shouldn't be the end of the discussion
15:40:23 <tbarron> i'm just saying look at the spec before the code merges, ask questions about divergence, etc.
15:40:28 <tbarron> use our heads
15:40:36 <ganso> bswartz: I think this "ceremony" is needed, else devs won't be required to review the spec at all, and their value will be diminished
15:40:39 <dustins> tbarron: +1
15:41:12 <ganso> this is similar situation with blueprints
15:41:12 <tbarron> ganso: we can build a culture that does the right thing w/o having to make formal process IMO
15:41:15 <bswartz> ganso: yes we need people to know that feedback is more welcome earlier than later
15:41:42 <vponomaryov> bswartz: "merge" is kind of proof
15:41:50 <bswartz> we have a history of people ignoring features until 2 weeks before feature freeze then dropping a whole bunch of feedback
15:42:14 <bswartz> that's not a good experience for contributors
15:42:16 <ganso> bswartz: yes, specs cannot solve that by itself, it is more of a cultural thing
15:42:34 <tbarron> and a history of big code drops late, right?
15:42:37 <bswartz> okay so here's a proposal
15:42:44 <ganso> so my idea of emphasizing "priority" is to address this
15:42:48 <ganso> no deadlines
15:42:50 <ganso> just priorities
15:43:22 <bswartz> if people post a spec, and ask for feedback, we should prioritize reviewing the spec and giving feedback early (before first milestone as ganso says)
15:44:12 <mkoderer> btw we have already some specs in gerrit for review.. can we put some priority to review them? ;)
15:44:14 <bswartz> people who fail to review specs shouldn't propose major changes later on in the release
15:44:40 <xyang2> bswartz: define major changes:)
15:44:52 <bswartz> xyang2: something which should have caught in the spec review
15:44:53 <vponomaryov> xyang2: good catch! ))
15:45:21 <bswartz> sometimes you can't see why you don't like something until you see the implementation
15:45:35 <mkoderer> bswartz: so true :)
15:45:52 <bswartz> but in many cases you can see objectionable things in the spec and the right time to object to those is before the code is written
15:46:18 <markstur__> disagreements in specs need to get resolved before code merges
15:47:00 <gouthamr> markstur__: yes..
15:47:02 <markstur__> Nits in specs -- shouldn't be a roadblock
15:47:18 <bswartz> also (and I've seen this with specs I've written) sometimes you just get really helpful suggestions in the spec review which make implementation go more smoothly
15:47:37 <bswartz> believe it or not, other people have good ideas
15:47:37 <markstur__> Also code POC before spec is decided is still a good idea if coder is OK w/ POC
15:48:01 <markstur__> but that isn't supposed to change the spec process (just adds proof)
15:48:16 <tbarron> markstur__: +1 correct spelling, etc. but don't -1 for it alone
15:48:41 <bswartz> wait a minute
15:48:44 <ganso> tbarron: nits shouldn't -1
15:48:53 <bswartz> spelling errors should be fixed -- that's what -1 is for
15:49:02 <mkoderer> markstur__: yeah I really like POC code in the same time with spechs
15:49:02 <bswartz> it's not hard to just fix it and move on
15:49:13 <gouthamr> or you can fix it if it's not too much of a bother?
15:49:23 <mkoderer> bswartz: I wouldn't block a merge just because two spelling nits
15:49:28 <tbarron> well I see a lot of negative energy going into that kind of thing
15:49:33 <bswartz> right we can always +2 over a -1
15:49:34 <tbarron> I do think we should fix them
15:49:47 <ganso> tbarron: they become obsolete
15:49:50 <bswartz> but that's doesn't mean we shouldn't post the -1 review
15:49:52 <tbarron> but note them as nits, fix, etc.
15:49:58 <ganso> tbarron: the documentation should be have perfect spelling
15:50:07 <ganso> tbarron: s/be have/have
15:50:13 <tbarron> ok, well we got that away.
15:50:17 <tbarron> out of the way -1
15:50:31 <gouthamr> ganso: true.. but what stops the reviewer from helping out and fixing the documentation for spelling errors?
15:50:37 <xyang2> bswartz: so we don't require spec to be merged before code merged?
15:50:50 <gouthamr> the docs team does this.. don't -1, just edit and help merge
15:50:55 <gouthamr> ^ if minor
15:51:10 <ganso> gouthamr: nothing, spelling mistakes are welcome to be pointed out, some people learn from it, but not worth -1
15:51:11 <bswartz> xyang2: not currently -- we could decide to change that (probably for ocata though given we're already well into newton)
15:51:21 <xyang2> ok
15:51:43 <tbarron> gouthamr: i like that b/c now when I do -1 it means something
15:51:48 <tbarron> but we can play the game either way :)
15:51:57 <bswartz> okay ganso: do you want to provide a link to your spec before we move on?
15:52:07 <ganso> bswartz: sure, thanks!
15:52:26 <ganso> #link https://review.openstack.org/315707
15:52:26 <gouthamr> tbarron: ofcourse, don't fix functionality, just fix 'teh' to 'the' or 'hence' to 'thus' :)
15:52:29 <bswartz> #action everyone review ganso's ^ spec!
15:52:52 <bswartz> #topic UI customization
15:53:11 <tbarron> sgotliv may have had to drop
15:53:13 <ganso> gouthamr: you don't like "hence" ? :(
15:53:13 <tbarron> late there
15:53:17 <tbarron> but
15:53:29 <tbarron> we have two issues where a customer has requested
15:53:38 <tbarron> more customizalbe ui.
15:53:48 <gouthamr> ganso: i've had US/british grammar checks happen wayy too often :)
15:53:52 <tbarron> they run a public cloud
15:54:08 <vponomaryov> tbarron: manila in public cloud? nice!
15:54:18 <tbarron> they down't want pulldowns for protocols that don't exist in their cloud
15:54:24 <bswartz> british english > US english
15:54:35 <ganso> bswartz: +1
15:54:37 * bswartz listens to the BBC too much...
15:54:38 <gouthamr> ^ well, i for one agree
15:54:48 <tbarron> if they don't have cifs of hdfs then they don't want their paying tenants to complain b/c they are in the ui and not availiable
15:55:04 <bswartz> #link https://etherpad.openstack.org/p/newton-manila-contributor-meetup
15:55:04 <gouthamr> tbarron: nice use case..
15:55:11 <tbarron> we have enabled_protocols in manila.conf so that seems a reasonable request to me.
15:55:16 <tbarron> any issue?
15:55:25 <bswartz> if you see in the etherpad, vponomaryov commented about the possiblity of a new API to support this use case
15:55:25 <vponomaryov> tbarron: no issue, I like idea
15:55:30 <ganso> tbarron: don't we already disable these through manila.conf ? "enabled_share_protocols" or something?
15:55:31 <gouthamr> tbarron: but i was under the impression people don't use vanilla manila-ui or manilaclient
15:55:41 <bswartz> I support the idea of the API
15:55:43 <vponomaryov> ganso: no APIs
15:55:51 <tbarron> gouthamr: they change the CSS sheet :-)
15:55:51 <vponomaryov> ganso: yet
15:56:04 <bswartz> it would be very useful for any tools built on top of manila to know which protocols are available
15:56:26 <tbarron> ok, we can work on that issue
15:56:29 <tbarron> #2.
15:56:35 <bswartz> tbarron: do we need anything more than that single API for that use case?
15:56:37 <cknight1> bswartz: It's possible now via the pools list API.
15:56:46 <cknight1> bswartz: The scheduler has all that information.
15:56:49 <bswartz> cknight1: that's admin only
15:57:01 <cknight1> bswartz: true
15:57:02 <bswartz> we need ordinary tenants to know which protocols are available
15:57:20 <bswartz> preferably without giving away all the pool details
15:57:33 <cknight1> bswartz: So what else might a user or GUI need to know?
15:57:55 <gouthamr> bswartz: scheduler stats can be improved, we only have GET pools and GET /detail on pools
15:58:01 <vponomaryov> cknight1: to know type of access and its level
15:58:08 <bswartz> perhaps a mapping of protocols to share types or share types to protocols in case not every protocol is compatible with every share type
15:58:18 <gouthamr> bswartz: we can easily add this tenant facing API to the same suite
15:58:39 <gouthamr> bswartz: or a filter to the existing API
15:58:48 <cknight1> bswartz: Point being, if we must add an API, we can design an extensible Manila capabilities API for adding such things.
15:59:01 <bswartz> or we could even make the protocol list just extra data on the share type list APIs
15:59:01 <tbarron> gouthamr: i think that's the way we were thinking
15:59:12 <tbarron> maybe we can do incremental refinement here
15:59:23 <tbarron> ready for #2?
15:59:25 <gouthamr> tbarron: agree..
15:59:31 <bswartz> we just return a list of supported protocols for each share type when you list the share types
15:59:37 <cknight1> tbarron: time check
15:59:41 <bswartz> then it's a change to an existing API instead of a brand new API
15:59:59 <ganso> tbarron: I am curious for #2
16:00:01 <tbarron> today when you create a share you get a make visible for all checkbox
16:00:02 <bswartz> altough I'm not sure we have the raw data for that anywhere
16:00:04 <tbarron> they want to be able to turn that off
16:00:05 <markstur__> there's a #2?
16:00:14 <gouthamr> beep beep beep
16:00:20 <gouthamr> 12:00
16:00:21 <tbarron> markstur__: yeah, i said 2 things
16:00:21 <ganso> gouthamr: lol
16:00:22 <markstur__> cliffhanger
16:00:28 <tbarron> continue in channel
16:00:31 <gouthamr> hahaa
16:00:32 <bswartz> okay
16:00:34 <bswartz> thanks all
16:00:34 <markstur__> to be continued...
16:00:35 <ganso> gouthamr: lunch time
16:00:36 <bswartz> we ran out of time
16:00:42 <bswartz> #endmeeting