15:01:01 <bswartz> #startmeeting manila
15:01:03 <openstack> Meeting started Thu Oct 22 15:01:01 2015 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:07 <openstack> The meeting name has been set to 'manila'
15:01:09 <cknight> Hi
15:01:12 <ganso> hello
15:01:21 <markstur_> hi
15:01:30 <bswartz> hello all
15:01:31 <bswartz> #topic announcements
15:01:38 <xyang1> Hi
15:01:43 <pchadwick> hello
15:01:55 <bswartz> there will be no manila weekly meeting next week, due to the Tokyo summit
15:02:32 <bswartz> the next meeting will be Nov 5
15:03:10 <bswartz> also, a reminder for those of you in the United States -- daylight savings time is ending so the meeting will be one hour earlier in your local timezone
15:03:31 <dustins> good to know
15:03:33 <bswartz> ^ that includes me
15:04:04 <bswartz> I'm sorry about the time markstur_
15:04:12 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:04:39 <bswartz> #topic Config Reference
15:04:48 <bswartz> markstur_: you're up
15:04:54 <markstur_> I just found out about https://wiki.openstack.org/wiki/Documentation/VendorDrivers#Vendor_Driver_Documentation
15:05:21 <markstur_> For the config-ref we need vendor page owners or else we have to just use templates that don't change much
15:05:27 <bswartz> markstur_: what is this?
15:05:51 <markstur_> For each vendor driver page in the config-ref we need an owner on this wiki
15:05:51 <bswartz> does it overlap with driverlog?
15:06:37 <bswartz> #link https://wiki.openstack.org/wiki/DriverLog
15:07:15 <bswartz> this feels like duplication of effort
15:07:37 <xyang1> Doc maintainer and driver log are two different repos
15:07:41 * bswartz wonders if there's a netsplit going on/ending
15:07:54 <bswartz> xyang1: okay thanks
15:08:02 <markstur_> This is for the doc team.  They don't want to be responsible for vendor details changing a lot
15:08:20 <markstur_> Anyway. For us we do need to make sure vendors own their config-ref pages.
15:08:43 <markstur_> What I got into Liberty didn't include the later changes in devref. So it is already behind.
15:08:46 <bswartz> so what is the docs team looking for? just an affirmative response from the responsible person?
15:09:21 <markstur_> Just a name/e-mail on that wiki so that if a doc bug comes in for that driver they can pass it on (I think)
15:09:30 <bswartz> yeah a few people asked me where the vendor docs should go at the end of Liberty and I told them we were moving to put the in the config ref but it wasn't ready for contributions yet
15:09:50 <markstur_> I mentioned it in some meetings, but it went in pretty fast.
15:10:21 <markstur_> It was basically W-I-P when it merged.
15:10:30 <bswartz> but it's ready now, correct?
15:10:46 <xyang1> markstur_: we are reviewing the doc for EMC drivers and will update if needed.  Thanks
15:10:55 <markstur_> There is a Liberty config-ref.
15:10:56 <bswartz> because I'd like to remove tall the user-facing docs from the manila tree so we have developer docs only
15:11:41 <markstur_> I need each driver to have an owner on that page.
15:11:57 <markstur_> Also the owner should look at the config ref and make sure their latest updates go in
15:12:16 <bswartz> yeah I agree
15:12:25 <markstur_> I put in a few names, but some of you have e-mail lists or someone else you want to own it.
15:12:27 <bswartz> markstur_ we probably need an ML post in addition to mentioning it here
15:12:46 <markstur_> I was thinking of volunteering vponomaryov for generic because he writes most of it.
15:12:49 <bswartz> and we need to chase down the few people who won't see the ML post and bug them directly
15:13:00 <markstur_> OK
15:13:19 <bswartz> vponomaryov: you okay with that?
15:13:37 <vponomaryov> bswartz: I lost almost all discussion, connectivity problems
15:13:41 <markstur_> Most of the rest is filled out but I wasn't sure which gluster e-mails to use.
15:14:08 <bswartz> vponomaryov: markstur_ volunteered you to be the maintainer of the generic driver config ref
15:14:32 <bswartz> it seems there is a netsplit on freenode today
15:14:36 <vponomaryov> in http://docs.openstack.org/liberty/config-reference/content/section_share-drivers.html ?
15:14:41 <bswartz> hopefully the bot is capturing this meeting log at least
15:15:12 <markstur_> vponomaryov, Yes. Doc team wants owners for vendor pages.
15:15:27 <vponomaryov> ok
15:15:30 <markstur_> We could probably move "generic" somewhere else, but it'd be good to give doc a contact.
15:15:31 <bswartz> vponomaryov: https://wiki.openstack.org/wiki/Documentation/VendorDrivers#Vendor_Driver_Documentation
15:15:40 <markstur_> Do we have anyone for Hadoop?
15:15:45 <bswartz> No, the generic driver is very important
15:15:53 <bswartz> it should be listed with the rest
15:16:07 <markstur_> Otherwise, I'll try to wrap that up and use the ML
15:16:14 <bswartz> markstur_: chen12 is not the right person but she sent me an email with a name I think
15:16:17 <bswartz> I can dig it up
15:16:23 <markstur_> Please look at the Liberty config-ref and add missing driver pages ur updates!
15:16:58 <bswartz> markstur_: weiting is the right person for HDFS driver
15:17:07 <markstur_> OK
15:17:29 <bswartz> although we should get him to confirm that he knows about the responsibility
15:17:47 <markstur_> I'll use e-mail to confirm.
15:17:57 <bswartz> markstur_: anything else on this topic?
15:18:02 <markstur_> Nope
15:18:34 <bswartz> #action markstur send ML post to remind vendors to sign up for config-ref maintenance for their drivers
15:18:42 <bswartz> #topic open discussion
15:18:49 <bswartz> okay that was the only thing on the agenda for today
15:18:52 <bswartz> anyone have anything else?
15:18:55 <ganso> markstur_: is HDS HNAS driver doc going to be moved to openstack docs as well?
15:19:09 <ganso> bswartz: there is minimum requirements subject
15:19:20 <ganso> bswartz: it is in the wiki page
15:19:42 <bswartz> oops
15:19:45 <bswartz> I had a stale wiki
15:19:51 <bswartz> #topic Minimum Requirements discussion
15:20:03 <bswartz> ganso: you're up
15:20:07 <ganso> bswartz: thanks
15:20:13 <bswartz> #link https://review.openstack.org/235914/
15:20:35 * bswartz reminds himself to refresh agenda wiki page when meeting starts
15:20:41 <ganso> in the link above, we have a doc proposal regarding minimum driver requirements
15:21:07 <ganso> at first it was only the minimum requires features, so snapshot and shrink share were going to be left out of that document
15:21:23 <ganso> then we changed that to include also optional features in the same document, in a different section
15:21:56 <ganso> but it has been brought up that experimental features may also be included in that document, also in a different section
15:22:20 <ganso> I would like to know what you guys think about that
15:22:43 <bswartz> yeah if we're documenting features and who supports what, I think it's very helpful to document the experimental ones
15:23:02 <markstur_> It's a very helpful document
15:23:17 <xyang1> ganso: very helpful, may be you should submit different patches on optional and experimental
15:23:17 <bswartz> I'm imagining that if a vendor wants to implement a new optional feature, they'll want to quickly find the existing implementations so they can borrow/copy some of the code
15:23:18 <markstur_> I think it is still not clear about how we deal with "minimum"
15:23:46 <markstur_> For existing drivers there are probably some issues in getting everyone up to the minumum
15:23:59 <bswartz> markstur_: I hope not!
15:24:23 <xyang1> We should ask all driver maintainers to take a look of the minimum features
15:24:26 <bswartz> which required feature is not implemented by an existing driver?
15:24:27 <ganso> bswartz: by "documenting who supports what", you mean like a feature support matrix? don't we already have that?
15:24:48 <cknight> bswartz: manage/unmanage is proposed as required, but not all have it.
15:25:04 <xyang1> On our side, Isilon team is still evaluating the doc and see if there is any requirement they cannot meet
15:25:07 <markstur_> Does it say all drivers to access-level rw/ro for all protocols.  I thought that was one example we weren't sure about.
15:25:28 <ganso> cknight, bswartz: Read-only access rule mode is not currently supported, and we are proposing as a minimum requirement as well
15:25:37 <bswartz> cknight: we've discussed though that a no-op implementation of manage/unmanage is valid -- so calling it required vs. optional is a funny distinction
15:25:46 <xyang1> markstur_: yes
15:26:09 <vponomaryov> also we should add driver capability for access levels - RW/RO
15:26:17 <bswartz> ganso: you're right I',m thinking about the other document too
15:26:22 <vponomaryov> if we make Ro optional
15:26:42 <markstur_> For thinks like RO, manage -- the main thing is we need to decide if/when it is required
15:27:05 <bswartz> okay we need to be clear for each feature what the requirement is, since it will vary from feature to feature
15:27:08 <markstur_> ... and does required mean pull the drivers at M, or just enter a bug, or just no-op
15:27:19 <ganso> markstur_: +1
15:27:30 <bswartz> for manage/unmanage, it just has to not blow up
15:28:03 <ganso> I think saying that "required for Mitaka release" is a good way of trying to get everything done for Mitaka, this decision has to be determined as soon as the release starts
15:28:18 <bswartz> markstur_: I'm in favor of pulling a driver that doesn't implement a required feature
15:28:48 <bswartz> otoh, if there's a good reason a driver can't implement a required feature, then it probably shouldn't have been required
15:29:02 <bswartz> maybe we need to have a specific discussion about read-only shares
15:29:07 <xyang1> Just like snapshot
15:29:37 <markstur_> So requiring manage/unmanage allows driver to just return notImplemented?
15:30:04 <bswartz> markstur_: we need to document that one carefully
15:30:22 <ganso> bswartz, markstur_: snapshot was a requirement before, and since we removed from minimum requirement, we also adjusted the interface to not show "Create Snapshot" button when snapshot support capability is advertised as "False". The consequence is that backends are not going to be so seamless for cloud providers, but they can be handled through share types.
15:30:22 <ganso> The same can be done for manage/unmanage.
15:30:29 <bswartz> there is indeed an implementation which is optional -- but the feature itself technically works on all backends
15:30:36 <markstur_> also for ensure_share because most of us just "pass" on that one
15:31:02 <xyang1> markstur_: same here
15:31:12 <bswartz> ensure_share isn't really a feature
15:31:20 <ganso> markstur_: NotImplemented() is different than reporting as a capability, and does not seem like a good idea
15:31:37 <bswartz> ensure_share is an opportunity for the driver to fix things that are broken
15:31:58 <bswartz> drivers can choose not to use it
15:32:00 <xyang1> NotImplemented will throw exception if called
15:32:31 <markstur_> This doc is a very good start, expecially for new drivers
15:32:42 <xyang1> markstur_: i think if you just pass, that is a no-op
15:32:55 <xyang1> markstur_: +1
15:33:15 <bswartz> https://github.com/openstack/manila/blob/master/manila/share/driver.py#L706
15:33:28 <bswartz> manage_existing throw an exception if you don't implement it
15:33:29 <markstur_> I'm not sure we have clarity on things that have to work or the driver gets removed
15:33:51 <bswartz> markstur_: I agree, and that's what ganso is trying to fix
15:34:25 <xyang1> https://github.com/openstack/manila/blob/master/manila/share/driver.py#L708
15:34:35 <xyang1> Unmanage is a no-op
15:34:53 <xyang1> Driver doesn't need to do anything
15:35:17 <bswartz> I think we can change manage_existing() to a different default behavior
15:35:51 <bswartz> but manage/unmanage is an easy case so I don't think we should spend much time one it
15:35:56 <bswartz> s/one/on/
15:36:05 <bswartz> we need to have the discussion about readonly support
15:36:27 <bswartz> and any other feature which we've said it required but we know of drivers that don't implement it
15:36:39 <vponomaryov> manage/unmanage can not be required feature because this feature works only with one of two possible driver modes and we allow to implement either one
15:37:16 <ganso> vponomaryov: what about "required if DHSS = false"?  :)
15:37:31 <bswartz> manage/unmanage is admin-only and it's no guaranteed to work even on drivers that do implement it, so I'm not too worried about that one
15:37:52 <bswartz> I'm much more concerned with end user features
15:38:15 <bswartz> we have an interest in making the end-user's experience as consistent and uniform as possible
15:38:54 <vponomaryov> bswartz: then RO is the main concern right now
15:38:54 <bswartz> let's plan on having this nailed down by the next meeting (in 2 weeks)
15:39:36 <bswartz> I want ganso's doc merged by that time and we should have a list of non-compliant drivers and a plan to get them fixed in Mitaka
15:39:56 <bswartz> after that there won't be any remaining concerns about whether drivers meet the minimum bar or not
15:40:30 <bswartz> so let's start the discussion right now
15:40:36 <bswartz> (assuming you're done with your topic ganso....)
15:40:45 <ganso> bswartz: yes
15:40:49 <bswartz> #topic read-only access
15:41:02 <bswartz> which drivers don't implement read-only yet?
15:41:09 <xyang1> Isilon
15:41:14 <bswartz> we know there is limitation with the generic driver and CIFS
15:41:27 <markstur_> 3par doesn't do read-only yet
15:41:33 <bswartz> xyang1: can Isilon implement it? is it a lot of work?
15:41:35 <vponomaryov> bswartz: Generic does not support Ro only for CIFS
15:41:50 <xyang1> bswartz: still waiting for them to get back to me
15:41:56 <vponomaryov> bswartz: at once with RW
15:41:57 <markstur_> for 3par I think it is easy for CIFS
15:42:31 <vponomaryov> http://docs.openstack.org/developer/manila/devref/share_back_ends_feature_support_mapping.html#mapping-of-share-drivers-and-share-access-rules-support
15:42:32 <bswartz> vponomaryov: we need to figure out if there's some way to work around that limitation
15:42:35 <markstur_> to do RO nfs shares is easy, but to do it per IP client is tricky.  I think it is possible
15:42:47 <markstur_> using 2 shares
15:43:21 <bswartz> markstur_ xyang1, do you think you can find out in the next 2 weeks whether it's possible or not to implement readonly support?
15:43:33 <xyang1> bswartz: should be
15:43:40 <bswartz> if the answer is yes, then it's just a matter of getting the work done in Mitaka
15:43:58 <markstur_> I can try.  I have an idea.  I'll have see if it is verifiable in 2 weeks.
15:44:02 <vponomaryov> bswartz: it is possible in generic driver, but we will have two different exports for both access types
15:44:18 <bswartz> if the answer is no.... then we need to question how wise it is to have it as a required feature
15:44:57 <bswartz> vponomaryov: if that's the only workaround that solve the problem, then we may need an API change to allow shares to have different export locations for rw and ro
15:45:07 <bswartz> it sounds like 3par might need a similar workaround
15:46:01 <bswartz> I have a topic for the friday meetup next week called export location metadata
15:46:21 <bswartz> part of my thinking for that proposal is to enables cases like this one
15:46:57 <bswartz> so I'll make sure to reference this discussion
15:47:33 <bswartz> okay I'll put an agenda item on the meeting 2 weeks from now to make a final decision on whether read-only access is required
15:47:45 <bswartz> #action bswartz put an agenda item on the meeting 2 weeks from now to make a final decision on whether read-only access is required
15:47:52 <bswartz> #topic open discussion
15:48:00 <bswartz> okay now does anyone have anything else
15:48:14 <xyang1> bswartz: for Friday's sprint, can someone at least write down the topics and conclusion?
15:48:52 <bswartz> xyang1: https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Manila
15:49:08 <xyang1> bswartz: cool
15:49:32 <bswartz> actually I made the export location metadata topic it's own working session
15:49:55 <bswartz> I should have checked the list before I said anything
15:50:13 <bswartz> anyways the etherpads have the topics, and we'll add notes right in the etherpads
15:50:22 <bswartz> one more thing I should mention
15:50:29 <xyang1> bswartz: thanks
15:50:54 <bswartz> I will attempt to create google hangouts for the design summit sessions, and provide audio/video if technology permits
15:51:18 <bswartz> links for those will go in the etherpads if we manage to make it work
15:51:30 <bswartz> I look forward to seeing you guys in Tokyo next week!
15:51:43 <xyang1> Who is going
15:51:57 <ganso> looking forward to seeing you guys too :)
15:52:08 * bswartz is going
15:52:26 <bswartz> cknight will be there too (I think he had to leave this meeting)
15:52:33 <markstur_> I can't make it
15:52:42 <vponomaryov> -1
15:52:44 <bswartz> markstur_: :-(
15:52:48 <dustins> Couldn't make it this time around :(
15:52:57 <cknight> I'll be there.
15:52:58 <markstur_> bswartz, +1 or -1 to agree with :(
15:53:05 <dustins> I hear Austin is nice in May, though :D
15:53:23 <xyang1> Lots of people couldn't make it:(
15:53:41 <xyang1> I am going, Jay Xu will be there too
15:53:54 <bswartz> for those that can't make it -- is it because of the time or the location?
15:54:01 <ganso> markstur_:  :(
15:54:13 <dustins> Location for me
15:54:14 <vponomaryov> location as a reason for budget
15:54:25 <markstur_> Cost.  And I think location suggests it'll be exensive.
15:54:46 <dustins> It's tough to send a large contingent of folks to a place half-way around the world
15:55:07 <bswartz> markstur_: my hotel in Tokyo is cheaper than my hotel was in Austin
15:55:19 <bswartz> maybe the food will be expensive...
15:55:19 <ganso> dustins: Austin is not going to be much easier for some people as well
15:55:23 <xyang1> bswartz: I got a good deal too
15:55:23 * bswartz is looking forward to sushi
15:55:33 <dustins> ganso: Indeed :(
15:56:15 <bswartz> okay thanks everyone
15:56:18 <bswartz> I think we're done
15:56:35 <bswartz> #endmeeting