| *** mtanino has quit IRC | 00:09 | |
| *** haomaiwang has quit IRC | 00:30 | |
| *** esker has joined #openstack-manila | 00:54 | |
| *** tbarron has quit IRC | 01:37 | |
| *** tbarron has joined #openstack-manila | 01:38 | |
| *** BitSmith has joined #openstack-manila | 02:03 | |
| *** haomaiwang has joined #openstack-manila | 02:24 | |
| openstackgerrit | Merged openstack/manila: Make devstack install manila-ui if horizon is enabled https://review.openstack.org/184778 | 02:27 |
|---|---|---|
| *** vbellur has joined #openstack-manila | 02:31 | |
| openstackgerrit | Merged openstack/manila: glusterfs: Edit doc and comments https://review.openstack.org/185309 | 02:35 |
| *** BitSmith has quit IRC | 02:36 | |
| *** zhonghua-lee has joined #openstack-manila | 02:51 | |
| openstackgerrit | zhongjun proposed openstack/manila: Huawei manila driver code refactoring https://review.openstack.org/176637 | 03:10 |
| *** zaitcev has quit IRC | 03:46 | |
| *** lpetrut has joined #openstack-manila | 03:46 | |
| *** haomaiwang has quit IRC | 03:57 | |
| *** zhonghua-lee has quit IRC | 04:00 | |
| *** haomaiwang has joined #openstack-manila | 04:01 | |
| *** xyang1 has quit IRC | 04:11 | |
| *** bswartz has quit IRC | 04:28 | |
| *** rcallawa has quit IRC | 04:28 | |
| *** sgotliv has joined #openstack-manila | 04:30 | |
| *** lpetrut has quit IRC | 04:39 | |
| *** haomaiwang has quit IRC | 04:39 | |
| *** cknight has quit IRC | 04:49 | |
| *** openstackgerrit has quit IRC | 04:50 | |
| *** openstackgerrit has joined #openstack-manila | 04:50 | |
| openstackgerrit | Merged openstack/python-manilaclient: Drop incubating theme from docs https://review.openstack.org/186199 | 04:55 |
| *** nkrinner has joined #openstack-manila | 04:59 | |
| *** lpetrut has joined #openstack-manila | 05:24 | |
| openstackgerrit | Merged openstack/manila: Drop incubating theme from docs https://review.openstack.org/186196 | 05:26 |
| openstackgerrit | Merged openstack/manila: Remove ServiceClient from share_client https://review.openstack.org/185152 | 05:27 |
| *** vbellur has quit IRC | 05:44 | |
| *** haomaiwa_ has joined #openstack-manila | 05:56 | |
| *** vbellur has joined #openstack-manila | 06:23 | |
| *** lpetrut has quit IRC | 06:38 | |
| *** lpetrut has joined #openstack-manila | 07:02 | |
| *** lpetrut has quit IRC | 07:11 | |
| *** lpetrut has joined #openstack-manila | 07:22 | |
| *** zhonghua-lee has joined #openstack-manila | 07:27 | |
| *** Maike has joined #openstack-manila | 07:29 | |
| *** u_glide has joined #openstack-manila | 07:46 | |
| openstackgerrit | Igor Malinovskiy proposed openstack/manila: Implement extend_share() method in Generic driver https://review.openstack.org/182383 | 07:48 |
| openstackgerrit | Igor Malinovskiy proposed openstack/manila: Implement tempest tests for share extend API https://review.openstack.org/183497 | 07:49 |
| openstackgerrit | Igor Malinovskiy proposed openstack/manila: Implement tempest tests for share extend API https://review.openstack.org/183497 | 07:52 |
| openstackgerrit | Igor Malinovskiy proposed openstack/manila: Add share shrink API https://review.openstack.org/184069 | 07:55 |
| openstackgerrit | Igor Malinovskiy proposed openstack/python-manilaclient: Add share shrink API https://review.openstack.org/185380 | 08:06 |
| openstackgerrit | li,chen proposed openstack/manila: Implement versioned object for share export locations https://review.openstack.org/173692 | 08:34 |
| *** kaisers has joined #openstack-manila | 08:37 | |
| Maike | Hi, I'm using devstack kilo on Ubuntu 14.04 LTS. Where can I change the setting that configures which manila service image should be used by manila? | 08:37 |
| *** haomaiwa_ has quit IRC | 08:39 | |
| vponomaryov | Maike: https://github.com/openstack/manila/blob/770c272b/devstack/plugin.sh#L89 | 08:40 |
| vponomaryov | Maike: in link provided list of env vars that you can redefine and do it in the same way as all other devstack config changes you do - using localrc file | 08:41 |
| Maike | vponomaryov: okay, thanks. I already found this part, but it doesn't worked... I will try it again | 08:43 |
| vponomaryov | Maike: how exactly id does not work? | 08:44 |
| vponomaryov | s/id/it/ | 08:44 |
| *** 7YUAAETE8 has joined #openstack-manila | 08:45 | |
| *** mkoderer has quit IRC | 08:50 | |
| *** mkoderer has joined #openstack-manila | 08:54 | |
| *** rraja has joined #openstack-manila | 08:58 | |
| *** lpetrut1 has joined #openstack-manila | 09:13 | |
| *** lpetrut has quit IRC | 09:14 | |
| *** Triveni has joined #openstack-manila | 09:19 | |
| *** 7YUAAETE8 has quit IRC | 09:27 | |
| *** rraja_ has joined #openstack-manila | 09:55 | |
| *** rraja has quit IRC | 09:57 | |
| openstackgerrit | zhongjun proposed openstack/manila: Huawei manila driver code refactoring https://review.openstack.org/176637 | 09:57 |
| *** rraja_ has quit IRC | 09:58 | |
| *** rraja has joined #openstack-manila | 10:00 | |
| *** zhonghua-lee has quit IRC | 10:22 | |
| *** Triveni has quit IRC | 10:49 | |
| *** rcallawa has joined #openstack-manila | 10:57 | |
| *** rcallawa has quit IRC | 11:00 | |
| *** rcallawa has joined #openstack-manila | 11:01 | |
| *** rcallawa_ has joined #openstack-manila | 11:05 | |
| *** rcallawa has quit IRC | 11:09 | |
| *** rcallawa_ has quit IRC | 11:18 | |
| *** rcallawa has joined #openstack-manila | 11:19 | |
| *** zhonghua-lee has joined #openstack-manila | 11:22 | |
| *** timcl has joined #openstack-manila | 11:27 | |
| *** haomaiwang has joined #openstack-manila | 11:28 | |
| *** openstackgerrit has quit IRC | 11:39 | |
| *** openstackgerrit has joined #openstack-manila | 11:39 | |
| *** haomaiwang has quit IRC | 11:40 | |
| *** marcusvrn1 has joined #openstack-manila | 11:52 | |
| *** marcusvrn has quit IRC | 11:55 | |
| *** ganso_ has joined #openstack-manila | 11:55 | |
| *** zhonghua-lee has quit IRC | 11:56 | |
| *** rcallawa has quit IRC | 11:56 | |
| *** akerr has joined #openstack-manila | 12:04 | |
| *** akerr_ has joined #openstack-manila | 12:05 | |
| openstackgerrit | Julia Varlamova proposed openstack/manila: Share_server-pool mapping https://review.openstack.org/180450 | 12:06 |
| openstackgerrit | Julia Varlamova proposed openstack/manila: Add PoolFilter for Manila scheduler https://review.openstack.org/184053 | 12:06 |
| *** rraja has quit IRC | 12:08 | |
| *** akerr has quit IRC | 12:08 | |
| *** zhonghua-lee has joined #openstack-manila | 12:24 | |
| *** rcallawa has joined #openstack-manila | 12:39 | |
| *** kaisers has quit IRC | 12:40 | |
| *** kaisers has joined #openstack-manila | 12:41 | |
| *** rraja has joined #openstack-manila | 12:47 | |
| *** bswartz has joined #openstack-manila | 12:48 | |
| *** zhonghua-lee has quit IRC | 12:57 | |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: Remove unused attr status from models https://review.openstack.org/186374 | 13:02 |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: Remove unused attr status from models https://review.openstack.org/186374 | 13:08 |
| *** akshai has joined #openstack-manila | 13:09 | |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: Remove unused attr status from models https://review.openstack.org/186374 | 13:09 |
| *** esker has quit IRC | 13:12 | |
| *** Maike_ has joined #openstack-manila | 13:14 | |
| *** bswartz has quit IRC | 13:16 | |
| *** Maike has quit IRC | 13:18 | |
| *** bswartz has joined #openstack-manila | 13:22 | |
| *** akerr_ has quit IRC | 13:24 | |
| *** dustins has joined #openstack-manila | 13:29 | |
| *** timcl has quit IRC | 13:46 | |
| *** vbellur has quit IRC | 13:52 | |
| *** xyang1 has joined #openstack-manila | 13:57 | |
| *** nkrinner has quit IRC | 13:59 | |
| *** Maike__ has joined #openstack-manila | 14:01 | |
| *** timcl has joined #openstack-manila | 14:03 | |
| *** xyang1 has quit IRC | 14:04 | |
| *** vkmc has joined #openstack-manila | 14:05 | |
| *** Maike_ has quit IRC | 14:05 | |
| *** rushil has joined #openstack-manila | 14:07 | |
| *** rushil has quit IRC | 14:08 | |
| *** cknight has joined #openstack-manila | 14:13 | |
| *** rushil has joined #openstack-manila | 14:18 | |
| *** mtanino has joined #openstack-manila | 14:28 | |
| *** Maike__ has quit IRC | 14:33 | |
| *** xyang1 has joined #openstack-manila | 14:35 | |
| *** bswartz has quit IRC | 14:47 | |
| *** bswartz has joined #openstack-manila | 14:47 | |
| *** esker has joined #openstack-manila | 14:48 | |
| *** markstur has quit IRC | 14:53 | |
| *** Zhongjun has joined #openstack-manila | 14:54 | |
| *** markstur has joined #openstack-manila | 14:55 | |
| *** mtanino has quit IRC | 15:06 | |
| *** mtanino has joined #openstack-manila | 15:07 | |
| *** mtanino has quit IRC | 15:07 | |
| *** mtanino has joined #openstack-manila | 15:08 | |
| *** fthiagogv has joined #openstack-manila | 15:16 | |
| *** vbellur has joined #openstack-manila | 15:21 | |
| *** timcl has quit IRC | 15:25 | |
| *** akerr has joined #openstack-manila | 15:27 | |
| *** timcl has joined #openstack-manila | 15:30 | |
| *** akerr has quit IRC | 15:35 | |
| *** timcl has quit IRC | 15:35 | |
| *** akerr has joined #openstack-manila | 15:35 | |
| *** fthiagogv has quit IRC | 15:37 | |
| *** timcl has joined #openstack-manila | 15:37 | |
| *** fthiagogv has joined #openstack-manila | 15:37 | |
| *** chlong has quit IRC | 15:54 | |
| *** mtanino_ has joined #openstack-manila | 16:02 | |
| *** mtanino has quit IRC | 16:03 | |
| *** absubram has joined #openstack-manila | 16:05 | |
| *** rraja has quit IRC | 16:07 | |
| *** chlong has joined #openstack-manila | 16:07 | |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: Remove unused attr status from models https://review.openstack.org/186374 | 16:07 |
| *** Triveni has joined #openstack-manila | 16:17 | |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: Fix policy check for API 'security service update' https://review.openstack.org/186460 | 16:22 |
| *** Triveni has quit IRC | 16:27 | |
| *** lpetrut1 has quit IRC | 16:28 | |
| *** haomaiwang has joined #openstack-manila | 16:29 | |
| *** Triveni has joined #openstack-manila | 16:45 | |
| *** Triveni has quit IRC | 16:52 | |
| *** akshai has quit IRC | 16:56 | |
| *** akshai has joined #openstack-manila | 16:58 | |
| *** lpetrut has joined #openstack-manila | 17:01 | |
| *** rcallawa_ has joined #openstack-manila | 17:02 | |
| *** rushil has quit IRC | 17:02 | |
| *** akshai has quit IRC | 17:04 | |
| *** akshai has joined #openstack-manila | 17:05 | |
| *** rcallawa has quit IRC | 17:05 | |
| *** rushil has joined #openstack-manila | 17:05 | |
| *** zaitcev has joined #openstack-manila | 17:30 | |
| *** sage has quit IRC | 17:31 | |
| *** sage has joined #openstack-manila | 17:32 | |
| *** sage has quit IRC | 17:48 | |
| bswartz | ganso_: ping | 17:55 |
| ganso_ | bswartz: pong | 17:59 |
| bswartz | ganso_: I replied to your ML post | 17:59 |
| bswartz | I wanted to know about your proposal to implement migration without creating a second DB row | 17:59 |
| bswartz | since that's new to me | 17:59 |
| *** akshai has quit IRC | 18:00 | |
| *** vbellur has quit IRC | 18:01 | |
| ganso_ | bswartz: I will reply in detail to the ML, but in summary, Valeriy suggested not creating a temporary DB entry, so the ID used would always be the original one | 18:01 |
| *** rcallawa_ has quit IRC | 18:01 | |
| bswartz | ganso_: here is fine also | 18:02 |
| ganso_ | vponomaryov: ^ | 18:02 |
| *** rcallawa has joined #openstack-manila | 18:02 | |
| bswartz | or a google hangout if that would be easier for you | 18:02 |
| bswartz | I'm really curious though | 18:02 |
| ganso_ | ok, we can discuss it here | 18:02 |
| ganso_ | the original approach was based on Cinder's: create a totally new volume in the destination backend, new API ID, new physical volume ID | 18:03 |
| ganso_ | then after copying data, copy all DB properties from the new DB entry to the original one | 18:03 |
| bswartz | yes | 18:03 |
| ganso_ | so the original API ID would be linked to the physical share ID, because the physical share ID is a property value | 18:04 |
| ganso_ | that is transferable | 18:04 |
| bswartz | the advantage to that approach is that drivers don't need to change at all for it to work in the fallback case | 18:04 |
| ganso_ | yes | 18:04 |
| *** rushil has quit IRC | 18:04 | |
| bswartz | so what is the new proposal | 18:04 |
| *** akshai has joined #openstack-manila | 18:05 | |
| ganso_ | take by example that the generic driver is storing the volume_id in the private driver storage | 18:05 |
| ganso_ | the volume_id in this case is the physical share ID I mentioned above | 18:06 |
| ganso_ | when we create the new share in the destination backend, we would store that value in the private driver storage | 18:06 |
| ganso_ | since private driver storage is restricted by backends, it will not conflict with the source backend private driver storage | 18:07 |
| bswartz | but you can't create a new share without creating a DB row first | 18:07 |
| ganso_ | I thought so too at first, I am still analyzing that, and so far, it looks to me that we can do so by providing the source DB entry, and skip the API call | 18:07 |
| bswartz | unless we make a new driver entry point called "create_migration_destination_share" which creates a share that has no DB ro | 18:07 |
| bswartz | row | 18:07 |
| ganso_ | go straight to the manager | 18:07 |
| bswartz | then you'd have 2 drivers thinking they owned the same share | 18:08 |
| ganso_ | but it is a little dangerous, I am still analyzing that, it would be complicated to cleanup error states | 18:08 |
| ganso_ | yes | 18:08 |
| bswartz | I don't think that's a smart approach | 18:09 |
| bswartz | the error cases would be very hard to deal with | 18:09 |
| ganso_ | yes | 18:09 |
| bswartz | if you think about either or both backends being bounced in the middle of the migration operation | 18:09 |
| ganso_ | using the temporary Cinder approach is much easier to handle | 18:09 |
| bswartz | I would be less scared if we made it an entirely separate driver call, but then we wouldn't have a universal fallback approach for share migration | 18:10 |
| ganso_ | a separate call would be more secure, indeed | 18:10 |
| ganso_ | and it would be related to the universal fallback approach | 18:10 |
| ganso_ | the driver migration approach would be before that | 18:11 |
| *** rushil has joined #openstack-manila | 18:11 | |
| bswartz | were the other 2 approaches discussed? | 18:11 |
| ganso_ | if the driver is unsuccessful migrating, then we proceed to generic migration | 18:11 |
| ganso_ | which is the approach based on Cinder's | 18:11 |
| ganso_ | driver migration may not even create other DB entries, it is up to driver | 18:11 |
| ganso_ | in fact, if I am not mistaken, the driver is not allowed to do that | 18:12 |
| bswartz | but you can't do a generic migration without either (1) doing the scary thing you proposed above or (2) forcing all drivers to implement a new method or (3) creating 2 DB rows | 18:12 |
| ganso_ | what do you mean by (2)? | 18:13 |
| *** sage has joined #openstack-manila | 18:13 | |
| bswartz | correct, the driver cannot create new DB entries -- the theory would be that the scheduler/API would create the new row and then tell the driver to try to do optimized migration from one share to the other | 18:13 |
| bswartz | by (2) I mean make drivers implement something like "create_migration_destination_share" so the driver knows that it's creating a migration destination instead of a normal share and | 18:14 |
| bswartz | s/and// | 18:14 |
| ganso_ | not really, the way I see the driver would not really need to interact with the scheduler/API, driver migration is when it migrates from vendor A backend to another vendor A backend, so it can really do it in background, at the backend level, and just update the export location | 18:15 |
| bswartz | in case it's not obvious I really like the elegance of the cinder approach to migration -- I just think they mishandled the ID swap approach | 18:16 |
| bswartz | ganso_: let me understand your proposal better then | 18:17 |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: Transform share and share servers statuses to lowercase https://review.openstack.org/186520 | 18:17 |
| bswartz | what decides where the destination share will go? | 18:17 |
| bswartz | suppose I have a share on backend A, which is a netapp | 18:17 |
| ganso_ | in (2), my original idea was to have the manager implement the "create_migration_destination_share" and call the driver's "create_share", but since the driver will have total control over the private storage, then it may have to be a different method, I am still looking at that | 18:17 |
| bswartz | and the administrator says: migrate to backend B, which is also netapp | 18:17 |
| bswartz | and what if the administrator says: migrate to backend C, which is HDS? | 18:18 |
| bswartz | what would the Host field in the DB for that share say? | 18:19 |
| ganso_ | in your first scenario, the "migrate_share" method starts, calls "driver.migrate_share" and it returns a model update, done | 18:19 |
| bswartz | calls that method on which backend? | 18:20 |
| ganso_ | in your second scenario, from netapp to HDS, the "migrate_share" manager method starts", calls "driver.migrate_share", which returns None, and the code proceeds to generic migration, which we are still debating how to properly handle the IDs | 18:21 |
| ganso_ | the source backend | 18:21 |
| bswartz | ganso_: and how does the source backend know where it's supposed to go? | 18:21 |
| bswartz | hold on I want to stay on the first example before going to the second | 18:22 |
| ganso_ | I haven't really looked how Cinder drivers implement their own migration | 18:23 |
| ganso_ | hold on let me grab a line of code | 18:23 |
| bswartz | it's just that if we never store the destination of the migration anywhere, I'm confused about how the source backend knows where to try to migrate to and how we recover from a crash before the migration is done | 18:24 |
| ganso_ | https://github.com/openstack/cinder/blob/master/cinder/volume/manager.py#L1420 | 18:24 |
| ganso_ | it has the host parameter | 18:24 |
| ganso_ | which is the destination host | 18:25 |
| ganso_ | I remember taking a quick look somewhere that there are ways for driver to obtain host information based on that string value | 18:25 |
| bswartz | ganso_: ugh | 18:25 |
| bswartz | I didn't realize cinder did that for the optimized case | 18:26 |
| bswartz | does anyone implement that codepath? | 18:26 |
| *** dustins has quit IRC | 18:26 | |
| bswartz | because I think it's a giant bug waiting to happen | 18:26 |
| ganso_ | I am not sure, I may have seen one vendor implementing that when I first started studying it, after our previous midcycle meeting | 18:27 |
| ganso_ | I can look it up again | 18:27 |
| bswartz | clearly in cinder very different things happen with optimized and non-optimized volume migration | 18:27 |
| bswartz | I kind of think that's bad by itself | 18:27 |
| ganso_ | the way I understood is that | 18:28 |
| ganso_ | let's say my backend is HDS | 18:28 |
| bswartz | I would rather have the 2 codepaths as similar as possible, with the optimization just being how the data gets from the source to the destination | 18:28 |
| ganso_ | and it is performing migration to another HDS backend | 18:28 |
| ganso_ | the source backend would talk to the other backend inside that method, like, issue commands to create the share in the destination backend, because HDS drivers know the protocol to talk to each other | 18:29 |
| ganso_ | the way I see it, this is the optimized approach | 18:29 |
| *** Zhongjun has quit IRC | 18:29 | |
| bswartz | you mean one driver instance talks to 2 storage controllers | 18:29 |
| bswartz | not 2 drivers talking to eachother | 18:29 |
| ganso_ | yes | 18:29 |
| ganso_ | like a cluster array | 18:30 |
| bswartz | I agree that's the right way to handle the data movement | 18:30 |
| bswartz | My issues are around the database/state-trackinf side of this | 18:30 |
| bswartz | tracking | 18:31 |
| ganso_ | the database would not be touched in that driver migration approach | 18:31 |
| bswartz | right | 18:31 |
| ganso_ | because the model update returned would only update the export location | 18:31 |
| bswartz | so if anything at all goes wrong, you completely forget it ever happened | 18:31 |
| ganso_ | so only the physical share moved | 18:31 |
| bswartz | well not anything at all | 18:31 |
| ganso_ | in fact, it updates the export location and the host columns | 18:31 |
| bswartz | but if the c-vol instance doing the migration dies before the model update is returned then we forget about the migration attempt | 18:32 |
| ganso_ | yes, this is something VERY problematic that happens on the Cinder migration as well | 18:32 |
| ganso_ | every time an error occurs, we never know if migration in fact succeeded | 18:32 |
| ganso_ | because the error state is cleaned, and the original ID remains, with status available | 18:33 |
| bswartz | that the main reason I'm in favor of creating a new row immediately and putting the original share into some kind of migration state | 18:33 |
| bswartz | that way if anything happens after that, we can pick up where we left off, or go back and clean up the error | 18:33 |
| ganso_ | yes, it has been discussed in the Cinder migration design session | 18:33 |
| ganso_ | we have a field for that | 18:33 |
| ganso_ | for cleaning up | 18:34 |
| ganso_ | but at the design summit we discussed having a "last migration" field | 18:34 |
| ganso_ | something like that | 18:34 |
| bswartz | okay so let's back up for a minute | 18:34 |
| bswartz | forget about the optimized case and go to the non-optimized case | 18:35 |
| ganso_ | but thinking more about it, I think the host field is enough to say where the share really is | 18:35 |
| ganso_ | ok | 18:35 |
| bswartz | I think if we can solve that one, then how we handle optimized migrations will be just a small detail | 18:35 |
| bswartz | so what happens in the A->C case (netapp to hds) | 18:35 |
| ganso_ | original idea: create a totally new share in C (physical + DB), copy data over, delete physical share in A, copy DB entries, and delete the temporary DB entry. End result is original ID pointing to physical share at C | 18:37 |
| bswartz | right.. | 18:37 |
| ganso_ | that is the one that is prototyped | 18:38 |
| bswartz | I was comfortable with that approach | 18:38 |
| ganso_ | me too | 18:38 |
| bswartz | although we would want to decide on using 2 ID fields or allowing re-IDing of the share | 18:38 |
| ganso_ | everything that is being discussed, about private driver storage, are possible improvements | 18:39 |
| bswartz | that's a minor detail compared to not creating a new row at all though | 18:39 |
| bswartz | so what is the new idea that doesn't involve creating a new row? | 18:39 |
| *** xyang1 has quit IRC | 18:40 | |
| ganso_ | the idea was to create a new share in destination backend, either by a separate method or providing the original ID, the driver would store the physical share ID in the private driver storage, and then we would delete the source physical share, along with its private driver storage | 18:41 |
| ganso_ | in that new idea, it is certain that at some point, both backends will have a share with the same ID, like you said | 18:42 |
| bswartz | which driver would store in the private data storage? | 18:42 |
| ganso_ | both, the private driver storage is stored per backend | 18:43 |
| ganso_ | so, if backend A has the private storage entry "volume_id":"X" and backend B adds the private storage entry "volume_id":"Y", it does not overwrite, backend A will never find the value backend B added | 18:44 |
| ganso_ | they can only read their own | 18:44 |
| ganso_ | the host name is used as filter | 18:44 |
| ganso_ | when retrieving the private driver storage | 18:44 |
| bswartz | is that how it's implemented now? | 18:45 |
| ganso_ | if you think about it, it is quite a powerful thing, we can store any values we want that may assist in tracking the migration status in that private storage | 18:45 |
| bswartz | with a host column in that table? | 18:45 |
| ganso_ | as far as I understood, yes, unless I got it wrong | 18:45 |
| bswartz | yeah but the whole point of driver-private storage was that it's *for the driver only* | 18:45 |
| ganso_ | yes | 18:46 |
| ganso_ | I discussed that with vponomaryov | 18:46 |
| bswartz | now we're immediately overloading the feature so that 2 drivers can share it | 18:46 |
| bswartz | I don't like that | 18:46 |
| ganso_ | I think it is quite wrong that the manager touches that | 18:46 |
| ganso_ | not really sharing | 18:46 |
| ganso_ | the manager would be handling all that stuff | 18:46 |
| bswartz | well the manager shouldn't touch those fields | 18:46 |
| bswartz | if the manager needs more fields we can add more fields to the shares table or another table | 18:46 |
| ganso_ | and I quite don't like the manager touching that as well... but he said it is okay... we may open it for discussion | 18:46 |
| bswartz | I don't like overloading that table with another purpose before any driver has even started to use it | 18:47 |
| ganso_ | /s/may/can | 18:47 |
| bswartz | that's also an easy problem to solve though | 18:47 |
| bswartz | we can add more columns to the share table or create a migrations table to work around those if needed | 18:48 |
| ganso_ | I think this decision is essential for this approach | 18:48 |
| bswartz | I'm just trying to imagine what this would looks like | 18:48 |
| ganso_ | if we are adding more columns I may even prefer to stick with 2 IDs | 18:48 |
| *** fthiagogv has quit IRC | 18:54 | |
| *** zhonghua-lee has joined #openstack-manila | 19:00 | |
| *** zhonghua-lee has quit IRC | 19:16 | |
| *** MIDENN_ has quit IRC | 20:01 | |
| *** esker has quit IRC | 20:30 | |
| *** timcl has quit IRC | 20:33 | |
| *** akerr has quit IRC | 20:54 | |
| *** cknight has quit IRC | 20:57 | |
| *** mdenny has joined #openstack-manila | 21:17 | |
| *** lpetrut has quit IRC | 21:18 | |
| *** mtanino_ has quit IRC | 21:31 | |
| *** openstackgerrit has quit IRC | 21:36 | |
| *** openstackgerrit has joined #openstack-manila | 21:36 | |
| *** rcallawa has quit IRC | 21:46 | |
| *** rushil has quit IRC | 22:19 | |
| *** marcusvrn1 has quit IRC | 22:21 | |
| *** rcallawa has joined #openstack-manila | 22:34 | |
| *** rcallawa_ has joined #openstack-manila | 22:35 | |
| *** absubram has quit IRC | 22:37 | |
| *** rcallawa has quit IRC | 22:39 | |
| *** rcallawa__ has joined #openstack-manila | 22:39 | |
| *** rcallawa_ has quit IRC | 22:39 | |
| *** rcallawa__ is now known as rcallawa | 22:40 | |
| *** rushil has joined #openstack-manila | 22:41 | |
| *** akshai has quit IRC | 22:47 | |
| *** chlong has quit IRC | 22:52 | |
| *** ganso_ has quit IRC | 23:14 | |
| *** rushil has quit IRC | 23:20 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!