15:00:41 <bswartz> #startmeeting manila
15:00:41 <openstack> Meeting started Thu Jan 22 15:00:41 2015 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:46 <openstack> The meeting name has been set to 'manila'
15:00:56 <bswartz> hello
15:01:04 <u_glide> hi
15:01:05 <jasonsb> hi
15:01:06 <vponomaryov> hi
15:01:07 <rraja> hi
15:01:10 <xyang2> hi
15:01:21 <ganso_> hi
15:01:28 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:01:39 <cknight> Hi
15:01:44 <chen> hi
15:01:56 <bswartz> I'm going to reorder the agenda a bit
15:02:09 <bswartz> I want to start with
15:02:16 <marcusvrn_> Hi
15:02:16 <bswartz> #topic  Kilo-2 milestone review
15:02:34 <bswartz> #link https://launchpad.net/manila/+milestone/kilo-2
15:02:51 <bswartz> So we're 2 weeks way from kilo-2
15:03:19 <bswartz> there's a lot of content targeted at kilo-2 which is not done
15:03:28 <bswartz> and we need to start pushing stuff out if it's not ready
15:04:10 <bswartz> does anyone see stuff on the list that's definitely not happening?
15:04:15 <tbarron> hi
15:04:40 <ganso_> yes
15:04:40 <bswartz> or anything here that's not properly updated?
15:04:54 <jasonsb> i'll submit driver after this meeting
15:04:57 <vponomaryov> bswartz; several bugs for cdot driver
15:05:03 <bswartz> if there's a change in gerrit, it should be in Needs Code Review
15:05:39 <bswartz> for anything that's not ready for code review today, its chances of slipping to K-3 increase every day
15:06:23 <cknight> vponomaryov: let's hold off the cDOT driver bugs until the refactor is merged
15:06:28 <bswartz> vponomaryov: you think those bugs won't get fixed or they will?
15:06:44 <vponomaryov> bswartz: they won't , some of them just as notification
15:06:52 <bswartz> ok
15:07:09 <ganso_> my driver will not be targeted to kilo-2 anymore
15:07:17 <bswartz> anyone who owns a blueprint that's not ready for review, expect me to ping you
15:07:35 <marcusvrn_> We will update the bp
15:07:37 <bswartz> I'm going to just retarget stuff if I can't get a good answer
15:07:56 <jasonsb> ganso_: marcusvrn_ :(
15:08:17 <bswartz> and just so there's no confusion, it's okay if stuff slips to Kilo-3
15:08:29 <bswartz> but if Kilo-3 gets too much content, the reviews might get overloaded
15:08:36 <bswartz> reviewers*
15:08:46 <bswartz> and new features CANNOT slip past kilo-3
15:09:09 <bswartz> so do us all a favor and get your changes in early
15:09:38 <bswartz> and do me a favor and update your BPs/bugs in launchpad sometime in the next 50 minutes
15:09:45 <xyang2> I see there are things already merged but still marked need code review: https://blueprints.launchpad.net/manila/+spec/huawei-manila-driver
15:09:55 <bswartz> xyang2: I know
15:10:14 <bswartz> that's why this list needs a cleanup so we can assess where we really are relative to the K-2 date
15:10:35 <bswartz> I'm going to do my best to sort it all out but help is appreciated
15:10:44 <bswartz> any questions about K-2 before we move on?
15:11:23 <bswartz> #topic dev status
15:11:37 <bswartz> okay now lets get an update from vponomaryov
15:11:50 <vponomaryov> Dev status:
15:11:56 <vponomaryov> 1) Rename of driver modes
15:12:00 <vponomaryov> BP: #link https://blueprints.launchpad.net/manila/+spec/rename-driver-modes
15:12:06 <vponomaryov> gerrit: #link https://review.openstack.org/147821
15:12:11 <vponomaryov> status: finished
15:12:15 <vponomaryov> 2) Single_svm mode for Generic driver
15:12:19 <vponomaryov> BP: #link https://blueprints.launchpad.net/manila/+spec/single-svm-mode-for-generic-driver
15:12:22 <vponomaryov> gerrit: #link https://review.openstack.org/142403
15:12:27 <vponomaryov> status: ready for review
15:12:32 <vponomaryov> 3) Manage/unmanage shares
15:12:36 <vponomaryov> BP: #link https://blueprints.launchpad.net/manila/+spec/manage-shares
15:12:39 <vponomaryov> gerrit: #link https://review.openstack.org/147495
15:12:43 <vponomaryov> status: work in progress
15:12:47 <vponomaryov> 4) Share access levels 'ro' and 'rw'
15:12:52 <vponomaryov> BP: #link https://blueprints.launchpad.net/manila/+spec/level-of-access-for-shares
15:12:58 <vponomaryov> gerrit:
15:12:58 <vponomaryov> - client #link https://review.openstack.org/144298
15:12:58 <vponomaryov> - server #link https://review.openstack.org/144617
15:13:02 <vponomaryov> status: ready for review
15:13:08 <vponomaryov> 5) level of visibility for shares
15:13:12 <vponomaryov> BP: #link https://blueprints.launchpad.net/manila/+spec/level-of-visibility-for-shares
15:13:17 <vponomaryov> gerrit: #link https://review.openstack.org/148853
15:13:18 <vponomaryov> status: work in progress
15:13:25 <vponomaryov> that's the main
15:13:41 <xyang2> should some blueprint be renamed now? BP: #link https://blueprints.launchpad.net/manila/+spec/single-svm-mode-for-generic-driver
15:13:51 <bswartz> xyang2: good point
15:14:09 <vponomaryov> does it matter?
15:14:20 <xyang2> It adds confusion:)
15:14:31 <bswartz> I'm personally okay with leaving the name, but people looking back from the future might not understand what we meant
15:14:53 <bswartz> what would be a better name?
15:14:57 <vponomaryov> we can not guarantee understanding in any case
15:15:13 <bswartz> generic-driver-without-share-servers?
15:15:25 <xyang2> sounds good to me
15:15:33 <bswartz> no-share-server-generic-driver?
15:15:41 <ganso_> maybe just match it with the current one so people know it is related
15:15:42 <bswartz> I dunno
15:15:58 <nileshb> earlier is better
15:16:07 <nileshb> generic-driver-without-share-servers
15:16:09 <bswartz> vponomaryov: rename it if you wish
15:16:22 <lpabon> imo, i think the paragraph describing the blueprint could be reworded.  That would probably fix the issue
15:16:35 <bswartz> yeah it's more important that the blueprint content makes sense than the blueprint name
15:16:59 <bswartz> names are just arbitrary tags, but the content should actually be clear
15:17:09 <xyang2> at least explain in the blueprint and commit message what this means
15:17:15 <bswartz> +1
15:17:38 <bswartz> okay moving on
15:17:47 <bswartz> #topic Manila Midcycle Meetup (virtual)
15:18:06 <bswartz> so many of you are probably aware of various midcycle meetups happening for different projects
15:18:28 <bswartz> most of them are actual physical meetups, and they're usually very awesome and productive
15:19:02 <bswartz> we talked about doing something similar with this team, but travel is difficult for many of us
15:19:11 * lpabon has been to one for Swift.  Very cool
15:19:11 <bswartz> so I'm proposing that we do a virtual meetup
15:19:53 <markstur_> +1
15:20:03 <ganso_> bswartz: +1
15:20:06 <lpabon> sounds good.  Something like Google Hangouts?
15:20:06 <chen> +1
15:20:14 <bswartz> The format would be a google hangout open to everyone, with possibly a telephone bridge for bringing in more people with audio only
15:20:52 <bswartz> I'm thinking we would do a few 4-hours sessions across 2 or 3 days
15:21:00 <marcusvrn_> bswartz: +1
15:21:02 <bswartz> people could join all of them or some of them
15:21:12 <xyang2> there's a limit on number of people on google hangout, right?
15:21:14 <bswartz> the main question is which days and which timeslots
15:21:20 <bswartz> xyang2: with the free version the limit is 10
15:21:21 <lpabon> fyi, the Ceph team is very experienced in doing virtual meetups.  If you need any help or feedback
15:21:28 <bswartz> I think you can pay for a higher limit
15:21:54 <lpabon> I may be able to use BlueJeans
15:22:00 <lpabon> I think the limit there is 99
15:22:28 <lpabon> Its what Google uses in the background anyways :-)
15:22:34 <jasonsb> is there possibility of meatspace meetup too?
15:22:40 <bswartz> anyways, I'm thinking that UTC 1300-1700 is a timeslot that should work for most people
15:23:20 <bswartz> if there anyone for whom that's a bad time?
15:23:34 <markstur_> very early for me in California
15:23:40 <nileshb> little earlier would be better for India, China
15:23:45 <chen> very late in China
15:23:53 <bswartz> yeah I was going to say that that time is terrible for california
15:24:13 <bswartz> this is the main challenge with a virtual meetup -- whatever time you choose, someone is sleeping
15:24:20 <markstur_> yep
15:24:36 <cknight> markstur_: you'd be welcome in NC for the event
15:24:41 <vponomaryov> we have whole world here =)
15:25:07 <lpabon> i always have issues matching california to India/China time.  One of those will always have a hard time
15:25:08 <bswartz> yeah we have several people in north carolina, and NetApp would be happy to host anyone who wants to join physically
15:25:11 <markstur_> I'd go to Hawaii, but that won't help.  I suppose I could get up early a few days
15:25:51 <bswartz> We could do some sessions at different times to accommodate different groups
15:26:00 <jasonsb> hawaii is nice idea
15:26:08 <bswartz> but if there's not a time everyone can join then we lose some of the value
15:26:35 <markstur_> can it be recorded?
15:26:48 <markstur_> still loses value, but might help
15:27:05 <lpabon> google supports recording to YouTube
15:27:10 <bswartz> markstur_: probably, but who would want to sit through 4 hours of recorded audio?
15:27:25 <bswartz> the value of a meetup is mostly when it's live
15:27:41 <bswartz> we would definitely collect minutes on an etherpad for those who were unable to join
15:27:54 <lpabon> fyi, the Ceph team records it, then marks each part of the session from a wiki, for those who want to watch it later.  Each small session is about 30 mins
15:28:02 <bswartz> interesting
15:28:20 <xyang2> lpabon: how long is their meetup?
15:28:37 <bswartz> well time is running out during Kilo for this really to be a "mid-cycle" thing so I'd like to do it in the next 2-4 weeks
15:28:55 <bswartz> next week is the cinder meetup and we don't want to conflict with that
15:28:56 <lpabon> I don't exactly remember, but i think it is about 4 hours spread across two days.. let me find a link
15:29:41 <bswartz> I'm sensing that there's a lot of interest though, which is good
15:30:16 <bswartz> #link https://etherpad.openstack.org/p/manila-kilo-midcycle-meetup
15:30:22 <bswartz> I just created this etherpad
15:31:18 <bswartz> To collect a list of people who are interested in joining
15:31:25 <vponomaryov> bswartz, maybe better write time slots?
15:31:33 <bswartz> well
15:31:35 <vponomaryov> that are suitable
15:32:06 <bswartz> I think we're just going to have to pick timeslots that are bad for the fewest number of people
15:32:21 <nileshb> time-slots - converted to UTC
15:32:37 <bswartz> my intuition is that morning eastern time is the best, excepting people in pacific timezone
15:32:46 <bswartz> for them we could do an afternoon session
15:33:04 <lpabon> #link https://wiki.ceph.com/Planning/CDS/CDS_Giant_and_Hammer_(Jun_2014)
15:33:14 <lpabon> Example of virtual summit
15:34:10 <bswartz> hmm
15:34:22 <bswartz> I think EST is actually UTC-5 not UTC-4
15:34:37 * bswartz hates daylight savings time
15:35:18 <bswartz> how about dates
15:35:34 <bswartz> I would lean towards a Tuesday, Wednesday, or Thursday
15:35:41 <xyang2> bswartz: I thought you took daylight savings into account:)
15:35:42 <bswartz> maybe 2 days
15:35:59 <bswartz> xyang2: I always get it backwards though
15:36:07 <xyang2> lpabon: that looks very well organized
15:36:21 <bswartz> EST is UTC-5 and EDT is UTC-4
15:36:47 <lpabon> xyang2: Yeah, they really do a great job.
15:36:53 <bswartz> wow
15:37:13 <bswartz> yeah they have a planned agenda down to the 15 minutes
15:37:34 <xyang2> it is really a conference rather than just a meetup
15:38:07 <lpabon> True, it is more like themes to discuss, each one with a lead
15:38:29 <bswartz> My main goals for the meetup would be to talk about changes targeted at K-3 and to answer questions, to try to expedite getting all the content merged
15:38:37 <lpabon> most are 30m
15:38:50 <bswartz> we could have a bug squashing session
15:38:57 <bswartz> perhaps some presenatations
15:39:24 <bswartz> anyways, expect to hear more from me
15:39:38 <bswartz> I'll try to get a date time set ASAP so anyone interested in travelling can make arrangements
15:40:12 <bswartz> next topic
15:40:19 <bswartz> #topic Share manage/unmanage (redux)
15:40:37 <bswartz> so there was a lot of discussion on this topic last week
15:41:10 <bswartz> where we settled was that we will only implement share manage/unmanage for single_svm (driver_manages_share_servers=False) backends intially
15:41:24 <bswartz> because that case is a lot more straightforward
15:42:00 <bswartz> I still hope to someday have a way to manage/unmanage whole share_servers for multi_svm (driver_manages_share_servers=True) backends someday, but that's a much harder problem
15:42:35 <bswartz> I just wanted to bring this back up for discussion in case anyone had strong feelings about this or questions
15:43:18 <chen> implement share manage/unmanage for single_svm (driver_manages_share_servers=False) backends doesn't looks useful
15:43:42 <chen> why would user wants that ?
15:44:29 <chen> driver_manages_share_servers=False already request admin prepare everything
15:44:56 <chen> why not add these shares at do_setup in driver directly
15:45:21 <chen> If I'm the admin, I would not like to add shares by hand one by one
15:45:31 <bswartz1> I'm back
15:45:38 <bswartz1> sorry my connection dropped
15:45:47 <ganso_> chen: currently there is no way to register existing shares to a share server
15:46:01 <markstur_> chen, I'd want to be able to add a share (when not so many)
15:46:05 <bswartz1> the last I saw was chen's question
15:46:09 <u_glide> chen: with manage/unmanage admin can choose which to add (manage) and which to unmanage
15:46:26 <ganso_> chen: if adm is creating share server manually, he may want to register existing shares too
15:46:33 <bswartz1> chen: the use case is taking an existing NAS server and bringing it under the management of Manila
15:46:37 <markstur_> unmanage/manage is also what most apps would call export/import
15:46:54 <markstur_> so that is useful too
15:46:55 <u_glide> without changing manila db manually
15:48:00 <bswartz> perhaps the BP for manage/unmanage needs to be more clear about the use case and how it works
15:48:18 <u_glide> bswartz: I will update it
15:48:32 <bswartz> chen: do you understand now?
15:48:46 <chen> I understand the behavior
15:48:58 <bswartz> I sort of assume that most of you are familiar with cinder and how manage/unmanage works for that project
15:49:03 <chen> just not very useful for driver_manages_share_servers=False dirver
15:49:07 <bswartz> okay
15:49:35 <bswartz> chen: having the features is way better than not having the feature, and this is the easier case to implement
15:49:48 <chen> bswartz, ok.
15:50:04 <bswartz> if someone wants to design a solution for the harder case, please do
15:50:33 <bswartz> #topic Manila image project
15:50:42 <bswartz> I put this on the agenda last week and we didn't get around to it
15:50:59 <bswartz> I just wanted to call attention to the thread on the openstack-infra ML about this
15:51:12 <bswartz> and thank csaba for driving it
15:51:35 <bswartz> not many cycles have been spent on this because it hasn't been a high priority
15:51:35 <csaba> bswartz: np
15:52:00 <bswartz> I'm now curious if the project referenced in that thread will be any help to us at all
15:52:19 <bswartz> diskimage-builder
15:52:31 <bswartz> I certainly hate duplicating work
15:52:49 <bswartz> but I worry that the goals of diskimage-builder don't match with what we're trying to achieve
15:53:24 <bswartz> maybe we'll get to that in kilo-4....
15:53:36 <bswartz> heh
15:53:41 <bswartz> #topic open discussion
15:53:46 <bswartz> okay anyone have something else?
15:54:30 <bswartz> if not, go update your blueprints in LP right now
15:54:49 <csaba> bswartz: I'd have liked to answer to image project topic once you finish with the lead-up but you switched topic right after lead-up ")
15:55:04 <bswartz> csaba: go ahead
15:55:46 <csaba> so just links FYI #link http://lists.openstack.org/pipermail/openstack-infra/2015-January/002319.html original post
15:55:56 <csaba> #link http://thread.gmane.org/gmane.comp.cloud.openstack.infrastructure/2308 gmane whole thread
15:56:22 <csaba> so basic problem here was not technical but legal -- what licensing considerations would the project face?
15:56:34 <csaba> and answer to that seems to be: basically none
15:56:51 <csaba> ie. there is no APLv2 enforcement on stackforge
15:57:02 <bswartz> yeah it sounds like everyone is okay with us using the GPL license for that project as long as it's not destined for defcore
15:57:02 <csaba> we can go with any FLOSS license
15:57:28 <csaba> that was just something to clear beyond getting to make technical decisions
15:57:45 <csaba> and that goal was reached, I feel
15:57:58 <csaba> s/beyond/before/
15:58:32 <csaba> that's my summary
15:58:35 <bswartz> alright I think that's it for today
15:58:41 <bswartz> thanks csaba
15:59:01 <bswartz> reminder to sign up on https://etherpad.openstack.org/p/manila-kilo-midcycle-meetup so I can make some plans
15:59:16 <bswartz> I'll follow up on the ML for midcycle meetup stuff so we don't have to wait until next week
15:59:25 <bswartz> #endmeeting