Monday, 2016-08-29

*** gouthamr has joined #openstack-manila00:01
*** qeelee has joined #openstack-manila00:39
*** ameade has quit IRC01:10
zengyingzheHi all, please take a look at this patch https://review.openstack.org/#/c/331586/, thanks.01:11
*** scottda has quit IRC01:11
*** mtanino has joined #openstack-manila01:16
*** yangyapeng has joined #openstack-manila01:23
*** scottda has joined #openstack-manila01:23
*** xiaoyang has joined #openstack-manila01:23
*** magic has joined #openstack-manila01:24
*** yangyapeng has quit IRC01:24
*** yangyapeng has joined #openstack-manila01:24
*** magic is now known as Guest4707401:25
*** ameade has joined #openstack-manila01:25
*** xiaoyang has quit IRC01:28
*** Guest47074 has quit IRC01:28
openstackgerritNam Nguyen Hoai proposed openstack/manila: TrivialFix: Remove cfg import unused  https://review.openstack.org/36096001:28
*** yangyape_ has joined #openstack-manila01:31
*** yangyapeng has quit IRC01:35
*** kaisers_ has joined #openstack-manila01:36
*** kaisers_ has quit IRC01:41
*** wangqun has joined #openstack-manila01:47
*** vbellur has joined #openstack-manila02:32
*** kaisers_ has joined #openstack-manila03:26
*** kaisers_ has quit IRC03:30
*** rhefner has joined #openstack-manila03:42
openstackgerritYingzhe Zeng proposed openstack/manila: Fix test bugs for replication CI  https://review.openstack.org/36104203:47
*** gouthamr has quit IRC04:01
*** chlong has quit IRC04:12
*** chlong has joined #openstack-manila04:25
*** xiaoyang has joined #openstack-manila04:52
*** magic has joined #openstack-manila04:58
*** magic is now known as Guest9847404:59
*** xiaoyang has quit IRC05:02
*** kaisers_ has joined #openstack-manila05:14
*** mtanino has quit IRC05:15
*** kaisers_ has quit IRC05:19
*** shausy has joined #openstack-manila05:34
*** sandanar has joined #openstack-manila05:47
*** lpetrut has joined #openstack-manila05:58
openstackgerritBhagyashri Shewale proposed openstack/python-manilaclient: Replace functions 'Dict.get' and 'del' with 'Dict.pop'  https://review.openstack.org/36185806:09
*** sandanar has quit IRC06:12
*** akapil has joined #openstack-manila06:14
*** nkrinner_afk is now known as nkrinner06:22
openstackgerritgecong proposed openstack/manila: Add Python 3.5 classifier and venv  https://review.openstack.org/36188006:24
*** kaisers_ has joined #openstack-manila06:45
*** dsariel has joined #openstack-manila06:56
*** akapil has quit IRC06:57
*** pcaruana has joined #openstack-manila07:00
*** qeelee has quit IRC07:00
*** qeelee has joined #openstack-manila07:02
*** lpetrut has quit IRC07:02
toabctltbarron, bswartz, ganso, xyang1:  Regarding this FFE - I have the same opinion as cknight which is 'no'. For the same reasonas as cknight07:21
openstackgerritPeter Wang proposed openstack/manila: VNX: Use job for NFS share creation  https://review.openstack.org/35956707:25
Guest98474manila07:37
*** Guest98474 has quit IRC07:37
*** xiaoyang has joined #openstack-manila07:38
*** tovchinnikova has joined #openstack-manila07:39
*** xiaoyang has quit IRC07:42
*** xiaoyang has joined #openstack-manila07:42
xiaoyanghow to use manila in public cloud?07:43
*** aovchinnikov has joined #openstack-manila07:49
*** qeelee has quit IRC07:50
dgonzalezganso, bswartz: Is the gate stable again after https://review.openstack.org/#/c/361413/ ?07:53
*** daidv has joined #openstack-manila08:00
*** dsariel has quit IRC08:09
*** dsariel has joined #openstack-manila08:09
*** daidv has quit IRC08:13
*** daidv has joined #openstack-manila08:13
*** daidv has quit IRC08:19
*** qeelee has joined #openstack-manila08:25
*** akapil has joined #openstack-manila08:37
*** qeelee has quit IRC08:48
*** lpetrut has joined #openstack-manila08:57
*** qeelee has joined #openstack-manila09:05
*** senk has joined #openstack-manila09:17
*** qeelee has quit IRC09:33
*** qeelee has joined #openstack-manila09:49
*** jcsp has joined #openstack-manila09:50
*** zigo_ is now known as zigo09:56
*** yangyape_ has quit IRC10:08
*** shausy has quit IRC10:08
*** shausy has joined #openstack-manila10:08
*** qeelee has quit IRC10:37
*** shausy has quit IRC10:37
*** shausy has joined #openstack-manila10:38
*** qeelee has joined #openstack-manila10:39
*** qeelee has quit IRC10:39
*** akapil has quit IRC10:41
*** akapil has joined #openstack-manila10:42
*** wangqun has quit IRC10:44
*** gaurangt has joined #openstack-manila11:05
*** yangyapeng has joined #openstack-manila11:16
*** alyson_ has joined #openstack-manila11:21
*** ganso has joined #openstack-manila11:49
*** gouthamr has joined #openstack-manila12:06
*** tpsilva has joined #openstack-manila12:14
gansogouthamr: ping12:21
gouthamrganso: Good morning!12:24
gansogouthamr: Morning gouthamr! :)12:25
gansogouthamr: I liked your idea about including the task_state in the migration_get_progress response12:25
*** magic has joined #openstack-manila12:26
*** magic is now known as Guest9404812:26
gouthamrganso: yes.. i was wondering if removing 'total' from the progress would make sense too; because that seems to be the confusion?12:26
gansogouthamr: but ideally, all those scenario at line 1059 in https://review.openstack.org/#/c/332267/69/manila/share/api.py should be changed to non-error responses12:27
gansogouthamr: it is confusing because the current_file_progress is not shown12:27
gouthamrganso: hmmm.. how will that help?12:27
*** xiaoyang has quit IRC12:28
gansogouthamr: instead of saying "migration of share has already completed" as an error response, we would show "total_progress: 100, task_state: migration_success"12:28
*** xiaoyang has joined #openstack-manila12:28
gouthamrganso: oh..12:29
gansogouthamr: I prefer if those scenarios had progress hardcoded12:29
gansogouthamr: I think the current approach we have today shows a clear message12:29
gouthamrganso: so, when phase1 is done and API request is made to migration_get_progress: we'll not take the call to the backends?12:30
gansogouthamr: basically it "translates" the task_state into a friendlier message... but it is an error response12:30
gansogouthamr: no, I don't think it should be done12:30
gansogouthamr: although you said "it is on drivers"12:30
gansogouthamr: the user should not care that the migration_get_progress call is failing because the driver has not implemented that12:31
gouthamrganso: yes.. i still think drivers can handle that.. and probably have a mechanism for the fallback case to do the same12:31
gouthamrganso: we could make it a design requirement... ?12:31
gouthamrganso: i don't know why drivers will not be able to get progress after phase1 has been completed..12:31
*** Guest94048 has quit IRC12:31
gouthamrganso: any scenario that i'm missing?12:32
gansogouthamr: when phase1 is completed, the driver may clean up the replication/data migration jobs12:33
gansogouthamr: if driver is using private storage to store the job progress, that informaiton may be cleaned up12:33
gouthamrganso: afaics, migration_start - spawn a new share in the destination, initiate some data copy asynchronously | continue - keep checking on progress, try to fix any erros data copy if you can, raise on failure | migration_complete - switchover to your destination, and cleanup12:34
gansogouthamr: the moment when "migration_continue" returns True is when driver cleans up phase112:34
gouthamrganso: i don't agree12:35
gansogouthamr: it hasn't deleted the source share yet12:35
gouthamrganso: drivers shouldn't cleanup before migration_complete12:35
gouthamrganso: or even perform a switchover..12:35
gansogouthamr: not a switchover, or delete the source share12:36
gansogouthamr: but in the storage backend, the replication/data migration job may be finished, and it does not need to be stored or tracked anymore12:36
gansogouthamr: so I can see a scenario where the driver, when invoked by migration_get_progress, asks the backend what the job progress is... when phase1 is done, there is no such job anymore12:37
gouthamrganso: hmm, in that case, if you are unable to get the status, couldn't you try...except and look at the task_state and not reraise?12:37
*** timcl has joined #openstack-manila12:37
gansogouthamr: so when invoking migration_get_progress in this case, drivers will need to do something a bit different12:37
gansogouthamr: yes, could12:37
gansogouthamr: the progress can be returned and derived from other data12:37
gouthamrganso: i don't suspect a lot of backends may have that limitation.. maybe you can do that in the manager?12:38
gansogouthamr: but I prefer to have the approach we have to day, show a friendly message that the phase1 is done, than invoking the driver and requiring an additional complexity12:38
gouthamrganso: if phase1 is complete, and the driver/fallback code raises an exception in get_progress, set the progress yourself?12:38
gouthamrganso: i'm thinking of a time when you'll let drivers return more information :)12:38
gansogouthamr: yes, that was what I derived from your suggestion12:38
gouthamrganso: currently, i'm trying to log some useful information... the goal was to let administrators make informed decisions using that information..12:40
gansogouthamr: yes I will allow drivers to return more information (common information among several drivers) in migration_get_progress when task_state is 'driver_migration_in_progress" :)12:40
gansogouthamr: what kind of information/12:40
*** akapil has quit IRC12:41
*** akapil has joined #openstack-manila12:41
gouthamrganso: drivers can have different flavors of data movement.. so, sometimes the information necessary may be different.. but at the least, i wanted to send back a status, progress as a  percentage, estimated time of completion, and a message..12:42
gouthamr:D12:42
gouthamroverkill, i know. so, i am logging all of that..12:42
gansogouthamr: not overkill, it is good info... I am just concerned if we could get all drivers to do that :D12:42
gouthamrganso: no, probably not.. and it defeats abstraction if they have different levels/kinds of information unless they have single vendor deployments..12:43
gansogouthamr: that's the point, show only what everyone can do so it is included in the abstraction12:44
*** akapil has quit IRC12:44
*** akapil has joined #openstack-manila12:44
gansogouthamr: btw, line 906 in https://review.openstack.org/#/c/328431/43/manila/share/manager.py12:44
gansogouthamr: I did not change anything, got confused in your comment12:44
gouthamrganso: i ruined your weekend, didn't i :P12:45
gansogouthamr: lol no12:45
gansogouthamr: fortunately, I was free this weekend12:45
openstackgerritDaniel Gonzalez Nothnagel proposed openstack/manila: Add multi-segment support  https://review.openstack.org/27773112:45
gouthamrganso: oh. that, i guess you can ignore that.. i typed out a long message a few lines above that on something and later discarded it..12:45
gansogouthamr: if I had any appointments then I wouldn't be able to get everything done by this morning12:45
gansogouthamr: ok cool12:46
gansogouthamr: did you see my response to your migration-cancel suggestion?12:46
gouthamrganso: "to be able to always cancel, I would need to add task_state checks at each step checkpoint" - didn't understand this portion.. i made a couple of changes in my env.. could there be more?12:47
gansogouthamr: have you taken a look at share backup patch?12:48
gouthamrganso: yes.. i believe that canceling should only be possible during phase1, after phase1 before completion12:48
gouthamrganso: not during completion..12:48
gouthamrganso: no i haven't..12:48
gansogouthamr: hummm what you just said is how it is today... let me grab you a link to show you what I am talking about as "checkpoints"12:49
gouthamrganso: If it has an APIImpact (i'm sure it does), i need to get on it sometime soon.12:49
gansogouthamr: so you're the APIImpact guy?12:49
gansogouthamr: :P12:49
gouthamrganso: i've been called many names on this channel :P12:49
gansogouthamr: lol12:50
gansogouthamr: https://review.openstack.org/#/c/343980/9/manila/data/manager.py@38012:50
gouthamrganso: migration_canceling ?12:52
gansogouthamr: that's what I meant by "checkpoint"12:53
gouthamrganso: ^ as a busy task state will help you avoid any races12:53
gansogouthamr: so to be able to cancel migration at any point, not only while it is copying, I need to add a check like that at each step12:53
gansogouthamr: before creating a share server in the destination, before invoking the driver, before deleting the source instance in migration_complete12:54
gansogouthamr: to check if the user has cancelled the migration, so I don't proceed12:55
gansogouthamr: so *the code does not proceed12:55
gansogouthamr: that's what zhongjun_ is doing12:55
gansogouthamr: but if so, if you have JUST checked that variable, and then the user cancels, it is going to cancel only at the next checkpoint12:56
gansogouthamr: this is an additional complexity compared to allowing it to be cancellable only while it is copying, and telling the driver to stop it, as it is today's design12:56
gouthamrganso: admin should be able to cancel only when the task state is 'migration_driver_in_progress' or 'data_copying_in_progress' or 'data_copying_completed' or 'migration_driver_phase1_done'12:56
gansogouthamr: it would be an additional mechanism12:56
*** tovchinnikova has quit IRC12:57
gansogouthamr: oh you want to cancel when phase1 is done? like if admin regrets doing the migration and now that phase1 is done he wants to cancel, but he cannot do so anymore he could only invoke migration-complete, is that it?12:57
gouthamrganso: i meant allow cancelation when in the middle of phase1 or after, before waiting for completion..12:58
bswartzdgonzalez: it seems yes12:58
gouthamrganso: yes.. its entirely possible that data copy takes 10 hours and the admin goes home; comes back and decides not to go ahead with the completion..12:58
gansogouthamr: oh, I get it now lol12:59
gansogouthamr: great I like it :)12:59
gouthamrganso: the alternative currently is to force-delete the share instance and go out of band of manila nd make changes..12:59
gansogouthamr: hummm12:59
gansogouthamr: ok I will include in the next PS for the bugfix patch13:00
gouthamrganso: nice. sure thing; i'm ready with my +1 whenever you are, lol13:00
gansogouthamr: ok :)13:00
gansogouthamr: about your API comments in the newton-migration-improvements patch13:00
gouthamrganso: microversioning?13:01
gansogouthamr: I've never seen this before: "?skip_optimized_migration=null"13:01
gansogouthamr: I mean, not in OpenStack13:01
gouthamrganso: keyword args in queries need not have values13:01
gansogouthamr: I thought it accepted only POST13:01
gouthamrganso: wait, this is in the body..13:02
gansogouthamr: yes13:02
gansogouthamr: always body13:02
gouthamrganso: still, it's perfectly valid to have null13:02
*** pcaruana has quit IRC13:02
gouthamrganso: it's a BadRequest13:02
gansogouthamr: yes, the code is handling that13:03
gansogouthamr: if not found, it is False by default: skip_optimized_migration = params.get('skip_optimized_migration', False)13:03
gansogouthamr: then, if found, it is converted to boolean: skip_optimized_migration = strutils.bool_from_string(skip_optimized_migration, strict=True)13:03
gansogouthamr: are you saying we should accept it being null?13:04
gansogouthamr: in the body: {'migration_start': {'skip_optimized_migration': None} } ?13:04
gouthamrganso: try this: params = {'skip_optimized_migration': None} ; you should see a alueError(msg)13:04
gansogouthamr: yes13:04
gouthamrValueError13:04
gansogouthamr: it captures ValueError13:05
gouthamrganso: no, i'm saying.. separate the two things.. skip_optimized_migration = params.get('skip_optimized_migration') or False13:05
gansogouthamr: I see13:06
gansogouthamr: then it will accept the None and change it to False using the code you suggested13:07
gansogouthamr: cool13:07
gouthamrganso: yes13:07
gansogouthamr: thanks :)13:07
gouthamrganso: no problem..13:07
gansogouthamr: lastly, about the policy thing13:07
gansobswartz: ping13:07
gansogouthamr: so I am not sure if this idea I had is really crazy or not13:08
gansogouthamr: about disabling migration individually13:08
gouthamrganso: really crazy, yeah.13:08
gouthamr:P13:08
gansogouthamr: why do you think it is crazy?13:09
gouthamrganso: i don't think that level of granularity is expected; if its a really highly secure cloud, why would they run non-secure applications alongside secure ones?13:09
gansogouthamr: let's say company X has a cloud that it uses for its customers, and internally13:10
gansogouthamr: so company X would not do a migration that may not preserve-metadata or even because it handles users data because they have a contract saying they cannot do that13:11
gansogouthamr: but they would do it with their own data internally13:11
gouthamrganso: you already have a config option to disable fallback migration13:12
gansogouthamr: yes, at this moment, it disables for all backends, in this case I agree that the policy is better13:12
gansogouthamr: but I am considering the case of disabling selectively13:13
gansobswartz: do you consider valid the above scenario? ^13:13
gouthamrganso: if the company cares about this heterogeneity, they would buy storage that have efficient data movement technology?13:13
gouthamrganso: hmmm, so you're suggesting an opt in share/driver.py to disable migrations on a backend..13:15
gansogouthamr: yes. And disabling in the API would also disable for optimized migration as well13:15
gouthamrganso: would this opt cover migration both to and from cases?13:16
gansogouthamr: it has to start from the source backend13:16
gansogouthamr: it would cover only from13:16
gouthamrganso: why not 'to'.. you shouldn't be able to take your data to a backend and then not come back from it when your cloud's operational..13:17
*** pcaruana has joined #openstack-manila13:17
gouthamrganso: i may be wrong, but i recall a midcycle discussion where cknight was in favor of something like this13:18
gansogouthamr: well admin should know what he is doing :P13:18
gansogouthamr: in favor of blocking migration on specific backends?13:19
gouthamrganso: i *think*, he's not here yet to confirm13:19
gansogouthamr: but for other features that use migration, I need to make sure it does not go to backends that it is not allowed to come back, yes13:19
*** xyang1 has joined #openstack-manila13:20
gouthamrganso: yes.. that's true.. so maybe not do this until some use case arises? :)13:20
*** nkrinner has quit IRC13:21
gansogouthamr: I don't know... the impacts of disabling fallback migration per backend and disabling the migration API are different13:22
bswartzganso: pong13:22
gansogouthamr: I should talk to bswartz  and mkoderer, mkoderer__ to understand this better13:22
gansobswartz: could you please share your opinion on the above case?13:23
bswartzI'm unclear on the case13:23
bswartzsomeone wants to completely disable lossy migrations?13:24
*** nkrinner has joined #openstack-manila13:24
gansobswartz: yes, in migration's session in Austin, mkoderer raised this concern13:24
bswartzwhat is the concern? that someone will forget to send the --preserve-metadata flag?13:25
gansobswartz: I believe he said he has customers that either want to disable migration entirely, or want to disable fallback migration13:25
gansobswartz: preserve-metadata is True by default13:25
gansobswartz: I think maybe because os user agreements saying that user data should not be handled by the cloud13:25
gansobswartz: *there may be user agreements13:26
bswartzI don't agree with this13:26
bswartzAn API is an API13:26
bswartzif you choose not to use parts of it, that's up to you13:26
bswartzif you don't trust yourself (to not use certain features) then you can build a layer on top of the API and use that13:27
gansobswartz: thing is, in the future, share-retype may use it and the user may not be fully aware that it will do a migration13:27
bswartzI think I understand the concern but there has to be a better way to deal with it13:27
gansobswartz: I already have those switches implemented in the code, do you think I should remove them13:28
ganso?13:28
bswartzganso: that's ridiculous -- we're concerned that a user won't understand how to use a feature that doesn't even exist yet?13:28
*** rooneym has joined #openstack-manila13:28
bswartzwhen we add the feature we'll explain how it works -- people who fail to understand it do so at their own peril13:29
bswartzalso I think --preserve-metadata should default to false probably, but that's another topic13:29
*** porrua has joined #openstack-manila13:29
gansobswartz: I think that preserve-metadata gives enough control over the API, it will prevent fallback migration from running13:31
gansobswartz: the switches are mostly redundant13:31
gansobswartz: but I added because it was requested13:31
gansobswartz: so I guess I will just remove them13:31
*** nkrinner has quit IRC13:31
gansobswartz: and if someone is concerned, they can remove access through policy and would not require any code change, as gouthamr suggested13:32
*** hoonetorg has quit IRC13:33
*** gaurangt has left #openstack-manila13:34
*** eharney has joined #openstack-manila13:37
*** dustins has joined #openstack-manila13:40
*** nkrinner has joined #openstack-manila13:44
*** pcaruana has quit IRC13:55
bswartzwhich will you remove?13:56
bswartzis there some policy.json stuff to control the API behavior?13:57
gouthamrbswartz: you can turn off all the APIs or some of the APIs.. or we can make an API specific for fallback migration and control it with policy13:58
*** shausy has quit IRC13:58
bswartzyes but what are you going to remove?13:58
gouthamrbswartz: oh.. ganso was talking about two config opts.. disable_fallback_share_migration and disable_share_migration13:58
gouthamrbswartz: https://review.openstack.org/#/c/328431/43/manila/share/api.py13:59
*** akerr has joined #openstack-manila14:00
gouthamrbswartz: and https://review.openstack.org/#/c/328431/43/manila/share/manager.py14:00
*** aovchinnikov has quit IRC14:02
*** senk has quit IRC14:04
*** tpatzig_ has joined #openstack-manila14:04
*** marcusvrn_ has quit IRC14:04
*** tpatzig has quit IRC14:06
*** mkoderer has quit IRC14:06
*** mtanino has joined #openstack-manila14:07
*** mkoderer has joined #openstack-manila14:08
*** pcaruana has joined #openstack-manila14:09
*** ksumit has joined #openstack-manila14:15
*** dsariel has quit IRC14:23
*** yangyapeng has quit IRC14:24
*** ksumit has quit IRC14:34
bswartzgouthamr: I can see the argument for such config opts but they would make more sense as a policy thing than a config opt14:44
bswartzi.e. I'd rather see them go into policy.json than manila.conf14:44
*** kaisers_ has quit IRC14:46
*** eharney has quit IRC14:59
gouthamrbswartz: +1 i agree..14:59
dustinsbswartz: ping15:00
bswartzdustins: pong15:01
dustinsbswartz: Hey, I was wondering if I'd need an FFE for landing this patch for updating our Tempest tests to use the new stable clients https://review.openstack.org/#/c/334596/1915:02
dustinsI chatted with andreaf last week about getting this in, and it looks like the main hurtle is the missing stable IdentityClient interface that the scenario tests need15:03
bswartzdustins: no15:03
bswartzQA improvements are not subject to FF15:03
dustins\o/15:03
dustinsThat's good to know15:03
bswartzso we can merge it anytime (except for the quiet periods before the RCs/final release)15:03
dustinsRight, that's understandable15:04
dustinsDon't wanna bust up the gate when everyone's shoving to get through it :D15:04
bswartzI wish everyone would work on QA improvements between FF and release, but that will never happen15:04
dustinsNot with that attitude :P15:05
dustinsI wish I had more time to work on it myself, if I'm honest15:05
bswartztrue, I need to improve my attitude15:07
bswartzI'm so glad everyone is going to work on QA improvements between FF and release!15:08
dustinsThere we go :D15:14
*** hoonetorg has joined #openstack-manila15:16
*** eharney has joined #openstack-manila15:30
*** porrua has quit IRC15:34
*** pcaruana has quit IRC15:43
*** porrua has joined #openstack-manila15:57
*** david-lyle_ is now known as david-lyle16:01
*** nkrinner is now known as nkrinner_afk16:05
*** sandanar has joined #openstack-manila16:17
openstackgerritAlyson proposed openstack/manila: Fix Manila HNAS driver managing a share twice  https://review.openstack.org/35590616:21
*** kaisers_ has joined #openstack-manila16:35
*** vbellur has quit IRC16:35
*** lpetrut has quit IRC16:38
*** kaisers_ has quit IRC16:40
openstackgerritBen Swartzlander proposed openstack/manila: [ZFSonLinux] Add share migration support  https://review.openstack.org/35341716:43
bswartz^ this is a simple rebase, didn't actually fix the driver16:43
gouthamrganso: ping17:05
gansogouthamr: pong17:05
gouthamrganso: so 'inactive' can be removed as a valid share state?17:05
gansogouthamr: yes17:05
gouthamrganso: nice.. need an update in models.py..17:05
gansogouthamr: really? been doing that since liberty17:06
gansogouthamr: update where?17:06
gouthamrganso: ? i noticed the removal in your driver fixes patch17:06
gouthamrhttps://github.com/openstack/manila/blob/addb65225d015e5489ab1898d78011380c2be4e6/manila/db/sqlalchemy/models.py#L79617:07
gansogouthamr: that's for share server17:09
*** sandanar has quit IRC17:09
gansogouthamr: the share instance model does not have that enum17:09
gouthamrganso: ah.. yes, you're right but the unit tests and the API have it: https://github.com/openstack/manila/blob/addb65225d015e5489ab1898d78011380c2be4e6/manila/share/api.py#L68317:11
gouthamrhttps://github.com/openstack/manila/blob/bdea762769f9e5a69f5e690c18a0d93fc017de61/manila/tests/db/sqlalchemy/test_models.py#L5517:11
gansogouthamr: yes, they do... what does need updating?17:12
gouthamrganso: asking for it to be removed..17:12
gansogouthamr: I still need it to suport INACTIVE17:13
gansogouthamr: let me get you a link17:13
gouthamrganso: oh...17:13
*** aovchinnikov has joined #openstack-manila17:14
gansogouthamr: https://review.openstack.org/#/c/332267/70/manila/share/manager.py@117017:15
gouthamrganso: oh, yes.. didn't notice that17:17
gouthamrthanks..17:17
gouthamrganso: did you see the comment on teh rpc call?17:17
gansogouthamr: no, haven't seen17:19
gouthamrganso: https://review.openstack.org/#/c/332267/ <--17:19
gansogouthamr: so it creates another safe thread17:19
gansogouthamr: and the init_host can proceed to do other stuff17:20
gansogouthamr: and either way, that will be removed in the newton-migration-improvements patch17:20
gouthamrganso: :P17:20
gouthamrganso: okay.. it is getting hard to see these changes. that patch needs to merge17:21
gansogouthamr: yes17:21
gansogouthamr: Ideally I should improve tempest tests to include the cancel scenario I just added17:26
gouthamrganso: okay..17:27
gansogouthamr: code worked testing manually17:27
*** lpetrut has joined #openstack-manila17:28
openstackgerritAlyson proposed openstack/manila: Fix Manila HNAS driver managing a share twice  https://review.openstack.org/35590617:32
*** eharney_ has joined #openstack-manila17:49
*** eharney has quit IRC17:51
*** eharney_ is now known as eharney17:55
*** akapil_ has joined #openstack-manila18:03
*** akapil has quit IRC18:06
*** lpetrut has quit IRC18:15
*** cknight has joined #openstack-manila18:20
*** aovchinnikov has quit IRC18:21
openstackgerritRodrigo Barbieri proposed openstack/manila: Fix Share Migration improper behavior for drivers  https://review.openstack.org/33226718:22
*** kaisers_ has joined #openstack-manila18:24
*** vbellur has joined #openstack-manila18:25
openstackgerritMerged openstack/manila-ui: Remove incorrect docstrings  https://review.openstack.org/34084318:27
*** kaisers_ has quit IRC18:29
*** Suyi_ has joined #openstack-manila18:31
*** senk has joined #openstack-manila18:45
*** zhugaoxiao has quit IRC19:16
*** zhugaoxiao has joined #openstack-manila19:16
openstackgerritRodrigo Barbieri proposed openstack/manila: Share migration Newton improvements  https://review.openstack.org/32843119:16
openstackgerritBen Swartzlander proposed openstack/manila: [ZFSonLinux] Add share migration support  https://review.openstack.org/35341719:29
*** akapil_ has quit IRC19:31
*** kaisers_ has joined #openstack-manila20:03
*** darrenc has quit IRC20:05
gouthamrbswartz xyang1: would appreciate your review on https://review.openstack.org/#/c/332267 -> a bugfix that is the base of a series of migration patches.. I've tested the fixes and they work against a driver optimized migration..20:05
*** darrenc has joined #openstack-manila20:07
bswartzgouthamr: I *am* reviewing that20:08
gouthamrbswartz: nice.. thank you.20:08
*** porrua has quit IRC20:09
*** lpetrut has joined #openstack-manila20:11
*** Suyi_ has quit IRC20:17
openstackgerritJay Mehta proposed openstack/manila: HPE 3PAR driver pool support  https://review.openstack.org/32955220:29
*** Suyi_ has joined #openstack-manila20:34
*** senk has quit IRC20:46
*** cknight has quit IRC20:52
openstackgerritBen Swartzlander proposed openstack/manila: [ZFSonLinux] Add share migration support  https://review.openstack.org/35341720:52
*** akerr has quit IRC20:53
openstackgerritRodrigo Barbieri proposed openstack/manila: Fix Share Migration improper behavior for drivers  https://review.openstack.org/33226720:56
*** gouthamr has quit IRC21:02
openstackgerritRodrigo Barbieri proposed openstack/manila: Fix Share Migration improper behavior for drivers  https://review.openstack.org/33226721:19
*** dustins has quit IRC21:31
*** eharney has quit IRC21:34
*** rooneym has quit IRC21:39
openstackgerritJay Mehta proposed openstack/manila: HPE 3PAR driver pool support  https://review.openstack.org/32955222:03
*** assassin has quit IRC22:12
*** cknight has joined #openstack-manila22:25
*** cknight has quit IRC22:32
*** xyang1 has quit IRC22:41
*** timcl has quit IRC22:43
openstackgerritIvan Chavero proposed openstack/puppet-manila: Add more info for deprecated parameters documentation.  https://review.openstack.org/36248222:49
*** lpetrut has quit IRC23:04
*** gouthamr has joined #openstack-manila23:07
openstackgerritRodrigo Barbieri proposed openstack/manila: Share migration Newton improvements  https://review.openstack.org/32843123:10
*** tpsilva has quit IRC23:54

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!