15:02:24 <bswartz> #startmeeting manila
15:02:25 <openstack> Meeting started Thu Jul 10 15:02:24 2014 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:28 <openstack> The meeting name has been set to 'manila'
15:02:44 <bswartz> good morning/afternoon/evening
15:02:47 <tbarron> guten tag
15:02:47 <deepakcs> Hi all
15:02:47 <shamail> Hi everyone.
15:02:49 <cknight> Hi
15:02:49 <vponomaryov> hi
15:02:51 <scottda> Hi
15:02:52 <dustins> o/
15:02:53 <rraja> hi
15:02:59 <xyang1> hi
15:03:01 <ameade> o/
15:03:28 <bswartz> #link https://wiki.openstack.org/wiki/Manila/Meetings
15:03:49 <bswartz> fairly short agenda today
15:03:57 <bswartz> I don't have anything specific
15:04:23 <bswartz> I had a relaxing week off last week and I hope that those of you in the USA also did
15:04:33 <bswartz> #topic dev status
15:04:39 <bswartz> vponomaryov: you're up first
15:04:51 <vponomaryov> Ok, dev status:
15:05:02 <vponomaryov> 1) Manilaclient now supports python3.3 version and has caching of tokens
15:05:02 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/cache-auth-token
15:05:02 <vponomaryov> status: implemented
15:05:15 <vponomaryov> 2) Manila migrated from to oslo.messaging from oslo-incubator common code
15:05:15 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/oslo-messaging
15:05:15 <vponomaryov> status: implemented.
15:05:37 <vponomaryov> 3) share-server-delete API
15:05:37 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/add-admin-api-delete-share-server
15:05:37 <vponomaryov> gerrit: #link https://review.openstack.org/#/c/103911/
15:05:37 <vponomaryov> status: review in progress
15:05:57 <vponomaryov> 4) oslo.db
15:05:57 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/oslo.db
15:05:57 <vponomaryov> status: work in progress, no gerrit commit yet.
15:06:13 <vponomaryov> 5) Usage of common code in Manila
15:06:13 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/use-common-code
15:06:13 <vponomaryov> status: several changes has been merged, there are still field for work.
15:06:25 <vponomaryov> 6) py33 compatibility for Manila
15:06:25 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/py3-compatibility
15:06:25 <vponomaryov> status: several changes has been merged, there are still field for work.
15:06:38 <vponomaryov> 7) pep rules
15:06:38 <vponomaryov> lp bug: #link https://bugs.launchpad.net/manila/+bug/1333290
15:06:38 <vponomaryov> status: some changes has already been merged, lots of other on review
15:06:40 <uvirtbot> Launchpad bug 1333290 in manila "pep8 tests has a lot of disabled rules" [Medium,In progress]
15:07:04 <vponomaryov> That's all for status
15:07:11 <bswartz> okay
15:07:48 <bswartz> I think the next agenda item covers what I want to say about these
15:07:56 <bswartz> anyone have any questions about these bugs/bps?
15:08:41 <bswartz> okay next
15:08:50 <bswartz> #topic add-admin-api-list-shares-for-share-server
15:09:13 <bswartz> #link https://blueprints.launchpad.net/manila/+spec/add-admin-api-list-shares-for-share-server
15:09:13 <bswartz> - do we need it? (Can be useful for admins)
15:09:13 <bswartz> - if yes, should it be separated API? (Restriction - policy rules are different according to already existing API 'list')
15:09:13 <bswartz> - if yes, what name should be used for this API?
15:10:11 <bswartz> so we can have an optional, admin-only argument to share-create which addresses this use case, can't we?
15:10:15 <xyang1> what can we get today without this?  A list of all shares, right?
15:10:46 <bswartz> err share-list
15:10:50 <vponomaryov> xyang1: list of shares without filtering by share server id
15:11:03 <vponomaryov> xyang1: it can be list of tenant shares or all tenants
15:11:19 <xyang1> vponomaryov: thanks.  so this can be useful
15:11:22 <bswartz> ameade had an example for how to create policies for specific arguments of an API
15:11:37 <bswartz> we don't always need whole new APIs for admin-only stuff
15:11:49 <shamail> I think its a useful one, the admin-only argument addition to shares-list sounds like a good landing spot.
15:12:12 <bswartz> #link https://etherpad.openstack.org/p/filter-shares-list-by-share-server
15:12:27 <bswartz> that's what ameade wrote up
15:12:43 <bswartz> any reason we can't do something like this?
15:13:10 <xyang1> looks reasonable
15:13:15 <dustins> It seems easy enough to add
15:13:27 * ameade is lurking quietly
15:13:53 <vponomaryov> bswartz: having more than one policy for one API call is not obvious
15:14:22 <bswartz> vponomaryov: perhaps, but can't we document the sample policy.json to make it obvious?
15:14:29 <shamail> Does it make sense to list all shares by share server?  I might be reading the write up wrong but it looks like you need to specify share server the way it's currently documented?
15:14:39 <bswartz> and seriously, how often do people really edit policy.json?
15:14:51 <xyang1> vponomaryov: what do you mean more than 1 policy
15:14:59 <bswartz> I assume that 90% of people use the default and the other 10% make very few modifications
15:15:11 <xyang1> vponomaryov: list_shares_by_share_server only has 1 policy here?
15:15:15 <ameade> policies aren't usually 1 to 1 with api resources
15:15:36 <vponomaryov> xyang1: user side
15:15:57 <vponomaryov> xyang1: one CLI command will have two policies in that case
15:16:08 <xyang1> vponomaryov: I see
15:16:15 <ameade> vponomaryov: do you mean admin side? user has no idea there are even policies
15:16:25 <ameade> only the deployer would care
15:16:55 <vponomaryov> ameade: yes, user has no idea, but will get 403 with this option and 200 without it
15:17:06 <bswartz> I think it's not unusual to have an API with admin-only arguments -- the only way to achieve that is with 2 policies for that API
15:17:19 <ameade> why would a user even know about the option if they can't do it?
15:17:37 <ameade> and there is no harm saying "sorry, you dont have permission to perform this operation"
15:17:44 <vponomaryov> so, everyone agreed that this API should be implemented?
15:17:58 <bswartz> +1
15:18:16 <rraja> +1
15:18:22 <shamail> +1
15:18:29 <xyang1> vponomaryov: what about having the same API, but make the CLI look different so that it is obvious to user?
15:18:37 <ameade> just to be clear, we are saying to not add a new API resource for this right?
15:19:18 <bswartz> ameade: good point -- I think we're agreeing NOT to add a new API and we agreeing to add a new policy to the existing API
15:19:47 <xyang1> vponomaryov: one is share-list, the other one something like share-list-by-share-server?
15:20:06 <vponomaryov> ameade, bswartz: exactly - API method, share list does not have share-server list for now
15:20:32 <vponomaryov> s/share-server/share-server in/
15:20:35 <bswartz> xyang1: I don't see a need for an extra CLI
15:20:54 <vponomaryov> xyang1: this one I prefer that new option
15:21:01 <bswartz> I guess there is one question
15:21:14 <xyang1> bswartz: trying to address vponomaryov's concern on different policies
15:21:18 <bswartz> can we make the builtin help for the CLI show different options for admins and non-admins?
15:21:37 <bswartz> ideally tenants wouldn't see the option at all
15:21:59 <vponomaryov> bswartz: why?
15:22:13 <xyang1> bswartz: make the "help" clear is helpful too
15:22:14 <bswartz> if it's an admin-only option, tenants should not see it
15:22:19 <vponomaryov> bswartz: only if not implemented via horizon
15:22:20 <bswartz> only admins should see it
15:22:43 <bswartz> can't python-manilaclient show different help depending on the access of the person running it?
15:22:54 <vponomaryov> bswartz: can not
15:23:00 <bswartz> DOH!
15:23:18 <bswartz> I'd like to fix that
15:23:19 <vponomaryov> bswartz: client does know nothing about access
15:23:27 <bswartz> hmm
15:23:33 <vponomaryov> bswartz: only request and return of answer
15:23:42 <deepakcs> vponomaryov, dumb Q maybe... share-list can print the share-server column for admin only, isn't that enuf ?
15:24:01 <deepakcs> vponomaryov, I mean by default it will print always
15:24:06 <vponomaryov> deepakcs: there no share server in list
15:24:18 <ameade> deepakcs: there is no guarantee since someone could set the policy so that anyone can do it
15:24:29 <bswartz> yeah
15:24:40 <ameade> this is just a nice optimization
15:24:40 <bswartz> okay then perhaps a separate CLI is a good idea
15:24:47 <bswartz> but no separate API
15:24:53 <ameade> i dont think there is anything wrong with having a --share-server option in the CLI
15:25:11 <ameade> and it just says"sorry, you dont have permission to perform this operation"
15:25:17 <bswartz> it would be nice if python-manilaclient could obtain the policy from the server and modify the help accordingly but that's probably a lot of work for little gain
15:25:47 <cknight> ameade: agreed
15:26:15 <deepakcs> vponomaryov, there is no share server in list today, but the CLI will print share server also in the shares-list output if it being done by admin (without any new --share-server)
15:26:39 <bswartz> vponomaryov: can we move on?
15:26:41 <vponomaryov> deepakcs: idea in filtering
15:27:08 <vponomaryov> bswartz: yes, but we did not make decision
15:27:12 <deepakcs> vponomaryov, admin can do shares-list | grep <share server>
15:27:19 <bswartz> vponomaryov: that was what I was asking
15:27:46 <bswartz> I thought we decided
15:27:50 <bswartz> what is still unclear
15:28:05 <vponomaryov> deepakcs: grep is Ok for user, but we can minimize body of response
15:28:18 <deepakcs> vponomaryov, ok
15:28:22 <vponomaryov> deepakcs: and it is not for for server in that case
15:28:37 <vponomaryov> s/not for for/not ok for/
15:28:44 <vponomaryov> ok, lets move on
15:28:49 <deepakcs> ok
15:29:10 <bswartz> vponomaryov: you understand what we agreed to?
15:29:39 <vponomaryov> bswartz: did we agree?
15:29:54 <bswartz> okay
15:30:02 <bswartz> so here I was my understanding is
15:30:09 <bswartz> 1) we will NOT add a new API
15:30:26 <bswartz> 2) we will add an optional share-server argument to the share-list API
15:30:38 <bswartz> 3) we will add a second policy so that argument defaults to admin-only
15:31:29 <bswartz> how we handle the CLI is still unclear
15:31:38 <bswartz> but I thought we agreed on the server side API
15:32:30 <bswartz> okay
15:32:35 <vponomaryov> bswartz: ok
15:32:42 <bswartz> #topic Tempest tests for python-manilaclient
15:32:45 <bswartz> dustins: you're up
15:33:15 <dustins> Alright, so I was looking at the tempest tests for the manila client and saw that they only covered simple read only tests
15:33:24 <dustins> Same as all other python-*clients
15:34:14 <bswartz> okay
15:34:16 <dustins> I was wondering if there was a reason, other than scope, why we couldn't add more robust and thorough tests to test more than the read only operations
15:34:47 <dustins> #link http://docs.openstack.org/developer/tempest/field_guide/cli.html
15:34:55 <bswartz> dustins: seems like that would duplicate a lot of testing
15:35:32 <dustins> bswartz: How so? There are currently no CLI tests for the clients for anything other than read-only ops
15:36:03 <dustins> Sure, it'd just exercise the code that is already tested through the API, but we should be making sure the client talks to the API correctly
15:36:04 <bswartz> well 90% of any CLI test is testing that the server-side API worked properly
15:36:17 <bswartz> unless we use some kind of fake server
15:36:24 <scottda> One stated goal from the docs link is not to modify the cloud. So that would limit things to read-only
15:36:24 <bswartz> and we have tests that test the APIs directly
15:36:59 <dustins> Fair enough, I can get behind that
15:37:02 <bswartz> I'm not saying it's not worth doing, but we'd end up testing a lot of things twice
15:37:28 <dustins> right, and currently no one else is doing it either and it doesn't seem like there's going to be an effort to add it
15:37:39 <dustins> Probably because of that doubling of effort
15:38:13 <bswartz> the risk we're exposing ourselves to by not testing this stuff is that non-read-only operations in the CLI could end up sending the wrong API to the server or interpretting the results incorrectly
15:38:49 <vponomaryov> dustins: actually there one two layers in client - python code and shell code
15:39:03 <dustins> Exactly, but it seems like the other projects also take that risk, so we're not the first or last
15:39:16 <bswartz> in an ideal world we would cover these cases but I think we have higher priority testing issues
15:39:22 <dustins> vponomaryov: Right the CLI and the client itself, yeah?
15:39:35 <vponomaryov> dustins: yes
15:39:57 <cknight> vponomaryov: the client unit tests appear to cover the python code, but not the shell layer.
15:40:20 <cknight> vponomaryov: we were just wondering if that was in scope
15:40:24 <vponomaryov> cknight: it covers shell too
15:40:28 <bswartz> cknight: now you're talking about unit tests not tempest tests, right?
15:40:50 <cknight> bswartz: yes
15:41:10 <vponomaryov> cknight: not all, maybe, but covers
15:41:40 <cknight> vponomaryov:  ok, found it, thanks
15:41:43 <bswartz> if we had GOOD unit tests coverage of the CLI that would make me feel safer about having poor functional coverage
15:42:14 <cknight> bswartz: if the goal is not to test stuff twice, the unit testing in the CLI layers can accomplish that
15:42:15 <dustins> bswartz: and good functional coverage of the underlying API :)
15:42:41 <bswartz> I'm not against testing stuff twice unless it's really expensive
15:43:02 <cknight> bswartz: it's just that there isn't any thorough end-to-end functional test of the CLI in tempest, which was our question.
15:43:12 <bswartz> my point was that this seems low priority relative to more complete API tests
15:43:25 <cknight> bswartz: fair enough
15:43:36 <vponomaryov> cknight: this question is more to tempest-related meeting
15:43:51 <bswartz> cknight: I think you're right, and the rest of Openstack has the same flaw, so we won't rock the boat
15:43:59 <dustins> vponomaryov: Fair point
15:44:15 <cknight> vponomaryov: well, we're adding things to manila client now and wanted to get it right
15:44:41 <bswartz> dustins: you satisfied?
15:44:58 <dustins> bswartz: yup!
15:44:59 <bswartz> #topic open discussion
15:45:11 <vponomaryov> cknight: good unittests can help very well
15:45:12 <bswartz> anyone have something else to discusss?
15:45:47 <bswartz> xyang1: I can't remember if you had something to discuss today, based on our earlier conversation
15:46:13 <xyang1> bswartz: I don't have anything else to report.  we are still waiting for legal
15:46:20 <xyang1> bswartz: on driver contribution
15:46:23 <bswartz> okay if that's all, please remember to do code reviews
15:46:36 <bswartz> I'm doing my part, but I'm slow :-(
15:46:55 <bswartz> we have several changes that could benefit from some reviews
15:47:06 <bswartz> https://review.openstack.org/#/q/manila+status:open,n,z
15:47:14 <bswartz> okay I think that's it
15:47:16 <bswartz> thanks everyone
15:47:28 <xyang1> thanks
15:47:30 <vponomaryov> bswartz: jfyi: gerrit commit with share-server-delete API has db method required for update of 'list' API
15:47:57 <deepakcs> bswartz, any update on the incubation ?
15:47:57 <bswartz> #endmeeting