15:00:25 <bswartz> #startmeeting manila
15:00:26 <openstack> Meeting started Thu Oct 20 15:00:25 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:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:30 <openstack> The meeting name has been set to 'manila'
15:00:42 <bswartz> hello all
15:00:43 <cknight> Hi
15:00:44 <markstur> hola
15:00:44 <ganso> hello
15:00:45 <ravichandran> hello
15:00:47 <vponomaryov> Hello
15:00:50 <toabctl> hey
15:00:53 <zengyingzhe> Hi
15:01:06 <dustins> \o
15:01:17 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:01:38 <bswartz> I dunno if some people have started traveling already
15:01:43 <bswartz> today's meeting should be short in any case
15:01:47 <ravichandran> Adding invalid user to the access rule changes existing valid access rules state from 'active' to 'error'.is this expected behavior ?
15:02:02 <bswartz> ravichandran: you're on the agenda, wait your turn
15:02:13 <bswartz> #topic  Specs and Deadlines
15:02:14 <ravichandran> SORRY
15:02:24 <bswartz> #link https://review.openstack.org/#/c/374883/
15:02:45 <bswartz> I've responded to all the feedback on this spec
15:03:04 <bswartz> ideally I'd like to merge it before we go to barcelona so I can announce deadlines
15:03:40 <bswartz> if anyone has any remaining issues with the proposal, please raise them now
15:03:54 <bswartz> otherwise I'd looking for two +2s
15:04:27 <bswartz> so regarding deadlines, that spec sets out the deadlines for specs themselves, and related features
15:04:41 <bswartz> however we have some other community deadlines
15:04:59 <bswartz> including the "new driver" deadline and the "major feature" deadline
15:05:19 <bswartz> I hope it's clear that the new spec process is indented to supercede the major feature deadline with a better process
15:05:36 <bswartz> so I intend to drop the major feature deadline
15:05:49 <bswartz> however the question of deadlines for new drivers remains
15:06:10 <bswartz> I feel the deadline we've had (feature freeze minus 3 weeks) has been working pretty well
15:06:43 <bswartz> so.... if there's no disagreement we'll keep that deadline too
15:06:54 * bswartz wonders if he's talking to himself
15:07:02 <ganso> bswartz: I am a bit confused, or I possibly missed the part where it says the new "major features" deadline, I thought it was only mentioning specs deadlines. Our "major feature" deadline refers to feature freeze
15:07:04 <kaisers_> na, listening ;)
15:07:38 <bswartz> ganso: for mitaka and newton we have a "major feature deadline" at feature freeze minus 6 weeks
15:07:45 <ganso> bswartz: and on a previous meeting, we established that the ocata major feature proposal deadline was before x-mas
15:07:50 <bswartz> s/have/had/
15:08:31 <bswartz> the new specs process is intended to cover all major features (as well as minor features)
15:08:46 <bswartz> oh yes I remember that
15:08:52 <bswartz> thank you for jogging my memory
15:09:59 <bswartz> ganso: do you have a reference to that discussion
15:10:11 <bswartz> we did agree on a date, and I need to make sure we keep that agreed date
15:10:21 <ganso> bswartz: let me head over to eavesdrop
15:11:01 <bswartz> #link http://eavesdrop.openstack.org/meetings/manila/2016/manila.2016-09-22-15.00.log.html
15:11:26 <ganso> bswartz: nice
15:11:44 <bswartz> #agreed driver proposal deadline Dec 19
15:11:52 <bswartz> that's from the previous meeting
15:12:14 <bswartz> I'll make sure that gets on the schedule
15:12:54 <bswartz> I don't think we cover major feature proposal freeze in that meeting
15:13:21 <bswartz> under the new specs process, there will be deadlines for the specs
15:13:54 <bswartz> if we agree to a spec but no code materializes, then we need a mechanism to push out those features too
15:14:08 <ganso> bswartz: ok so assuming a feature has a spec merged, its patch can be submitted up to which day?
15:14:29 <bswartz> well no later than Dec 19
15:14:47 <bswartz> but ideally even sooner than that
15:15:37 <ganso> bswartz: including very minor features that do not require specs, as stated in the specs' spec?
15:15:37 <bswartz> I'm worried we don't have enough people here to make a final decision
15:16:09 <bswartz> ganso: I updated the spec to imply that we expect specs for every feature
15:16:22 <bswartz> the only exception would be a "trivial fix" type of feature
15:16:37 <ganso> bswartz: o_O I guess I missed that part
15:17:07 <bswartz> the thinking is that no matter what we're implementing, it's best to hash out the details in a spec doc rather than code
15:17:17 <ganso> bswartz: no I did not. "Lastly, I propose that we require specs for any kind of change with broad impacts. It's better to agree on the design before we get too deep into implementation."
15:17:32 <ganso> bswartz: so, if it has no broad impact, does not require a spec, just a blueprint... right/
15:17:40 <bswartz> as we've been burned by features that had to be rewritten several times because we never agreed on a design up front
15:18:04 <bswartz> yeah if it's just a new config option in your driver, no spec
15:18:25 <bswartz> if you're implementing an existing interface in your driver, no spec
15:18:33 <ganso> bswartz: and if it is not driver-related?
15:18:36 <markstur> I thought you considered most driver features not spec-worthy
15:18:37 <bswartz> if you're modifying an REST API, then write a spec
15:18:47 <ganso> bswartz: I do not consider driver-related spec worthy
15:18:48 <markstur> nevermind you answered before I said it
15:19:10 <ganso> bswartz: but still some core features may have no broad impact
15:19:16 <bswartz> ganso: example?
15:19:35 <ganso> bswartz: a config option in the data service
15:20:04 <bswartz> ganso: yeah I would say certain config options could be added without specs
15:20:21 <vponomaryov> bswartz: Do any changes in testing approach require spec too?
15:20:35 <bswartz> however in some cases I could see long arguments about the some config options and those arguments are probably better to have in a document rather than the code
15:20:45 <bswartz> vponomaryov: I think not
15:21:02 <bswartz> testing is not features
15:21:09 <vponomaryov> bswartz: so, everything related to testing is separate kitchen?
15:21:23 <ganso> bswartz: couldn't those long arguments be discussed in the patch comments or a weekly meeting if the change is small enough?
15:21:33 <bswartz> vponomaryov: it just seems weird to write a spec about a testing approach
15:21:48 <vponomaryov> bswartz: not sure
15:22:05 <vponomaryov> bswartz: agreement on running some specific amount of functional and scenario tests may require spec
15:22:07 <bswartz> If we need to have a discussion and having a written document would help, then we *could* have a spec for testing, but we could just as easily handle those situations with wiki docs
15:22:16 <bswartz> vponomaryov: that's a good point
15:22:21 <vponomaryov> bswartz: because we will force people to update their third-party CIs in this case
15:22:51 <bswartz> if we're going to increase the burden on our 3rd party CI systems, then those discussion should be formalized and probably a spec is the best way to do that
15:23:07 <bswartz> ganso: yeah possibly
15:23:20 <bswartz> ganso: we'll have to use our judgement for stuff like that
15:23:35 <ganso> bswartz: I am starting to worry that we may get a big number of lower priority specs
15:23:55 <ganso> bswartz: because of statement "every feature, even small, requires a spec"
15:24:11 <ganso> bswartz: I was ok with "features with broad impact require a spec"
15:24:13 <bswartz> ganso: I'm imagining what a spec to add an option to the data service would look like -- and I'm thinking maybe 30 lines of text
15:24:31 <bswartz> that shouldn't be hard to review and agree to
15:24:42 <ganso> bswartz: concern is getting review attention to that spec
15:24:43 <bswartz> but you're right -- we don't want to go overboard
15:25:03 <ganso> bswartz: the same people could look at the code, if the feature is small enough, and discuss at the comments
15:25:24 <bswartz> okay so we have 2 open items
15:25:36 <ganso> bswartz: if we are trying to prevent effort wasted writing code, in this case, if it is small enough, we would be adding more effort, not saving
15:25:43 <bswartz> 1) date for major feature proposal freeze
15:26:05 <vponomaryov> ganso: +1 about efforts
15:26:05 <bswartz> 2) spec requirement for "small" features
15:26:30 <bswartz> since we're missing several key people today I propose we make those decisions next week and table them for today
15:26:47 <vponomaryov> let's allow people to upload code without spec if they are ok if it is not accepted for some reason
15:27:08 <vponomaryov> so, spec will be guarantee
15:27:17 <ganso> bswartz: I would like to add a candidate solution for #1: Dec 19. I see it as far back enough to include major features
15:27:45 <bswartz> I'm certainly okay with code that doesn't have specs but I don't want to end up with a sitation were we're disputing whether a feature has broad impact or not
15:28:06 <ganso> bswartz: I kinda agree with vponomaryov on this, maybe if we see that the feature is deserves a spec, we can say "-1, please write a spec"
15:28:37 <bswartz> ganso: I'm okay with that but depending on when that -1 happens, it could be too late to land in the release
15:29:02 <bswartz> then people will fight the request for a spec on the grounds that it pushes their change out of the release
15:29:11 <ganso> bswartz: indeed
15:29:29 <markstur> Need exception process for things that come in late and are needed
15:29:41 <bswartz> and that's exactly what we're trying to avoid -- we want people to just make their proposals early enough that we can make those decisions while being fully informed
15:30:31 <bswartz> okay I think we need to move on
15:30:44 <bswartz> I hope the wording in my spec is clear enough to merge
15:31:11 <bswartz> I haven't heard any argument against the "broad impact" language
15:31:36 <bswartz> we can update the spec deadline spec if we make more decisions to refine that cutoff
15:31:47 <bswartz> #topic Adding invalid user to the access rule changes valid access rule state from 'active' to 'error'
15:31:55 <bswartz> ravichandran: thank you for being patient
15:32:02 <bswartz> ravichandran: you're up now
15:32:10 <ravichandran> thank you
15:32:16 <ravichandran> Adding invalid user to the access rule changes existing valid access rules state from 'active' to 'error'.is this expected behavior ?
15:32:46 <ganso> ravichandran: I would say, yes, it is expected
15:32:47 <bswartz> ravichandran: you mean the backend doesn't recognize the user and fails to grant access
15:32:52 <bswartz> ?
15:33:29 <bswartz> I don't see any alternative other than putting the access rule state into error in that case
15:33:32 <ravichandran> If one rules fails for some reason like invalid user etc
15:33:48 <ravichandran> it changes all other rules state to error
15:33:51 <bswartz> I believe we need a better way to manage valid users for cifs shares, but that's sort of a separate problem
15:34:19 <bswartz> well no the only rule that should be in error state is the one with the invalid user
15:34:33 <ganso> ravichandran: right now, due to bad design, all access rules 'state' field value derivate on share_instance 'access_rules_status' field value
15:34:34 <bswartz> if other rules are going to error state that sounds like a bug
15:34:47 <bswartz> >_<
15:35:04 <ganso> ravichandran: there is a patch proposed to fix that
15:35:05 * bswartz admits being responsible for "bad design"
15:35:34 <ganso> ravichandran: #link https://review.openstack.org/#/c/369668/
15:35:42 <ravichandran> oh ok
15:36:04 <bswartz> yes that patch will improve things
15:36:06 <ganso> ravichandran: if that is your sole concern, you could checkout that patch and test if it solves your problem, and provide feedback on it whenever possible
15:36:13 <markstur> -1 needs a spec
15:36:18 <ganso> markstur: lol
15:36:33 <markstur> ganso: you think I'm joking?
15:36:40 <ravichandran> thank you ganso
15:36:41 <ganso> markstur: no lol
15:36:45 <bswartz> however I want to go further and find a way for manila to have some knowledge of the universe of valid users
15:36:46 <ravichandran> I will check
15:37:01 <bswartz> gouthamr: ^
15:37:03 <gouthamr> markstur: it's coming
15:37:12 <bswartz> :-)
15:37:20 <ravichandran> one more thing allowing user rule to NFS
15:37:39 <ravichandran> is not required
15:37:43 <ravichandran> correct ?
15:37:45 <bswartz> that's correct
15:38:09 <ravichandran> we may have to add that validation also to the ui and backend
15:38:11 <markstur> bswartz: list of known users sounds cool. Awesome if UI could allow selection -- but number of users could be too big for manila to know them all
15:38:12 <bswartz> NFS servers traditionally do access by IP
15:38:26 <gouthamr> it's something HPE can do... so far as my code reading goes
15:38:27 <bswartz> and individual files/directories have user ACLs
15:38:48 <bswartz> markstur: it gets complicated fast
15:39:08 <bswartz> markstur: but we've been avoiding it for too long and now it's causing problems for testing
15:39:29 <bswartz> so we need to think about how far we want to go towards solving that problem
15:40:01 <bswartz> ravichandran: no user access for NFS
15:40:04 <bswartz> just IP
15:40:14 <ganso> ravichandran: the case you mentioned could be applied for any protocol
15:40:14 <bswartz> anything else on this topic?
15:40:24 <ravichandran> no i am done
15:40:26 <markstur> gouthamr: HPE did only IP for NFS.  It was IP+user for CIFS, but IP is no longer required to make behavior more like other drivers.  It's a problem if we behave differently on that
15:40:50 <bswartz> markstur: correction: IP was NEVER required for CIFS, but we did have some drivers that supported it
15:41:16 <ganso> ravichandran: like, ok, for NFS no user rules, but what if another protocol accepts both, I believe we shouldn't have a mapping that says that hardcoded into manila, or even UI mechanism to behave differently for each protocol, the driver should determine what is compatible or not
15:41:31 <markstur> Yes. I thought it was a good thing -- but it is BAD if you don't know which backend you got and one need IP access and the other doesn't!
15:41:39 <gouthamr> markstur: oh.. yes, i got that the other way around
15:41:54 <vponomaryov> bswartz: we allow any type of a rule to any protocol via our interfaces
15:41:59 <vponomaryov> ravichandran: ^
15:42:07 <ravichandran> oh ok
15:42:10 <gouthamr> markstur: +1 - goes back to users being confused when they see the UI giving them all these options
15:42:37 <bswartz> so where this gets ugly is that share-server backends behave different from no-share-server backends
15:43:04 <bswartz> we went into depth on this topic at the midcycle
15:43:06 <markstur> gouthamr: User could create 2 share get 2 backends one works w/ user access, one doesn't (waiting for additional IP access) <-- that's not ideal  :(
15:43:13 <ganso> gouthamr: then I think we should come up with some guidelines on the use of protocols, we don't have such now
15:43:28 <bswartz> ganso: +1
15:43:45 <ganso> bswartz: there are a few drivers that accept more than one access type for a certain protocol, while other drivers that use that same protocol don't
15:43:47 <bswartz> I'd like to say NFS->IP access, CIFS->user access
15:43:50 <gouthamr> i wish we could re-write that portion, just like we have share capabilities.. when you create the share, the backend can tell us the supported access types and we can use that information in the API..
15:44:22 <markstur> We should start w/ what bswartz said ^ as the default behaovior
15:44:25 <bswartz> and other protocols just use whatever is appropriate
15:44:38 <markstur> Probably makes sense to extend it with capabilities at some point
15:44:57 <gouthamr> markstur: if we did that, what's the impact on the HPE driver?
15:45:14 <markstur> HPE driver already changed to do as bswartz prefers
15:45:23 <bswartz> gouthamr: you know he doesn't work for HPE anymore right?
15:45:44 <gouthamr> bswartz: i do :P i don't yet know who their driver maintainer is
15:46:03 <ganso> #link http://docs.openstack.org/developer/manila/devref/share_back_ends_feature_support_mapping.html
15:46:05 <ravichandran> its me
15:46:19 <bswartz> gouthamr: it's ravichandran
15:46:26 <gouthamr> okay, that clarifies, thanks ravichandran
15:46:36 <ravichandran> welcome
15:46:49 <bswartz> alright...
15:46:52 <bswartz> #topic open discussion
15:46:58 <bswartz> anything else for today?
15:47:10 <ganso> well we have not decided anything on the topic above, did we?
15:47:21 <gouthamr> does anyone have a fancy camera that they can bring to BCN? :)
15:47:43 <bswartz> ganso: we explained that NFS doesn't need user rules and CIFS doesn't need IP rules
15:48:00 <bswartz> and ravichandran will review gouthamr's change and see if it addresses his issue
15:48:23 <ganso> ok, are we going to come up with some validation or guidelines, will existing drivers have to change? (see link)
15:48:24 <bswartz> gouthamr: I have a shitty camera I will bring
15:48:26 <markstur> gouthamr: You mean like a polaroid?
15:48:27 <ganso> bswartz: ^
15:48:55 <gouthamr> i was looking beyond bswartz :P we didn't have a great webex experience from Austin
15:49:21 <bswartz> gouthamr: that's because we used google hangouts not webex in Austin IIRC
15:49:35 <gouthamr> i can host the webex/hangouts from our sessions.. but i was hoping we can use a good camera
15:50:35 <bswartz> ganso: which drivers doesn't support the minimum?
15:50:41 <gouthamr> bswartz: okay, we'll just use your 199x webcam xD
15:50:52 <ganso> bswartz: they support more than the minimum
15:51:07 <markstur> gouthamr: chat with hemna and diablo_rojo and maybe we can get live youtube channels like cinder did (know it is a stretch for barcelona, tho)
15:51:12 <ganso> bswartz: huawei's driver supports user for NFS, EMC isilon supports IP for CIFS
15:51:25 <markstur> ganso: ugh
15:51:25 <gouthamr> markstur: sure thing...
15:51:27 <bswartz> ganso: that's fine -- we can modify the manager to prevent those if we choose
15:51:32 <bswartz> the driver won't need to change
15:51:57 <ganso> bswartz: according to what gouthamr and markstur said, users that are unaware of the backends/drivers shouldn't have to see different behavior on certain shares
15:51:57 <bswartz> if a driver is missing minimum required access control then it will need to change
15:52:10 <bswartz> I plan to enforce that with scenario tests
15:52:32 <ganso> bswartz: but for instance, certain drivers probably create CIFS share without any access
15:52:56 <bswartz> ganso: yes we need to fix that
15:53:02 <markstur> bswartz: if that access rule is required it would be bad to block it in manager (don't know those, but that was my HPE way)
15:53:03 <bswartz> ganso: new shares should have no access
15:53:14 <ganso> bswartz: I asked my co-worker to add full IP access by default for CIFS shares, which is not done by default in the backend, so we wouldn't have to worry about this
15:53:42 <ganso> bswartz: I mean, CIFS shares would have full IP access, and require the user access to have access...
15:53:53 <ganso> bswartz: otherwise, they would require both access types to work
15:54:10 <markstur> No access by defualt should be a req.  More than 1 driver has run into that.
15:54:11 <bswartz> ganso: the requirement should be simple
15:54:30 <bswartz> for cifs shares, if I create a share, and grant access to a user, then mount as that user, it MUST succeed
15:54:46 <bswartz> it's not okay to also require some kind of IP based access too
15:55:06 <ganso> bswartz: yes, but some backends have IP + User access, where both need to be allowed so the client can mount the share
15:55:24 <ganso> bswartz: Hitachi HNAS for instance is like this
15:55:32 <ganso> bswartz: which is what I said above
15:55:39 <bswartz> it might be okay to further restrict access by IP, but the expectation from end users is that cifs shares should work with user access only
15:56:03 <ganso> bswartz: if we did not add full IP access in the driver when a CIFS share is created, a user access rule wouldn't be enough because the IP may not be allowed to mount
15:56:11 <bswartz> so the absence of any IP-based access rules must be interpreted as ALL IPs ALLOWED
15:56:30 <bswartz> ^ for CIFS shares
15:56:54 <bswartz> for NFS shares the absence of any IP-based access rules must be interpreted as nobody allowed
15:57:07 <bswartz> I think we need a spec here >_<
15:57:13 <bswartz> so we can have a proper argument
15:57:26 <ganso> bswartz: yes
15:57:38 <ganso> bswartz: that's what I meant that maybe some drivers would need to change
15:57:44 <bswartz> okay I agree
15:58:02 <bswartz> I'm hoping that scenario tests will make the expectations clear
15:58:39 <gouthamr> I'll include this into our access rules discussion at the summit
15:58:40 <bswartz> scenario tests will add user-access rules for CIFS shares and they won't add IP access rules, and scenario tests will expect that to work
15:59:07 <bswartz> the only open question for me is: how to we pick a user that we know will exist on both the client and the server
15:59:24 <bswartz> I think that's a solvable problem though
15:59:46 <bswartz> okay wer
15:59:51 <bswartz> okay we're out of time
15:59:56 <gouthamr> http://docs.openstack.org/admin-guide/identity-integrate-with-ldap.html
15:59:59 <gouthamr> :)
16:00:03 <bswartz> see you guys in spain next week!
16:00:13 <ganso> have a nice flight everyone
16:00:13 <bswartz> #endmeeting