15:01:02 <bswartz> #startmeeting manila
15:01:02 <openstack> Meeting started Thu Aug 28 15:01:02 2014 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:06 <openstack> The meeting name has been set to 'manila'
15:01:10 <bswartz> hello all
15:01:12 <cknight> Hi
15:01:14 <xyang1> hi
15:01:14 <rushil> hi
15:01:15 <vponomaryov> hi
15:01:17 <bswartz> who do we have?
15:01:17 <scottda> hi
15:01:19 <vvechkanov> hi
15:01:23 <ameade_> o/
15:01:24 <rraja> hi
15:01:27 <csaba> hi
15:01:40 <bswartz> awesome
15:01:40 <lgreg_> hey
15:01:50 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:02:08 <bswartz> #topic incubation
15:02:24 <bswartz> so for those of you who don't know, manila is an incubated project now!
15:02:40 <bswartz> our application was approved at this tuesday's TC meeting
15:02:52 <xyang1> wonderful!
15:03:18 <bswartz> this will mean some practical changes, but mostly during the kilo timeframe
15:03:37 <bswartz> for juno we need to continue to finish up the release
15:04:42 <bswartz> the most immediate benefit of incubation is that I think we will get some official time on the schedule at the design summit
15:04:47 <bswartz> I'm not sure how much yet
15:05:05 <bswartz> during kilo, we'll move our code from stackforge to openstack
15:05:15 <bswartz> and we'll integrate with devstack, tempest, and horizon properly
15:05:53 <bswartz> any questions about incubation?
15:06:20 <bswartz> I'll share more when I know more
15:06:58 <xyang1> Is 9/4 the deadline for patches to be merged in Juno?
15:07:06 <bswartz> hopefully some of you will be able to dedicate more time now that you can tell your bosses manila isn't some science project anymore
15:07:17 <bswartz> 9/3 is the deadline
15:07:32 <bswartz> on 9/4 we release juno-3
15:07:39 <xyang1> ok
15:08:11 <bswartz> okay we'll move on to
15:08:15 <bswartz> #topic dev status
15:08:23 <vponomaryov> Dev status for last week:
15:08:28 <vponomaryov> 1) Manila now uses 'alembic' for db migrations instead of 'sqlalchemy-migrate'.
15:08:36 <vponomaryov> 2) service_instance module now allows to switch service instance to tenant net in two ways.
15:08:44 <vponomaryov> 3) Multiple bug fixies for generic and netapp cmode drivers.
15:08:51 <vponomaryov> 4) NetApp 7-mode driver was removed as obsolete.
15:08:58 <vponomaryov> 5) Add support to use default share-network by multitenant drivers
15:08:58 <vponomaryov> bp: #link https://blueprints.launchpad.net/manila/+spec/default-network-for-multitenant-drivers
15:08:58 <vponomaryov> gerrit: #link https://review.openstack.org/114258
15:09:12 <vponomaryov> that's the main
15:09:37 <bswartz> ooh the patch is up
15:09:59 <bswartz> looks like jenkins is still chewing on it
15:10:58 <bswartz> we can talk about that last one a bit more
15:11:06 <vponomaryov> it is next topic
15:11:17 <bswartz> I'm not convinced it will get enough soak time before the release
15:11:20 <vponomaryov> any questions about 1-4?
15:11:44 <bswartz> I still want to try to get it in, but that will require us all to reach agreement pretty fast
15:12:09 <vponomaryov> bswartz: yeah, there are open items for it in agenda
15:12:40 <bswartz> okay if no questions, then
15:12:48 <bswartz> #topic Discuss blueprint "Add support to use default network by multitenant driver"
15:13:12 <bswartz> #link https://blueprints.launchpad.net/manila/+spec/default-network-for-multitenant-drivers
15:13:42 <bswartz> vvechkanov: ?
15:13:50 <vvechkanov> I have several question about this change, they are in agenda and I'll copy them here.
15:13:59 <vvechkanov> 1) Do we need option in config for turn on/off auto creation default share network?
15:14:26 <vponomaryov> or ask drivers for it
15:14:30 <bswartz> to answer that question I think we have to define the behaviour if it's off
15:14:51 <vvechkanov> It will work as without my changes
15:15:14 <bswartz> I'm not sure the current behavior is something we want to preserve though
15:15:22 <vvechkanov> If it is turned off. This will be smth necessary for single tenant drivers
15:15:30 <bswartz> the whole idea here is to improve the default behavior
15:16:00 <bswartz> I suppose there's a question of whether anyone is relying on the current behavior
15:16:26 <bswartz> I'm hoping that everyone is using share networks explicitly
15:17:08 <vponomaryov> bswartz: question is a little bit different, should we create default share-net if it won't be used?
15:17:14 <bswartz> my vote is for: don't give an option to turn it off
15:17:20 <vvechkanov> My changes will work for singletenant drivers. But they do not need share-net.
15:17:45 <vvechkanov> And in my changes whar-net will be created.
15:17:57 <vvechkanov> s/whar-net/share-net
15:18:25 <bswartz> so people who explicitly specify share networks will not be affected
15:19:02 <xyang1> I'm not quite clear on what impact this will have on single tenant driver
15:19:04 <vvechkanov> bswartz, Yes
15:19:08 <bswartz> I think our goal needs to be to give the admin control over how to handle requests with no share network
15:19:22 <bswartz> turning this new feature on/off doesn't help there
15:19:28 <vponomaryov> xyang1: nohow, just redundant actions
15:19:57 <bswartz> okay we need to stop using the term "single tenant driver" and use the more accurate term "flat network driver"
15:20:08 <bswartz> because I think it confuses us and people reading these logs
15:20:31 <bswartz> you have have multiple tenants on a flat network
15:20:44 <xyang1> ok, we need to clean up docs and docstring/comments in the code too
15:20:45 <bswartz> you can* have
15:21:09 <vponomaryov> xyang1: what do you mean by clean up?
15:21:18 <vponomaryov> xyang1: what's wrong with it?
15:21:36 <bswartz> maybe she's referring to the EMC driver doc strings?
15:21:46 <xyang1> vponomaryov: this is regarding Ben's comments to use "flat network driver
15:21:56 <vponomaryov> xyang1: oh
15:22:04 <xyang1> no, EMC's VNX driver supports multitenancy
15:22:13 <bswartz> ok
15:22:35 <xyang1> I remember seeing docstring on single tenant driver somewhere, maybe glusterfs driver?
15:22:37 <bswartz> vvechkanov: I don't hear any disagreement with no allowing disabling it
15:22:40 <bswartz> vvechkanov: next question?
15:22:44 <vvechkanov> So as I understand we prefer to create share-net when it's not doing anything. It will not affect anything, it is just unnecessary action.
15:23:00 <vvechkanov> Ok, next question.
15:23:02 <rraja> xyang1: you're right.
15:23:11 <vvechkanov> Do we need option in config for choosing name of default share network?
15:23:28 <bswartz> vvechkanov: do you have a use case in mind?
15:23:55 <bswartz> vvechkanov: it will be referred to by ID in all the API calls -- the string is just a convenience thing for admins and users
15:24:14 <bswartz> are you thinking that the name should be internationalizable for non-english speakers?
15:24:39 <vvechkanov> No. It will be referred by name.
15:25:15 <vvechkanov> The problem is that administrator can create this default share-net manually. So we should refer it by name.
15:25:20 <bswartz> so my understanding is that it will be used when you *don't* specify a name
15:25:48 <vvechkanov> We have default share network in service tenant.
15:26:09 <vvechkanov> It can be created manually or if not thenautomatically
15:26:20 <vponomaryov> bswartz: we do not specify asusers, but admin can create it manually
15:26:32 <vponomaryov> bswartz: in service tenant, and it will be used
15:27:05 <vponomaryov> bswartz: or better to say, manually created - first priority, then autocreation
15:27:05 <vvechkanov> The name of this default share net should be specified somewhere. Hardcoded in the code. Or as option in config file.
15:27:18 <bswartz> but when will it be autocreated?
15:27:44 <bswartz> if it's created first thing when manila starts up then the admin won't get a chance to create it manually
15:27:49 <vponomaryov> bswartz: on share creation call
15:28:17 <bswartz> I feel weird about waiting for the first share creation to create it
15:28:18 <vvechkanov> bswartz: on share creation call, with not specified share-net
15:28:40 <bswartz> I like the idea of it being clearly defined right up front
15:28:48 <bswartz> otherwise I see race conditions
15:28:49 <vponomaryov> bswartz: wait? it is db record
15:29:18 <vponomaryov> bswartz: other stuff - as usual
15:29:19 <bswartz> why can't we put all of the definition that's needed for the default network into the conf file
15:29:30 <bswartz> and make it created immediately upon startup?
15:29:50 <vponomaryov> in case we want use security services - it is to much opts
15:30:11 <vponomaryov> so, admin would want create manually if sec services are used
15:30:28 <vponomaryov> ^ for example
15:30:31 <bswartz> can we not create it automatically and allow the admin to modify the one that's created as long as nobody is using it?
15:31:10 <vponomaryov> possibility to update will be common behaviour
15:31:21 <vponomaryov> if share server present - restrict update of its data
15:31:36 <vponomaryov> its - default share-network
15:31:46 <bswartz> okay well we're getting off track
15:31:54 <bswartz> the question about about modifying the name
15:32:07 <bswartz> and I see no harm in allowing it
15:32:25 <bswartz> we allow names to be modified on other share networks
15:32:38 <vponomaryov> modifying name of share-net that will be used, not name of share-name itself
15:32:46 <bswartz> OH
15:33:06 <bswartz> so you mean we could have default1 and default2
15:33:21 <bswartz> and you could switch back and forth now and then?
15:33:33 <vponomaryov> I mean we can call it with config "my_cool_share_net" instead of hardcoded "default".
15:33:55 <vponomaryov> ^ for example
15:34:01 <vvechkanov> But we will have only one default share-net
15:34:11 <bswartz> yeah my concern there is how confusing it would be to actually change it once people start using a default
15:34:45 <vponomaryov> default name or default in general?
15:35:02 <bswartz> any mechanism that allows the admin to switch which network is treated as the default seems like a bad idea
15:35:26 <bswartz> if the admin needs to switch the default network then we need to consider how to enable that use case very carefully
15:35:39 <vponomaryov> bswartz: it won't make harm
15:35:45 <bswartz> maybe limitted modifications to the default should be allowed
15:35:55 <bswartz> but switching to a whole new network I don't like
15:36:05 <vponomaryov> bswartz: we can allow it
15:36:15 <vponomaryov> bswartz: do it or not - choose of admin
15:36:20 <vvechkanov> bswartz: The only thing new options will do is name default share-net not "default" but "some-name-I-prefer"
15:36:48 <vponomaryov> vvechkanov: yes, but opt means we can change it everytime
15:36:57 <bswartz> so my proposal for that, is to internally refer to the default by ID only
15:37:07 <bswartz> and allow the admin to rename the network referred to by that ID
15:37:12 <rushil> bswartz: +1
15:37:32 <vponomaryov> bswartz: better not use IDs via configuration
15:38:01 <bswartz> I know it's ugly but it's the only way to avoid the problems I see
15:38:12 <vponomaryov> bswartz: we can "hardcode" name
15:38:22 <vponomaryov> and there will be used only one
15:38:36 <vponomaryov> if its name unchanged
15:38:38 <bswartz> hardcoding the name makes it impossible to rename it though
15:38:44 <vvechkanov> And hardcoded name looks better than use id in configure
15:38:54 <scottda> But hardcoded name might conflict with another share net name created later
15:39:13 <scottda> UUID must be unique, name does not have to be unique
15:39:17 <vponomaryov> scottda: default one will be stored in service tenant
15:39:25 <vvechkanov> This share-net created in special service tenant. Thay will not conflict
15:40:25 <bswartz> okay I think there's still a lot of misunderstanding about this feature
15:40:27 <vponomaryov> bswartz; we also specify neutron net and subnet "name"s via config, not its IDs
15:40:33 <bswartz> and I'm not sure we're going to resolve it in 20 minutes
15:40:42 <xyang1> I think we should rely on uuid, not name
15:40:57 <rushil> I feel the same
15:40:58 <bswartz> yeah I'm unconfortable with names when all of these things are renamable
15:41:09 <vponomaryov> xyang1, bswartz: when we start Manila first - there are no UUIDs yet
15:41:15 <bswartz> if a rename operation in neutron breaks us, that's kind of lame
15:41:18 <xyang1> names are not unique
15:41:27 <vponomaryov> xyang1, bswartz: and we can not guess it
15:41:35 <bswartz> yeah I see that problem too vponomaryov
15:42:07 <bswartz> I'm sure other projects have solved similar problems
15:42:23 <bswartz> and I KNOW I've seen UUIDs in config files before
15:42:34 <vponomaryov> bswartz: yes, "booking" of IDs
15:42:37 <bswartz> it's not pretty but it's more reliable
15:42:55 <vponomaryov> bswartz: but it should be really UUID valid
15:43:22 <vponomaryov> bswartz: some value, that will be used as UUID and not generated automatically
15:43:55 <bswartz> does anyone see a problem with letting the admin pick the UUID to use for the default share network?
15:44:31 <vponomaryov> bswartz: mentioned one is big problem - absense of it on first start
15:45:14 <bswartz> they can always just run 'apt-get -y install uuid-runtime && uuidgen'
15:45:40 <vponomaryov> bswartz: it will be absent in Manila
15:46:01 <vponomaryov> bswartz: are we on the same page?
15:46:21 <scottda> It seems better to have code generate UUID. There is not guarantee that what an admin picks is actually unique
15:46:37 <bswartz> manila can create it if the admin specifies it
15:46:44 <vponomaryov> scottda: in that case it is not generated on config option set step
15:46:50 <bswartz> scottda: we can check for uniqueness of passed in values
15:46:59 <scottda> true
15:47:24 <bswartz> well I know this much -- I prefer hardcoding something to allowing the admin to specify a name
15:47:46 <bswartz> I recognize the downsides of putting UUIDs in config files
15:48:00 <bswartz> maybe this needs to be handled with an API
15:48:39 <vvechkanov> Ok, lets use automatically created share-network with harcoded name.
15:48:47 <bswartz> we could simply disable the "default" share-network until the admin sets it up using a special admin API
15:49:29 <bswartz> or perhaps and admin-only flag on the existing share-network-create API
15:49:34 <vponomaryov> bswartz: if we hardcode name, that can be changed only by admin, this should be OK, is not it?
15:49:38 <bswartz> s/and/an/
15:50:28 <vponomaryov> bswartz: if share-net in service tenant is not changed, then no problem. And access to change it has only admin
15:51:01 <bswartz> so I'm confused about the relationship of this network to the service tenant
15:51:06 <bswartz> but that's another topic
15:51:40 <bswartz> okay last question
15:51:55 <bswartz> 3. What behavior expected for single tenant driver, where share network is not necessary?
15:52:00 <vponomaryov> bswartz: default "share-network", that will be in "service" project and used by "users" in their projects (tenants)
15:52:09 <vvechkanov> Oh this question was already discussed I think
15:52:15 <bswartz> let's rewrite that to
15:52:30 <bswartz> What behavior is expected for flat network driver, where share network is not necessary?
15:52:36 <vvechkanov> It was discussed as part of the first one.
15:53:01 <bswartz> okay
15:53:11 <bswartz> flat network drivers are going to ignore any share networks that are passed in
15:53:18 <vvechkanov> Yes
15:53:23 <vvechkanov> exactly.
15:53:36 <vponomaryov> bswartz: main concern - do not make redundant actions
15:53:43 <bswartz> okay so we're good on that topic
15:54:02 <vvechkanov> We will just create it and it will be ignored. It's better because we not create any options.
15:54:02 <bswartz> okay so I wan the community's opinion here
15:54:22 <bswartz> are we confortable with adding this default share network feature this late in J-3?
15:54:33 <bswartz> or should we aim for K-1?
15:55:03 <vponomaryov> bswartz:  looks like better to postpone it
15:55:05 <bswartz> personally I'd like a chance to experiment with it myself
15:55:31 <lgreg_> K-1, to ensure well thought out and executed…
15:55:54 <lgreg_> But, still have it available for us to experiment…..
15:56:27 <bswartz> well my proposal is, let's finish this feature, and put the completed code on gerrit so people can download it and try it out
15:56:42 <bswartz> then in Paris we can have a talk about manila networking
15:56:48 <bswartz> and demonstrate this functionality
15:56:54 <rushil> K-1 seems the better option to me as well
15:57:13 <vponomaryov> bswartz: code is secondary, we need "agreement" on feature details
15:57:14 <scottda> +1 to K-1
15:57:23 <bswartz> In fact the merge window for K-1 will open up a few weeks before Paris so it could even be upstream by then
15:57:46 <vvechkanov> vponomaryov: Agreement will be after experiments with code
15:57:49 <bswartz> vponomaryov: I agree in principle, but often code communicates more clearly than words
15:58:04 <bswartz> some people just need to try it out and see how it works rather than read a document
15:58:30 <scottda> Testing the code will also expose any issues, even if they are just around usability
15:58:36 <bswartz> I feel like if we merge it in K-1 then we can go back and tinker with the design if needed
15:58:36 <vvechkanov> It is easier to discuss when everyone try it and understand how its work/
15:59:03 <bswartz> if we merge it now then it will be released with Juno and we'll be stuck with it
15:59:22 <bswartz> okay we're almost out of time
15:59:36 <bswartz> any last things?
15:59:51 <vponomaryov> csaba; do you have any new with cirros image?
15:59:54 <bswartz> sorry I didn't save time for open discussion (I meant to)
15:59:59 <vponomaryov> s/new/news/
16:00:15 <bswartz> I've been tinkering with the cirros image myself
16:00:21 <csaba> vponomaryov: not now
16:00:41 <bswartz> I actually have my own version of it that's not based on cirros but pulls from csaba's code
16:00:41 <csaba> I'm busy with getting some stuff done till codefreeze
16:00:47 <albs> Hello
16:00:53 <bswartz> okay we're getting kicked out
16:00:54 <bswartz> thanks all
16:01:05 <ameade_> bye!
16:01:08 <mihgen> sorry folks, fuel time )
16:01:15 <mihgen> hi all)
16:01:17 <bswartz> #endmeeting