15:00:18 <bswartz> #startmeeting manila
15:00:19 <openstack> Meeting started Thu Mar 24 15:00:18 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:23 <openstack> The meeting name has been set to 'manila'
15:00:30 <bswartz> hello all
15:00:31 <cknight> Hi
15:00:32 <tpsilva> hello
15:00:32 <ganso> hello o/
15:00:33 <dustins> \o
15:00:36 <gouthamr> hello o/
15:00:37 <vponomaryov> hi
15:01:37 <markstur_> hi
15:01:45 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:01:47 <JayXu> Hello
15:01:59 <tbarron> hi
15:02:30 <mkoderer> hello
15:02:34 <bswartz> JayXu was here then he vanished...
15:03:28 <bswartz> I wanted to cover his topic first but oh well
15:03:34 <bswartz> #topic Design summit planning
15:03:40 <bswartz> #link https://etherpad.openstack.org/p/manila-newton-summit-topics
15:04:08 <bswartz> so we have a bunch of topic proposals
15:04:11 <bswartz> thank you guys
15:04:20 <bswartz> anyone who hasn't added their proposals it's not too late
15:04:40 <bswartz> remember to put your name next to anything you add
15:05:05 <bswartz> and just because a name is there doesn't mean that person will be presenting (my name is next to several things I hope others will present)
15:05:17 <mkoderer__> for hpb/binding we are also on the Neutron etherpad https://etherpad.openstack.org/p/newton-neutron-summit-ideas
15:05:50 <mkoderer__> not sure how to organize a joint session
15:05:55 <bswartz> so my request is that today you start reviewing the topics and add +1 next to topics you want to see covered
15:06:05 <toabctl> hi
15:06:19 <bswartz> mkoderer__: typically we use one of their slots or one of our slots and we invite the guests to come to the other session
15:06:49 <bswartz> mkoderer__: we'd just need to coordinate schedules so it was a slot that we didn't have conflicts in
15:06:50 <mkoderer__> bswartz: ok I need to talk to the neutron folks about it
15:07:03 <mkoderer__> ok fine
15:07:26 <bswartz> I've asked ttx to schedule us so we don't conflict with cinder, but all bets are off regarding neutron
15:08:40 <JayXu> Hi
15:08:45 <mkoderer__> JayXu: hi
15:08:54 <bswartz> so please start voting on topics with +1s and add any other topics
15:09:15 <bswartz> I will take that information and try to fit the topics into the slots we have
15:10:09 <bswartz> any questions about design summit?
15:10:22 <mkoderer__> bswartz: do you know what day our sessions will be?
15:10:28 <dustins> I'm guessing the sessions will be more towards the end of the week?
15:10:34 <bswartz> mkoderer__: not monday
15:10:36 <dustins> what mkoderer__ said :)
15:10:39 <bswartz> not friday
15:10:56 <bswartz> they'll be tue/wed/thurs probably split across 2 days
15:11:03 <mkoderer__> ok fine for me
15:13:08 <bswartz> #topic Question about share servers
15:13:20 <bswartz> JayXu: welcome back, this is your topic
15:13:33 <bswartz> from the agenda: "Is there a way to get gateway IP address when the API setup_server() is invoked. I did not see this attribute in the input parameter network_info. Gateway IP is mandatory to create the interface for EMC storage which will be release coming soon, so it is expected that we can add the gateway IP into NetworkAllocation model if not."
15:13:40 <JayXu> okay, actually I post my question in the agenda.
15:14:12 <JayXu> and I would like discussing if any possibility to add gateway into network_info parameter when invoking setup_server()?
15:14:21 <bswartz> the gateway is part of the neutron subnet
15:14:27 <bswartz> so it should be available to manila
15:14:32 <JayXu> I  did not see any other driver to use this property.
15:14:47 <bswartz> cknight: do we need the gateway IP?
15:14:58 <cknight> bswartz: didn't think so, I'll check
15:15:03 <vponomaryov> JayXu: yes, none of the drivers use it and "network plugin" interface does not provide it
15:15:03 <bswartz> vponomaryov: does generic driver use it?
15:15:08 <bswartz> ugh
15:15:18 <vponomaryov> bswartz; generic driver does nto use network allocations ))
15:15:22 <bswartz> well I think it would be reasonable to provide it
15:15:33 <vponomaryov> yes, fix is easy
15:15:38 <vponomaryov> just need to implement
15:15:42 <bswartz> however drivers need to be able to handle the case when it's not present even in neutron
15:15:58 <JayXu> it is in subnet
15:16:10 <bswartz> neutron could set the GW IP to 0.0.0.0 if it doesn't exist and drivers should handle that case
15:16:22 <bswartz> there are networks with no gateways
15:16:23 <mkoderer__> should it be persistent in the manila db?
15:16:39 <JayXu> if gateway is not provided by subnet, the driver can throw an exception if it is mandatory. :)
15:16:51 <bswartz> jayxu: you need this is newton right? not mitaka?
15:16:57 <vponomaryov> JayXu: just file such bug and it will be fixed
15:17:00 <JayXu> My proposal is to add a column in NetworkAllocations
15:17:13 <JayXu> yes, Newton
15:17:17 <JayXu> is fine for me
15:17:27 <JayXu> and I will file a enhancement for that. :0
15:17:33 <bswartz> okay, yes a BP makes sense
15:17:56 <mkoderer__> JayXu: ok means old entries will be None in case of migration
15:18:17 <mkoderer__> but an exception looks fine
15:18:34 <bswartz> mkoderer__: we could add logic to manager to populate none entries at startup
15:19:01 <bswartz> so it works cleanly even after upgrades
15:19:08 <vponomaryov> mkoderer__, swartz: it is driver logic and its network_api attr
15:19:10 <ttx> bswartz: looking on the proviosnal scheduling I just finished... it's not looking too bad
15:19:18 <ttx> manila vs. neutron
15:19:25 <bswartz> ttx: is it published somewhere yet?
15:19:40 <ttx> no, I need to check the draft for conflicts
15:19:41 <mkoderer__> ttx: cool :)
15:20:10 <ttx> It's complete luck though
15:20:20 <ttx> :)
15:21:03 <bswartz> okay
15:21:06 <bswartz> #topic open discussion
15:21:10 <bswartz> any thing else today?
15:21:15 <bswartz> oh I have one announcement
15:21:22 <mkoderer__> dustins: should we discuss about https://review.openstack.org/#/c/288504/ ?
15:21:31 <dustins> I was just gonna mention that, haha
15:21:32 <cknight> mkoderer: yes
15:21:37 <bswartz> I'll be on vacation next week wed-fri, I'll find someone else to chair the weekly meeting
15:22:07 <bswartz> #link https://review.openstack.org/#/c/288504/
15:22:13 <mkoderer__> bswartz: +1 have a nice holiday
15:22:38 <mkoderer__> I raised the question why this is in devref and not adminref
15:22:52 <mkoderer__> and cknight suggested to put it onto the wiki like cinder does
15:23:04 <bswartz> mkoderer__: it's just momentum -- it was started here and never moved
15:23:13 <bswartz> I actually prefer it to live in openstack-manuals
15:23:26 <bswartz> and it should not mention past releases
15:23:31 <bswartz> just the current release
15:23:39 <dustins> It doesn't matter to me where it goes, I just gotta know :)
15:24:06 <mkoderer__> bswartz: mh, that's also fine.. but we need to ensure that all vendor update it accordingly
15:24:19 <bswartz> gouthamr was going to look at moving some of this info to the config-ref iirc
15:24:26 <mkoderer__> having it in tree makes it easy to do updates with one commit
15:24:48 <vponomaryov> mkoderer__: +1
15:24:56 <bswartz> personally I'd be okay with merging dustins's changes to the devref so the information is captured
15:25:03 <dustins> mkoderer__: Yeah, I kinda like having it in tree, perhaps in the adminref rather than the defref
15:25:15 <bswartz> but I agree that it's an awkward place for this information to live and I'd rather see it move out of tree
15:25:17 <dustins> bswartz: agreed, we can always move it later
15:25:30 <dustins> Whether it be out of tree or otherwise
15:25:32 <bswartz> +1 for moving later rather than now
15:25:45 <mkoderer__> bswartz: yeah sure its not releated to the change in general
15:25:56 <mkoderer__> bswartz: +1
15:26:22 <dustins> Yeah, I think that what it is is fine now, but where it is might need to change
15:27:09 <dustins> But we can do that later
15:27:23 <bswartz> dustins: you might want to ping gouthamr about his plans to move some of this info to the config-ref
15:27:36 <dustins> bswartz: wilco
15:27:44 <JayXu> Should we keep to update release by release?
15:27:49 <bswartz> I want to see it happen, but right at release time is not the best time
15:28:09 <dustins> I gotta make a change to the ZFS line anyway, so I'll do that as well (thanks, vponomaryov!)
15:28:20 <bswartz> JayXu: IMO the master version of the config-ref should match the matster version of manila
15:28:42 <bswartz> people who are interested in historical information should look at stable branches or git history
15:29:04 <JayXu> Make sense. *_^
15:29:49 * mkoderer__ wants to have a Manila t-shirt with our elected logo
15:29:52 <bswartz> also vendors often publish their own docs (I know netapp does) and vendors can include as much historical information as they want in those docs
15:30:21 <mkoderer__> I guess the distros do the same
15:30:26 <ganso> mkoderer__: which logo got elected?
15:30:37 <mkoderer__> ganso: we need to ask esker
15:30:39 <bswartz> ganso: good question
15:30:53 <dustins> IIRC, it was the third choice
15:31:22 <JayXu> T-shirt. How to get a t-shirt?
15:31:38 <mkoderer__> bswartz: the plan was a sticker right?
15:31:47 <bswartz> will there be tshirst? I thought it was stickers
15:32:08 <mkoderer__> should I try to get it sponsored by sap?
15:32:08 <ganso> bswartz: there were t-shirts @ Tokyo
15:32:15 <ganso> bswartz: stickers too
15:32:25 <mkoderer__> ganso: damn I wasn't there
15:32:28 <bswartz> ganso: if you say so
15:32:45 * bswartz doesn't know about marketing things
15:32:57 <vponomaryov> mkoderer__: how I understand you ((
15:33:25 <bswartz> okay I think we're done for today
15:33:32 <bswartz> thanks all
15:33:48 <bswartz> #endmeeting