15:00:35 <bswartz> #startmeeting manila
15:00:35 <openstack> Meeting started Thu Jun 23 15:00:35 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:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:38 <openstack> The meeting name has been set to 'manila'
15:00:46 <bswartz> hello all
15:00:46 <ameade> \o/
15:00:47 <ganso> hello
15:00:47 <cknight> Hi
15:00:48 <jseiler_> hi
15:00:49 <vponomaryov> hello
15:00:49 <tbarron|errand> hi
15:00:51 <zhongjun_> hello
15:00:54 <mkoderer> hi
15:00:57 <dustins> \o
15:00:57 <MikeG451> Hello
15:01:02 <markstur_> hi
15:01:05 <DaiDV> hi.
15:01:07 * bswartz notes that ameade had his caffeine today....
15:01:09 <vkmc> o/
15:01:15 <aovchinnikov_> hi
15:01:19 * ameade is at a coffee shop
15:01:28 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:01:43 <mkoderer> DaiDV: your on the agenda btw
15:01:52 <tpatzig> hi
15:02:04 <bswartz> #topic announcements
15:02:18 <bswartz> reminder that midcycle meetup is next week, tuesday/wednesday
15:02:32 <bswartz> from 1200 UTC to 2000 UTC
15:03:07 <tbarron> bswartz: google hangout, right?
15:03:12 <bswartz> apologies to US west coast and east asia people for the times, we cannot make everyone happy
15:03:20 <xyang> hi
15:03:21 <mkoderer> webex?
15:03:23 <DaiDV> Hi everyone, my proposing is "Implement extend and shrink features for glusterfs driver"
15:03:30 <vponomaryov> #link https://etherpad.openstack.org/p/newton-manila-midcycle
15:03:58 <bswartz> I haven't decided on webex or google hangouts, although we will use one of those
15:04:18 <bswartz> in the past the limited number of people in google hangouts has been a deal breaker
15:04:19 <dustins> I'd vote for hangouts, webex sucks in Linux
15:04:28 <dustins> though hangouts does limit participants...
15:04:29 <ganso> dustins: +1
15:04:37 <bswartz> does anyone know if hangouts has increased the person limit?
15:05:03 <mkoderer> I don't think so
15:05:07 <tbarron> ganso: dustins: +1
15:05:19 <dustins> 10 for normal, 15 if you have a google apps for business account
15:05:32 * dustins was expecting the Google Apps one to be higher than that
15:05:43 <mkoderer> I heard that bluejeans works for Linux Osx and windows
15:05:43 <bswartz> I hate webex as much as anybody, but it actually works and it scales way better than hangouts
15:05:46 <vkmc> what about bj?
15:05:47 <vkmc> yeah
15:06:05 <dustins> Bluejeans is indeed an option
15:06:10 <bswartz> Bluejeans works for me but I don't have an account
15:06:11 <tbarron> bswartz: works, but not on linux
15:06:22 <mkoderer> I think the RH ppl could host it
15:06:26 <tbarron> can make it work, but then it breaks on upgrades, etc
15:06:36 <bswartz> I keep a windows VM around expressly for webex, MS outlook, and powerpoint
15:06:56 <tbarron> don't mean to rathole
15:06:57 <dustins> I have my personal macbook that I could use, but I'd rather not
15:07:01 <bswartz> bluejeans has the distinction of being the only app ever to cause a kernel panic on my laptop
15:07:08 <dustins> (and don't tell the other Hatters that I have a mac)
15:07:41 * mkoderer doesn't propose to host the meeting with Micosoft Lync
15:07:59 <dustins> That DEFINITELY wouldn't work on Linux :P
15:08:31 <mkoderer> Let's start with hangout and switch to webex if needed
15:08:33 <gouthamr> heh, lync
15:08:34 <bswartz> if we did hangouts we'd need to setup a phone bridge and many people would be stuck using that due to the 10 person limit
15:08:35 <xyang> bswartz: I join webex on my Mac.  I also do powerpoint on Mac.  outlook is a pain.  I’m using the web version
15:09:00 <cknight> bswartz: not fair to anyone stuck with phone only
15:09:06 <cknight> bswartz: they wouldn't see the demos
15:09:17 <mkoderer> cknight: demos?
15:09:20 <bswartz> is there anyone who can't manage at all with webex?
15:09:27 <bswartz> mkoderer: screen sharing
15:09:29 <vponomaryov> mkoderer: your demo, forgot?
15:09:31 <ganso> isn't it possible to use both hangouts and webex?
15:09:48 <bswartz> ganso: indeed it is, but only audio would go across
15:09:51 <gouthamr> ganso: +1 we could start hangouts and broadcast the webex
15:10:07 <mkoderer> vponomaryov: :)
15:10:11 <bswartz> oh god are you volunteering to do that gouthamr?
15:10:23 <gouthamr> only broadcast through hangouts though, no conferencing :)
15:10:36 <bswartz> that sounds hideous and like it might cause your laptop to catch on fire
15:10:51 <gouthamr> yeah, use a mac bswartz
15:11:21 <bswartz> macs aren't open enough
15:11:28 <ganso> bswartz: +1 :)
15:11:29 <gouthamr> i can play with it and see if it works..
15:11:34 <tbarron> i don't have windows or mac but guess i'll figure something out
15:11:47 <vponomaryov> mkoderer: it would be really big lost not seeing demo of HPB feature
15:11:56 <mkoderer> vponomaryov: I can do
15:11:59 * tbarron works on an open source project
15:12:11 <dustins> tbarron: We can huddle around my macbook :P
15:12:14 <vponomaryov> mkoderer: cool!
15:12:16 <ganso> we should schedule a session at the beginning of midcycle to just make the conference work
15:12:25 <bswartz> tbarron: there are rumors that webex can be made to work on Fedora
15:12:28 <dustins> ganso: +1
15:12:44 <bswartz> tbarron: it's much less stressful to create a windows VM however and run webex there
15:12:57 <tbarron> no license
15:13:01 <vkmc> but licenses...
15:13:04 <vkmc> yeah
15:13:07 <bswartz> tbarron: Windows is free for 90 days or something like that
15:13:20 <tbarron> ah, true, windows 10 i guessa
15:13:50 <bswartz> it only starts complaining about activation if you continue to use it for a long time
15:14:09 <bswartz> okay enough on this topic
15:14:14 <dustins> So "borrow" a copy of windows, got it
15:14:20 <dustins> :)
15:14:23 <bswartz> Personally I'm leaning towards webex because it will allow enough people
15:14:34 <bswartz> anyone can join in audio only mode with no software at all -- just a phone
15:14:36 <vkmc> how many people are for Manila usually?
15:14:43 <xyang> tbarron: you don’t have a laptop?
15:14:53 <vponomaryov> vkmc: more than hangouts allow
15:14:55 <ganso> vkmc: ~15
15:15:01 <tbarron> xyang: fedora on laptop
15:15:04 <dustins> I think the last one had 15-20
15:15:08 <bswartz> we'll see if we can bridge a google hangout in with some kind of magic
15:15:26 <tbarron> xyang: that's what vkmc dustins tellesnobrega and I all use
15:15:38 <xyang> tbarron: ok
15:15:50 <bswartz> I'm not going to do the whole google business account thing to get 15 people though -- that was a ridiculous hassle the one time I tried it
15:15:53 * tbarron subtly points out that we're bringing more folks in  to work on manila
15:16:12 <tbarron> besides the ceph driver people
15:16:31 <bswartz> okay let's move on
15:16:38 <bswartz> #topic Implement extend and shrink features for glusterfs driver
15:16:49 <bswartz> DaiDV: you're up
15:17:01 <DaiDV> yes.
15:17:40 <DaiDV> I wanna implement two features for glusterfs driver: extend and shrink.
15:18:02 <mkoderer> DaiDV: do you have a spec already?
15:18:04 <vponomaryov> everyone remembers that "extend" is required feature ))
15:18:17 <bswartz> yes, extend is a required feature
15:18:26 <bswartz> if it's not implemented, how is glusterfs not failing CI?
15:18:35 <cknight> mkoderer: a spec isn't needed for a minor driver feature
15:18:38 <ganso> bswartz: extend tests can be disabled
15:18:41 <DaiDV> yes.
15:18:44 <mkoderer> cknight: ok
15:18:45 * bswartz groans
15:18:55 <bswartz> someone please remove the option to disable extend tests
15:19:13 <DaiDV> CI extend is not working on glusterfs backend.
15:19:28 <mkoderer> bswartz: don't think that this is so easy ..
15:19:36 <vponomaryov> bswartz: options are not only for CI, so, I disagree to remove it
15:19:51 <rraja> DaiDV: i think this is a small feature, and does not need a spec
15:19:51 <bswartz> what is the point of the option then?
15:20:07 <rraja> DaiDV: you'd have to just modify quota limits, right?
15:20:14 <DaiDV> yes.
15:20:15 <ganso> rraja: we are not requiring specs
15:20:16 <vponomaryov> disable things that I do not want to test
15:20:29 <bswartz> any driver that doesn't implement extend needs to be removed, and failing CI is a good way to find out which drivers that is
15:20:30 <DaiDV> and we also manager some exception
15:20:49 <DaiDV> such as: shrink_size smaller than data size is used
15:21:11 <DaiDV> and extend_size exceeds volume size.
15:21:20 <vponomaryov> DaiDV: have you looked at existing implementations in other drivers?
15:21:38 <vponomaryov> DaiDV: you are not first who implements these features
15:21:48 <DaiDV> yes, I see it is implemented on
15:22:05 <DaiDV> some special driver
15:22:25 <bswartz> extend should be fairly trivial to implement unless the underlying file system on the backend is horribly inflexible
15:22:32 <DaiDV> But glusterfs is not supported.
15:22:50 <bswartz> we ran into issues with extend in the generic driver due to issues with how cinder handles extend
15:23:13 <rraja> sorry, what's not supported?
15:23:26 <DaiDV> sorry, I mean
15:23:37 <DaiDV> glusterfs driver is not support them.
15:23:42 <vponomaryov> DaiDV: it is unclear what is your concern that you need help with
15:24:05 <rraja> DaiDV: ok. can you please email in openstack-dev or gluster-dev and we'll happy to help you out.
15:24:07 <rraja> ?
15:24:17 <bswartz> yeah I agree, it seems like DaiDV should just go ahead and implement the features in the driver
15:24:25 <mkoderer> +1
15:24:27 <bswartz> I'm not sure what we need to discuss
15:24:54 <bswartz> although I do feel like the option to disable extend tests should be removed
15:25:14 <ganso> bswartz: +1
15:25:15 <bswartz> I can't think of any good reason not to run those tests
15:25:21 <vponomaryov> bswartz: it is easy to workaround by other means
15:25:29 <DaiDV> bswartz: +1
15:25:49 <zhongjun_> bswartz: agree with remove the option to disable extend test
15:25:49 <ganso> vponomaryov: yea, like a regex in MANILA_TESTS env_var
15:25:55 <rraja> vponomaryov: you can always check the CI logs, right?
15:26:07 <mkoderer> not sure how this should be "technically" possible.. 3rd party ci systems cannot be controlled.. they could simply delete the test files
15:26:16 <vponomaryov> rraja: I also can return fake "success"
15:26:16 <bswartz> we could check CI logs but that's labor intensive
15:26:21 <rraja> vponomaryov: :)
15:26:48 <markstur_> vponomaryov is sneaky
15:26:55 <ganso> bswartz: we should do for new drivers, but in this case, we accepted a driver before extend existed and was considered a minimum feature
15:27:14 <vponomaryov> markstur_: ti catch a cheater think as cheater
15:27:19 <vponomaryov> s/ti/to/
15:27:19 <bswartz> ronald reagan always said "trust but verify" -- that's my philosophy when it comes to 3rd party CI
15:27:56 <bswartz> okay I think this topic is done
15:28:08 <bswartz> #topic  Do all drivers have to inherit from driver.ShareDriver?
15:28:20 <bswartz> mkoderer: not sure where you're going with this topic
15:28:46 <mkoderer> I came across this topic while reviewing https://review.openstack.org/#/c/312423/
15:28:46 <vponomaryov> bswartz: he dislikes EMC drivers implementation
15:29:14 <mkoderer> I see it dangergous if all drivers do not share the same base class
15:29:31 <bswartz> yeah... I agree
15:29:43 <bswartz> what is going on in the EMC driver that you don't like?
15:29:44 <mkoderer> if we introduce a new functioanltity these functions are not inheriteed to all the drivers
15:29:48 <DaiDV> mkoderer: +1
15:30:25 <ganso> mkoderer: +1
15:30:27 <bswartz> it looks to me like the driver does inherit from sharedriver
15:30:31 <mkoderer> bswartz: basically it has it's one base with ABC
15:30:34 <xyang> class EMCShareDriver(driver.ShareDriver):
15:30:37 <vponomaryov> mkoderer: actually, they inherit base class here - https://github.com/openstack/manila/blob/a97d2bd7/manila/share/drivers/emc/driver.py#L62
15:30:38 <bswartz> so what am I missing?
15:30:50 <cknight> EMCShareDriver subclasses Driver, then proxies calls into plug-ins.  What's wrong with that?
15:30:55 <xyang> We have one commone EMC Share Driver
15:31:11 <xyang> Isilon and VNX and Unity have plugins to this common driver
15:31:23 <mkoderer> https://review.openstack.org/#/c/312423/17/manila/share/drivers/emc/plugins/unity/connection.py
15:31:40 <xyang> mkoderer: that is the plugin
15:31:45 <bswartz> it seems that the EMC driver is following the same model the NetApp driver uses with a single driver class and plugins for different platforms
15:31:47 <mkoderer> sah ok
15:31:49 <xyang> the plugin to EMCShareDriver
15:31:57 <vponomaryov> bswartz: you are right
15:32:01 <mkoderer> ok maybe I am wrong.. than I am fine
15:32:10 <bswartz> there are a number of advantages to that kind of design
15:32:35 <mkoderer> I just wanted to ask if we want to stick that every driver needs to inherit from base driver
15:32:38 <cknight> bswartz: It's a common pattern in Cinder where there are driver subclasses for different protocols.
15:32:43 <mkoderer> if this is the case I am good
15:32:55 <vponomaryov> mkoderer: answer is "it is already so"
15:32:59 <DaiDV> Sorry? I wonder what blueprint/spec or any introduction indicate "all drivers have to inherit from driver.ShareDriver"?
15:33:18 <ganso> DaiDV: I believe there is a document in devref
15:33:19 <mkoderer> vponomaryov: ok sry.. seems i misread the code
15:33:27 <bswartz> so mkoderer I think we all agree that drivers do need to inherit from sharedriver, and there aren't any that don't, so there's no problem
15:33:40 <mkoderer> bswartz: +1 next topic :)
15:33:44 <bswartz> cool, that was an easy one to resolve
15:33:47 <vponomaryov> mkoderer: EMC and NetApp drivers just do additional branching
15:33:51 <bswartz> #topic open discussion
15:33:56 <ganso> I have a topic
15:34:05 <bswartz> oh
15:34:23 <mkoderer> what's the state of the contaienr driver? :)
15:34:26 <bswartz> ganso: what is it?
15:34:42 <ganso> bswartz: additional instances in optimized migration
15:34:45 <bswartz> mkoderer: waiting for 2 +2s
15:34:53 <bswartz> #topic additional instances in optimized migration
15:34:54 <aovchinnikov_> mkoderer: its doing great!
15:35:01 <bswartz> oh yes this is an important one
15:35:15 <ganso> bswartz and I were discussing this week about an approach of creating an additional share instance in migration, similar to what the fallback approach does. Conceptually I think it is not accurate because I believe that for some vendors there may be only one instance at all times
15:35:32 <ganso> ^ this is for driver optimized migration, forgot to mention
15:35:39 <bswartz> I have always been against the plan to do driver-optimized migration without creating a second share instance
15:36:03 <vponomaryov> bswartz: +1, I am surprised it is not so
15:36:16 <vponomaryov> ganso: share instances were designed for it
15:36:27 <ganso> I would like to input from other vendors present here if there are in fact two instances in every migration, and that the source instance can be restored to at any time
15:36:30 <bswartz> regardless of what the driver does internally, I think the share API and manager should still create a new share instance for the "destination"
15:36:59 <vponomaryov> ganso: ZFSonLinux will have two
15:37:25 <vponomaryov> ganso: so, it "should" have two share instances
15:37:45 <bswartz> so for netapp, we have a technology that lets us move a flexvol (share) from one aggr (pool) to another by copying the data internally to our array
15:38:29 <xyang> bswartz: you are planning to implement driver-optimized migration in NetApp driver in Newton, right?
15:38:30 <bswartz> however its no problem for us to simply rename the flexvol to match the new share instance ID after it's moved, or to store a mapping from the new ID to the old name, if we choose not to rename i
15:38:34 <bswartz> rename it*
15:38:51 <gouthamr> xyang bswartz: hacking on that right now..
15:38:56 <bswartz> xyang: I don't work on the netapp driver so I don't know what the plans are
15:39:10 <xyang> gouthamr, bswartz: ok, thanks
15:39:15 <bswartz> I just know how I would do it if I was
15:39:16 <ganso> bswartz: if moving fails after some data is moved, can you restore the original?
15:39:25 <gouthamr> though, no, no official plans on getting it done. i just want to verify that we can support it
15:39:37 <ganso> one of the advantages in the fallback approach is that up to the last step in migration, you have the source instance intact
15:39:57 <bswartz> gouthamr: do you know the answer to ganso's question?
15:40:07 * gouthamr reading up
15:40:10 <bswartz> when using vol move, can you abort and go back to the pre-migration state?
15:40:36 <gouthamr> ganso: i think it makes sense in giving the driver two instances..
15:40:55 <ganso> I'm concerned the admin may indeed be confused on what to do if he sees two instances when the driver is migrating, and believes he can delete one of them to fix it up
15:41:11 <gouthamr> ganso: i did think of updating export_locations and all that, so it may just work for the NetApp driver to have just one migration instance
15:41:37 <gouthamr> ganso: s/migration instance/share instance
15:41:57 <bswartz> ganso: couldn't we solve that by having the driver implement a check if we got a deletion request for a share instance that was the source or destination of an actively migrating share?
15:42:22 <gouthamr> yeah, you have the TASK_STATE don't you?
15:42:24 <ganso> bswartz: that is an unexpected snceario
15:42:31 <vponomaryov> ganso: when you do "mv foo bar" you have two while operation not completed
15:42:39 <xyang> ganso: are you supposed to delete the original one after migration is complete?
15:42:40 <bswartz> ganso: you make it sound like it's valid for the admin to do that
15:42:48 <vponomaryov> ganso; so, admin won't nr confused
15:42:51 <ganso> xyang: yes
15:42:51 <bswartz> ganso: if we don't want to allow the admin to do that then we can lock it out at the API layer
15:42:58 <gouthamr> bswartz: +1
15:43:49 <bswartz> either it's okay for the admin to meddle with share instances that are part of a migration, in which case the driver needs to handle it, or it's not okay, in which case the API service should prevent it
15:44:04 <ganso> I am planning on manila itself cleaning the new instance if migration fails
15:44:46 <ganso> manager code will create the new instance db entry, and feed the driver with it as "migrating_share", so driver interface will have "source_share" and "migrating_share"
15:45:03 <ganso> if optimized migration fails, we should clean it up
15:45:22 <bswartz> why would we clean up in that case when we don't clean up in other cases?
15:45:23 <ganso> this should not be a dangerous operation at all, so the source_instance should be clean
15:45:39 <ganso> when we had only one instance, we always expect data to be intact whenever it fails
15:45:46 <bswartz> it's sometimes better to leave an object in an error state so the admin can investigate and figure out what went wrong
15:46:00 <gouthamr> ganso: i think we can leave it behind if it fails.. administrator can be told to worry about that instance..
15:46:16 <ganso> bswartz: we can leave the new instance in error state, but data has to be intact
15:46:41 <bswartz> yes I agree
15:46:59 <bswartz> in fact the source instance doesn't need to remain in an error state
15:47:12 <ganso> bswartz: yes, that's what I expect
15:47:12 <bswartz> the source instance could go back to a normal state in a failed migration
15:47:34 <bswartz> but the destination instance should hang around in whatever state it was in when we failed
15:47:44 <bswartz> so the admin can go look at what went wrong
15:47:53 <ganso> ok so, I will leave the new instance in error state
15:48:11 <ganso> there is a second topic that wasn't brought up before
15:48:28 <markstur_> so we should tell admins to check for an accumulation of errored instances?
15:48:51 <ganso> markstur_: we would document this
15:48:54 <ganso> I am considering now, after talking with Valeriy, that we want to allow share_network_id to be changed in a migration, if it is specified in API parameter
15:49:22 <gouthamr> migrate across share networks?
15:49:24 <bswartz> markstur_: yeah I think there needs to be a way for the admin to find those
15:49:35 <ganso> gouthamr: yes
15:49:36 <xyang> ganso: do we report migration fail in this case?  the original share becomes available, admin may think things are wroking fine
15:49:37 <bswartz> gouthamr: it similar to the force-retype
15:49:58 <ganso> xyang: we have the field task_state that would show the value "migration_error" in the main share model
15:50:05 <bswartz> ganso: the share network would only matter if there was a share server though
15:50:13 <ganso> bswartz: yes
15:50:26 <ganso> bswartz: this is another thing that is going to be taken care of
15:50:28 <bswartz> how to you migrate to a share server?
15:50:39 <bswartz> oh a new share server would get created
15:50:59 <bswartz> or an existing one would get reused
15:51:04 <ganso> bswartz: there will be a new method that validates driver compatibility to perform optimized migration, if driver agrees, and check if there is a share server in the destination host + share_network,
15:51:05 * bswartz considers
15:51:24 <ganso> if there isn't, we invoke setup_server in the destination host
15:51:51 <bswartz> okay but I can't think of a case where migration would fail if we don't allow changing the share network
15:52:08 <ganso> bswartz: when you create a share, you tie it to a share_network
15:52:16 <ganso> bswartz: that share_network may not span across other AZs
15:52:23 <bswartz> the problem here is that an admin-triggered migration should be unknown to the user (aside from any outages)
15:52:37 <bswartz> changing the share network would definitely be visible to the end user
15:52:39 <ganso> bswartz: the host the admin chooses to migrate the share to may be in another AZ
15:52:45 <DaiDV> bswartz: your question like "if I created new share instance, can we reused share server" ? right?
15:53:08 <gouthamr> ganso: so, if there is no share server, you create a new one, today.. don't you?
15:53:17 <ganso> gouthamr: fallback does that, easily
15:53:22 <vponomaryov> DaiDV: share server belongs to host, it always will be new share server
15:53:22 <bswartz> we need to add new user-visible change-AZ and change-share-network APIs that let the user change those things and trigger migrations on the backend if needed
15:53:34 <ganso> gouthamr: but within driver.migration_start, the driver cannot do that
15:53:45 <DaiDV> bswartz: s/ created /create
15:54:01 <ganso> bswartz: but wouldn't then migration become a user feature?
15:54:08 * bswartz thinks more
15:54:19 <bswartz> okay I see it now
15:54:22 <xyang> bswartz: then migration becomes tenant action?
15:54:30 <ganso> xyang: yea, it would
15:54:43 <bswartz> yes the force-retype style of admin-migration would cause a user-visible change too, and for good reason
15:54:47 <ganso> my concern is, there are several variables that bind a share and prevent it from being moved
15:54:55 <bswartz> therefore there's no reason not to do something similar for AZs or share networks
15:55:10 <bswartz> okay I'm on board
15:55:33 <bswartz> to answer xyang's question, migration won't ever be a tenant action, because tenants don't know about backends, but...
15:55:51 <ganso> there is an alternative
15:56:01 <bswartz> ...tenant should be able to share-retype, share-change-az, and share-change-share-network, which might trigger migrations indirectly
15:56:40 <ganso> allow only fallback migration to do this kind of stuff
15:56:49 <bswartz> oh and don't forget everyone's favorite: share-change-protocol
15:56:54 <ganso> bswartz: lol
15:57:05 <tbarron> :D
15:57:10 <cknight> :-(
15:57:20 <zhongjun_> :)
15:57:24 <gouthamr> not cknight's favorite :)
15:57:27 <DaiDV> vponomaryov: btw, why not we shared share server for two share instances?
15:58:09 <cknight> ganso: One more question about migration…
15:58:12 <vponomaryov> DaiDV: it will mean we refer to single object twice
15:58:13 <bswartz> ganso: we can certainly limit driver-assisted-migration to as small a subset of use cases as we want
15:58:46 <cknight> ganso: If I'm running a single-vendor Manila cloud, and that vendor can do optimized migration, is there a way to disable the fallback migration entirely?
15:59:01 <ganso> cknight: yes, latest patch includes that config option
15:59:09 <ganso> cknight: it is not merged yet
15:59:12 <cknight> ganso: great, thanks.
15:59:17 <bswartz> cknight: I think we agreed that it should be disable-able on a request by request basis
15:59:38 <bswartz> the user who calls the API should be allowed to veto fallback migrations
15:59:43 <cknight> bswartz: such an admin might want to know that "lossy" migration will never occur in his cloud
15:59:56 <vponomaryov> time check
16:00:08 <bswartz> I don't see why the admin would care -- the it's the user's data not her's
16:00:20 <ganso> bswartz: he does that by default, lossy default value is false, preventing fallback migration
16:00:23 <xarses> fuel was canceled
16:00:23 <bswartz> the owner of the data should make the decision
16:00:28 <xarses> so go ahead
16:00:39 <bswartz> xarses: ty
16:01:26 <bswartz> well I don't want to keep you all late
16:01:31 <ganso> bswartz: I guess I am done with my topic, unless there are more questions
16:01:37 <bswartz> topic to possibly continued at midcycle
16:01:39 <bswartz> ...
16:01:43 <bswartz> thanks everyone
16:01:46 <tbarron> bye
16:01:52 <bswartz> #endmeeting