15:02:34 <bswartz> #startmeeting manila
15:02:35 <openstack> Meeting started Thu Jun  2 15:02:34 2016 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:38 <openstack> The meeting name has been set to 'manila'
15:02:41 <cknight> Hi
15:02:43 <mkoderer__> hello
15:02:43 <toabctl> hey
15:02:44 <gouthamr> hello o/
15:02:45 <rraja> hi
15:02:45 <dustins> \o
15:02:45 <tbarron> hi
15:02:47 <ganso> hello
15:02:47 <dgonzalez> Hi
15:02:47 <vponomaryov> hello
15:02:50 <zhongjun_> hello
15:02:50 <markstur_> hi
15:02:52 <xyang> hi
15:03:01 <Yogi1> Hi
15:03:05 * bswartz curses slow internet
15:03:35 <vkmc> hi o/
15:03:39 <bswartz> #topic N-1 milestone
15:03:40 <gouthamr> bswartz: disconnect your dot matrix printer
15:03:47 <bswartz> gouthamr: lol
15:03:53 <bswartz> that was a joke
15:04:05 <gouthamr> :)
15:04:27 * dustins ponders if you can easily buy paper for those still
15:04:36 <markstur_> always a glitch in the dot matrix printer
15:04:39 <bswartz> so due to lots of distractions I haven't cut the N-1 milestone yet
15:04:49 <bswartz> but I'm going to today
15:04:58 * ganso wonders if only he is not seeing any messages
15:04:58 <bswartz> any changes that need to be in?
15:05:14 <bswartz> ganso: we can see messages
15:06:12 <bswartz> okay I'm going to assume we're all good with N-1 and push the milestones then
15:06:23 <bswartz> I had hoped more specs would be merged by now
15:06:32 <bswartz> but we can continue to wrap those up in N-2
15:06:40 <ganso> bswartz: I am getting a lot of lag :(
15:06:49 <bswartz> I'm actually pleased with the amount of specs and the amount of detail in them
15:06:59 <vponomaryov> ganso: you have printer too? ))
15:07:02 <bswartz> I think we need more reviews though
15:07:27 <mkoderer__> we need to priotize spec reviews
15:07:57 <bswartz> I'm blaming my core router for the slowness -- I'll debug it later today
15:08:37 <bswartz> let's move on to important things
15:08:44 <bswartz> #topic Decision on APIv1 removal for newton
15:08:56 <bswartz> we discussed this last week
15:09:18 <bswartz> it's been deprecated long enough
15:09:35 <bswartz> the question is whether it's more effort to keep v1 in or take it out
15:10:06 <bswartz> and also if there are any compelling ${reasons} to keep it other than general angst about breaking old things
15:10:11 <vponomaryov> keep means continuous maintenance, it is endless
15:10:27 <bswartz> I think we mostly leaned towards taking it out now
15:10:55 <bswartz> vponomaryov: removing things takes effort too, and we'll never stop removing things
15:11:26 <vponomaryov> bswartz: it is less amount of efforts in long term
15:11:33 <vponomaryov> anyway
15:11:35 <gouthamr> vponomaryov: when you say continuous maintenance, do you mean we need to maintain CI support for the v1 API? Do we, today?
15:11:36 <bswartz> did anyone think of a good reason to keep v1 in the last week?
15:11:55 <vponomaryov> gouthamr: we run lots of tests using v1 in tempest
15:12:21 * bswartz forgets the vote syntax as usual
15:12:22 <ganso> bswartz: the only good reason I thought about if effort to maintain it is None
15:12:23 <tbarron> ganso had a customer that he was going to check on?
15:12:53 <mkoderer__> just #vote ?
15:12:59 <gouthamr> vponomaryov: oh.. shares_client uses v1 routes? #TIL
15:13:01 <ganso> tbarron: yes, but the customer will also upgrade everything to liberty, and liberty is still V1 compatible
15:13:08 <vponomaryov> gouthamr: yes
15:13:18 <bswartz> #startvote Fate of the v1 API in newton? Remove, Keep
15:13:19 <tbarron> ganso: k, customers were my only concern
15:13:19 <openstack> Begin voting on: Fate of the v1 API in newton? Valid vote options are Remove, Keep.
15:13:20 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
15:13:34 <gouthamr> #vote Remove
15:13:38 <dustins> #vote Remove
15:13:44 <zhongjun_> Maybe we could put this in maillist and let more people to know this change? Get more feadback about whether there are any strong objections?
15:13:45 <vponomaryov> #vote Remove
15:13:48 <xyang> #vote Remove
15:13:50 <cknight> #vote Remove
15:13:58 <markstur_> #vote Remove
15:14:03 <zhongjun_> my #vote Remove
15:14:07 <toabctl> #vote Remove
15:14:21 <bswartz> 20 more seconds
15:14:48 <bswartz> #endvote
15:14:49 <openstack> Voted on "Fate of the v1 API in newton?" Results are
15:14:50 <openstack> Remove (7): toabctl, gouthamr, xyang, cknight, vponomaryov, markstur_, dustins
15:14:58 <bswartz> it is decided!
15:15:03 <bswartz> who wants to push the patch to remove it?
15:15:21 <cknight> bswartz:  I nominate vponomaryov
15:15:23 <gouthamr> bswartz zhongjun_'s right... maybe there are some clients out there that we don't know about, mailing list will give them a head start that v1 is removed in newton..
15:15:30 <bswartz> zhongjun_: btw your vote wasn't counted
15:15:54 <bswartz> yes definitely I'll do a ML post about it
15:16:07 <tbarron> +1
15:16:10 <bswartz> the N release is still 4.5 months away
15:16:16 <mkoderer__> dgonzalez: we do have to update openstack4j, right? ;)
15:16:37 <dgonzalez> That's already happening
15:16:46 <mkoderer__> dgonzalez: ok
15:16:58 <bswartz> vponomaryov: do you feel comfortable writing the patch to remove v1?
15:16:58 <gouthamr> mkoderer__ dgonzalez: you're using v2 :)
15:17:09 <vponomaryov> bswartz: yes
15:17:17 <vponomaryov> bswartz: it will be not one patch
15:17:24 <xyang> bswartz: if any customer is using it, I’m pretty sure he/she will vote for No.  I don’t know if ganso’s customer is following the ML
15:17:39 <bswartz> we can remind everyone that v2.0 is identical to v1 and v2.1 is where we started making changes
15:17:40 <vponomaryov> bswartz: first step - remove usage, and I am aware about that OpenStack Rally uses v1 still
15:18:24 <bswartz> although v2.0 does require use of microversions
15:18:33 <ganso> xyang: it is fine, I am working it out with the customer :)
15:18:41 <xyang> ganso: ok:)
15:18:54 <bswartz> alright I think we can move on
15:19:07 <bswartz> #topic Model updates from drivers
15:19:19 <bswartz> This is a topic that we started last week but ran out of time for
15:19:55 <bswartz> I think the idea was generally understood
15:20:05 <mkoderer__> bswartz: is there a spec?
15:20:07 <bswartz> But we have no spec for it, an no implementer
15:20:13 <mkoderer__> ok ;)
15:20:26 <bswartz> mkoderer__: no -- I was looking for early feedback which might influence the spec
15:20:37 <zhongjun_> Is there a link to show this bug in launchpad?
15:20:49 * mkoderer__ needs to read the old meeting logs
15:21:01 <xyang> bswartz: I’m very hesitant on making this change, given how strongly we advocated not to do any db update from driver in the past
15:21:05 <bswartz> zhongjun_: this isn't a bug, it's a proposal to change the driver interface significantly
15:21:41 <bswartz> xyang: the goal of this proposal is to retain the level of safegaurds we have today on drivers hacking the DB
15:21:51 <zhongjun_> bswartz: Oh
15:21:53 <bswartz> however there are unavoidable problems with the current approach
15:22:49 <mkoderer__> I am a big fan of not having any driver related db tables
15:22:56 <bswartz> yeah this would not allow that
15:23:22 <ganso> mkoderer__: we have private storage
15:23:32 <ganso> mkoderer__: driver's* private storage db table
15:23:35 <vponomaryov> ganso: tsss
15:23:47 <mkoderer__> ganso: never saw that
15:23:57 <ganso> lol
15:23:59 <bswartz> just to re-summarize the proposal, I'd like a way for drivers to update the DB multiple times during a single operation, but each update would be limited to what they can currently return in a model update, or perhaps even less
15:24:08 <tbarron> tssss == shhhh ?
15:24:19 <ganso> tsss sounds like a snake
15:24:28 <vponomaryov> tbarron: yes ))
15:24:45 <bswartz> driver private storage is a place for drivers to persist information that nobody but the driver cares about, but the schema is unchangeable by drivers
15:24:57 <tbarron> vponomaryov: ty
15:25:31 <mkoderer__> bswartz: so it would be basically something like key value pairs in a table?
15:25:42 <bswartz> mkoderer__: that's what driver private storage is
15:25:44 <gouthamr> mkoderer__: yes
15:26:20 <mkoderer__> sounds not that bad
15:26:22 <ganso> but what we are discussing are the main db tables, not driver's private storage
15:26:30 <bswartz> this proposal is to have the manager pass an object into the driver's methods which it can use to manipulate the DB whenever it likes during that method call -- not just at the end
15:26:51 <bswartz> the object would severely limit which tables and fields could be updated
15:27:04 <vponomaryov> right, it is really useful to be able to save intermediate results
15:27:12 <bswartz> and the object would have a lifetime of just 1 driver method call
15:27:45 <tbarron> i wonder if there is any precedent for this from other projects, for comparison purposes
15:27:47 <ganso> bswartz: maybe we could limit the amount of calls the driver can make as well?
15:28:02 <bswartz> ganso: what are you worried about?
15:28:20 <ganso> bswartz: driver spamming updates
15:28:25 <tbarron> nothing against manila pioneering here, just trying to be informed
15:28:40 <bswartz> tbarron: I'm not aware of anything like this -- I mentioned how manila already started doing this kind of thing by attaching model updates to exceptions
15:28:58 <bswartz> ganso: hopefully that would be caught in code review
15:29:13 <ganso> bswartz: hopefully
15:29:14 <xyang> bswartz: I’m afraid that once we open the door for this, we’ll get more and more requests and eventually open it up for everything
15:29:40 <xyang> bswartz: what is reason not to allow driver to do db update directly?
15:29:52 <bswartz> xyang: if the requests were for good reasons, why wouldn't we want to say yes?
15:29:52 <vponomaryov> xyang: why everything? we provide object and only this object can be updated
15:30:22 <bswartz> I can't imagine it every becoming wide open though -- that's the point of using an object to mediate access
15:30:26 <jcsp> does anyone have a specific use case for driver private information?   in ceph, we do have to store things, but we store them in ceph.
15:30:30 <bswartz> s/every/ever/
15:30:32 <xyang> vponomaryov: I’m just saying there will be more and more cases once this gets started
15:30:41 <mkoderer__> jcsp: +1
15:30:51 <vponomaryov> jcsp: look at ZFSonLinux driver
15:30:56 <bswartz> jcsp: IMO that's superior to using the manila DB
15:31:19 <jcsp> vponomaryov: without me reading the code right now, what is it that that drive needs private data for?
15:31:24 <xyang> jcsp: generic driver also uses private data
15:31:33 <vponomaryov> jcsp: there we store info specific to ZFS dataset
15:31:43 <ganso> jcsp: manage/unmanage
15:31:47 <vponomaryov> jcsp: kind of mapping of share ID and dataset
15:31:49 <bswartz> jcsp: not all backends have a place to store metadata about shares I guess
15:32:06 <bswartz> oh yes that's a good case vponomaryov
15:32:37 <bswartz> jcsp: consider a backend with a name length limit of less than 32 characters
15:33:00 <vponomaryov> jcsp: and we require it in case of replication when we need to read other backend's dataset name
15:33:13 <bswartz> on such a backend, you can't simply name the share by UUID, you need to generate your own naming scheme
15:33:28 <vponomaryov> jcsp: when it is impossible to recalculate name of dataset using some template
15:33:31 <bswartz> and you need to store the mapping from the manila UUID to the actual name on the backend somewhere
15:33:42 <jcsp> couldn't you all just open source your backends and then change them to do what you need ;-)
15:33:58 <markstur_> :)
15:33:59 <mkoderer__> haha
15:34:01 <mkoderer__> +1
15:34:05 <tbarron> jcsp: +1
15:34:13 <vponomaryov> jcsp:  we already do what we need
15:34:19 <toabctl> we should vote on that ;)
15:34:25 <gouthamr> ideal world :)
15:34:50 <bswartz> okay we're getting off track
15:34:51 <dustins> hahaha
15:34:59 <bswartz> we still need a spec for this proposal to have a proper discussion
15:35:21 <bswartz> but I think we know what some of the early objections might be, so we can attempt to address those in the spec
15:35:53 <bswartz> #topic Midcycle meetup
15:36:56 <bswartz> so after deciding that this summer is not the right time to do a europe-based midcycle, I sort of dropped the ball on planning this
15:37:21 <bswartz> We know that the meetup will be mostly virtual as before
15:37:53 <bswartz> And we're happy to host people here in RTP if anyone wants to travel
15:38:06 <bswartz> but main priority is to set the date
15:38:34 <ganso> bswartz: +1
15:38:51 <bswartz> Cinder has set theirs 19-22 July
15:39:12 <mkoderer__> maybe just one week after the cinder one?
15:39:24 <bswartz> that's the week after N-2
15:39:44 <toabctl> can we use a doodle or so to get an overview?
15:39:46 <bswartz> mkoderer__: I actually think the cinder one is ridiculously late
15:39:55 <mkoderer__> bswartz: ok then before
15:39:56 <cknight> bswartz: +1
15:40:13 <mkoderer__> I didn't planed my vacation yet... :)
15:40:14 <bswartz> holding a midcycle in N-3 means you have 4 weeks until feature freeze afterwards
15:40:19 <zhongjun_> mkoderer__: haha +1
15:40:46 <ganso> mkoderer__: I also depend on the date definition to plan my vacation
15:40:55 <xyang> bswartz: it was moved to this late date because of some activities in Fort Collins earlier
15:40:56 <bswartz> I'd prefer for ours to be in late June I think
15:41:17 <xyang> bswartz: no hotels
15:41:24 <bswartz> of course that would be pretty short notice becuase it's early june now
15:41:54 * gouthamr man early is a nice nick.. bswartz is waking him/her a lot
15:42:28 <vponomaryov> gouthamr lol
15:42:50 * vponomaryov hopes there is no guy with nickname 'lol'
15:42:50 <xyang> bswartz: what about before n-2
15:43:01 <bswartz> wtf? someone's nick is early?
15:43:05 <bswartz> I'm sorry early
15:43:25 <gouthamr> vponomaryov: if there is, he probably never joins fun meetings :)
15:43:27 <markstur_> that's 2 more
15:43:43 <bswartz> okay so the reasonable weeks are:
15:43:55 <bswartz> Jul 11-15 (week of N-2 milestone)
15:44:20 <bswartz> Jul 04-08 (US holiday week)
15:44:41 <bswartz> Jun 27- Jul 01
15:44:42 <xyang> week of N-2 will be very bad
15:44:55 <ganso> xyang: why?
15:44:55 <gouthamr> us holiday week will be bad :)
15:45:06 <xyang> ganso: need to do code reviews
15:45:37 <ganso> xyang: oh cinder has N-2 deadlines, right?
15:45:44 <bswartz> gouthamr: less than half of us are US-based
15:45:49 <xyang> ganso: yes.  Manila too
15:45:55 <ganso> xyang: we do?
15:46:05 <xyang> ganso: we need to cut n-2 as well
15:46:17 <mkoderer__> sound like Jun 27- Jul 01 ?
15:46:22 <bswartz> the deadline we enforce for N-2 is the major feature proposal deadline
15:46:27 <xyang> ganso: manila needs to cut n-2, so lots of reviews need to be done that week
15:46:36 <bswartz> I agree it would be ideal to avoid the N-2 week
15:46:42 <ganso> xyang: oh yes but nothing like "drivers need to be merged by N-2", unless I am very lost on our deadlines
15:46:51 <xyang> ganso: no
15:46:55 <bswartz> and we might lose some US-based people if we do it the July 4th week
15:47:36 <bswartz> anyone have problems with  Jun 27- Jul 01 ?
15:47:50 <dustins> I'm down with that
15:48:01 <bswartz> that's just 4 weeks away
15:48:25 <bswartz> anyone who would like to travel to attend locally who that will cause problems for?
15:49:36 <markstur_> other weeks are worse -- not expecting travel approval anyway
15:49:41 <bswartz> okay 1 more question before we move on
15:49:59 <bswartz> in the past we've done Tues/Wed and Wed/Thurs
15:50:43 <bswartz> we've expanded from 1.5 days to 2 whole days -- will 2 days be enough or should we look at a third day?
15:50:58 <bswartz> and if 2 days, which 2 days are preferred?
15:51:05 <mkoderer__> depends on the topics.. should we collect them first?
15:51:47 <bswartz> at austin we didn't come close to covering all topics in the time we had
15:52:25 <ganso> bswartz: I think we could shoot for 3 days to not prevent in-depth discussions
15:52:35 <bswartz> how about we plan on Tuesday/Wednesday -- then if we feel like we're getting too much material we can expand into Thursday?
15:52:53 <ganso> bswartz: last midcycle I had the feeling that we did not discuss many things as we do in summits
15:52:57 <ganso> bswartz: +1
15:52:58 <dustins> Works for me
15:53:02 <mkoderer__> bswartz: +1
15:53:08 <xyang> +1
15:53:08 <vponomaryov> +1
15:53:09 <zhongjun_> +1
15:53:10 <gouthamr> +1
15:53:11 <mkoderer__> we need to do proper timeboxing IMO
15:53:29 <ganso> mkoderer__: and follow them
15:53:34 <bswartz> okay so the proposal is Jun 28 and 29 with possible June 30th too
15:54:06 <bswartz> I'll send out an ML post about that as well, and make it official if no major problems are raised
15:54:25 <bswartz> okay 1 last topic, not sure if we have enough time
15:54:32 <bswartz> #topic New spec - Extending share networks to span subnets
15:54:37 <bswartz> #link https://review.openstack.org/#/c/323646/
15:54:38 <gouthamr> #link: https://review.openstack.org/#/c/323646
15:54:43 <gouthamr> thanks bswartz
15:54:49 <ganso> my vacation dates have just been decided :)
15:55:05 <mkoderer__> gouthamr: I am already reviewing this
15:55:10 <gouthamr> just wanted to bring this to your attention..
15:55:13 <gouthamr> mkoderer__: nice :)
15:55:16 <gouthamr> thank you..
15:55:23 <mkoderer__> gouthamr: you'll get me feedback tomorrow
15:55:47 <gouthamr> mkoderer__: sure.
15:56:06 <mkoderer__> but I need to have a closer look to neutron AZ implementation
15:56:27 <gouthamr> yes, the blueprint linked there will give you the basic outline
15:57:02 <mkoderer__> seems this release is very network centric :)
15:57:03 <gouthamr> i've dug deep into their code paths... our AZ idea is built around their current implementation
15:57:46 <bswartz> mkoderer__: share servers inevitably get tangled up with networking issues
15:58:31 <gouthamr> i'd be happy to get reviewer feedback on that spec..
15:58:36 <gouthamr> that's all i had bswartz
15:58:38 <bswartz> yes...
15:58:47 <bswartz> I'd be happy if everyone reviewed all the specs
15:58:54 <gouthamr> +1
15:59:01 <bswartz> I've done a few in-depth reviews but there are many more to look at
15:59:16 <gouthamr> we've only merged one so far..
15:59:17 <bswartz> so please keep up with the spec reviews
15:59:55 <bswartz> gouthamr: it's a new process this release -- we'll learn what works and refine it for ocata
16:00:01 <gouthamr> +1
16:00:05 <bswartz> we're out of time
16:00:07 <bswartz> thanks all
16:00:23 <bswartz> #endmeeting