| *** BitSmith has joined #openstack-manila | 01:17 | |
| *** vbellur has joined #openstack-manila | 01:43 | |
| *** vbellur has quit IRC | 01:48 | |
| *** BitSmith has quit IRC | 01:51 | |
| *** zhidong has joined #openstack-manila | 04:09 | |
| *** rraja has joined #openstack-manila | 04:13 | |
| *** sks has joined #openstack-manila | 04:29 | |
| *** Triveni has joined #openstack-manila | 04:55 | |
| *** zhidong has quit IRC | 05:00 | |
| *** Triveni_ has joined #openstack-manila | 05:40 | |
| *** Triveni has quit IRC | 05:43 | |
| *** nkrinner has joined #openstack-manila | 05:44 | |
| *** Maike has joined #openstack-manila | 06:10 | |
| *** sks has quit IRC | 06:33 | |
| *** lpetrut has joined #openstack-manila | 06:38 | |
| *** kaisers1 has joined #openstack-manila | 06:39 | |
| *** sks has joined #openstack-manila | 06:48 | |
| *** Maike_ has joined #openstack-manila | 06:57 | |
| *** Maike_ has quit IRC | 06:59 | |
| *** Maike_ has joined #openstack-manila | 06:59 | |
| *** Maike has quit IRC | 07:00 | |
| *** kaisers2 has joined #openstack-manila | 07:03 | |
| *** kaisers2 has quit IRC | 07:06 | |
| *** Maike_ has quit IRC | 07:52 | |
| *** Maike has joined #openstack-manila | 08:02 | |
| *** Maike_ has joined #openstack-manila | 08:10 | |
| *** Maike has quit IRC | 08:14 | |
| *** Maike has joined #openstack-manila | 08:14 | |
| *** kaisers1 has quit IRC | 08:15 | |
| *** Maike_ has quit IRC | 08:15 | |
| *** lpetrut has quit IRC | 08:47 | |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: Transform share and share servers statuses to lowercase https://review.openstack.org/186520 | 08:58 |
|---|---|---|
| openstackgerrit | Valeriy Ponomaryov proposed openstack/python-manilaclient: Add rw functional tests for shares https://review.openstack.org/180219 | 09:07 |
| *** Maike has quit IRC | 09:19 | |
| *** lpetrut has joined #openstack-manila | 09:36 | |
| *** lpetrut1 has joined #openstack-manila | 09:39 | |
| *** lpetrut has quit IRC | 09:41 | |
| openstackgerrit | sac proposed stackforge/puppet-manila: Add share driver options. https://review.openstack.org/186699 | 09:46 |
| *** Maike has joined #openstack-manila | 10:14 | |
| *** vbellur has joined #openstack-manila | 11:08 | |
| *** lpetrut1 has quit IRC | 11:12 | |
| *** sgotliv has quit IRC | 11:53 | |
| *** ganso_ has joined #openstack-manila | 11:53 | |
| *** rraja has quit IRC | 11:54 | |
| *** nkrinner has quit IRC | 12:02 | |
| *** rcallawa_ has joined #openstack-manila | 12:02 | |
| *** rcallawa_ has quit IRC | 12:05 | |
| *** nkrinner has joined #openstack-manila | 12:05 | |
| *** marcusvrn has joined #openstack-manila | 12:14 | |
| *** lpetrut has joined #openstack-manila | 12:38 | |
| *** bswartz has quit IRC | 12:39 | |
| *** marcusvrn1 has joined #openstack-manila | 12:40 | |
| *** fthiagogv has joined #openstack-manila | 12:41 | |
| *** marcusvrn has quit IRC | 12:44 | |
| *** lpabon has joined #openstack-manila | 12:44 | |
| *** marcusvrn1 has quit IRC | 12:48 | |
| *** marcusvrn has joined #openstack-manila | 12:48 | |
| *** sks has quit IRC | 12:51 | |
| *** marcusvrn has quit IRC | 12:55 | |
| *** marcusvrn has joined #openstack-manila | 13:08 | |
| *** nkrinner has quit IRC | 13:10 | |
| *** xyang1 has joined #openstack-manila | 13:11 | |
| *** lpabon has quit IRC | 13:12 | |
| *** akshai has joined #openstack-manila | 13:15 | |
| openstackgerrit | sac proposed stackforge/puppet-manila: Add share driver options. https://review.openstack.org/186699 | 13:24 |
| *** mtanino has joined #openstack-manila | 13:26 | |
| *** cknight has joined #openstack-manila | 13:29 | |
| *** sgotliv has joined #openstack-manila | 13:30 | |
| *** vbellur has quit IRC | 13:36 | |
| *** bswartz has joined #openstack-manila | 13:44 | |
| bswartz | vponomaryov u_glide ganso_: ping | 13:46 |
| vponomaryov | bswartz: pong | 13:46 |
| bswartz | I had a conversation with ganso_ yesterday about share migration and the Manila DB | 13:46 |
| bswartz | we both agreed that 2 database records during the migration makes more sense than trying to use a single DB record | 13:47 |
| bswartz | there is too much state that we would need to store while the migration was in progress, without forcing every driver to change and have a special create_migration_destination_share() method | 13:48 |
| bswartz | and because we want the fallback migration method to work with all drivers, it's cleaner to just create a second share temporarily | 13:48 |
| bswartz | we will have the same issue that cinder does regarding ownership of the temporary share | 13:49 |
| bswartz | and the same issues regarding the IDs of the two shares | 13:49 |
| bswartz | there are 2 proposals to address the ID problem: | 13:49 |
| bswartz | 1) require all drivers to support a change-ID operation for shares, which will be much easier than in the past due to private driver share data | 13:50 |
| bswartz | 2) implement a second ID column in the database so every share has an "API ID" and a "Driver ID" which are different and the manager deals with mapping between the two | 13:50 |
| ganso_ | bswartz: pong | 13:51 |
| bswartz | Option 2 is the least disruptive for drivers, but could require a lot of change in manila core -- also cknight pointed out that 2 IDs would make manual debugging a lot more confusing | 13:51 |
| bswartz | Option 1 seems like it could work, and driver could use the generic driver as a model for how to handle mapping of IDs to the object on the backend | 13:52 |
| vponomaryov | 2) is redundant, you already can store such values in private driver storage | 13:52 |
| vponomaryov | for any amount of drivers | 13:53 |
| bswartz | vponomaryov: the idea behind option 2 would be that drivers would NEVER see the API ID, and users would NEVER see the driver ID | 13:53 |
| bswartz | we would have to implement some magic to ensure that | 13:53 |
| vponomaryov | API ID is current uuid of a share | 13:53 |
| vponomaryov | ? | 13:53 |
| ganso_ | options 2 would be enforcing the separate IDs | 13:53 |
| bswartz | API ID is what the user sees through the REST API | 13:53 |
| vponomaryov | ok, but not as new DB columns | 13:54 |
| ganso_ | option 1 we would be providing the means and guidelines for drivers, but we would not be enforcing them to correctly use it | 13:54 |
| bswartz | well we would need to store both | 13:54 |
| bswartz | in a migration this is what would happen | 13:54 |
| bswartz | User creates a a new share, it gets API ID 1 and Driver ID 2 | 13:54 |
| bswartz | User does an action which causes the share to migrate | 13:54 |
| *** lpabon has joined #openstack-manila | 13:54 | |
| bswartz | Manager creates a new share with API ID 1 and Driver ID 3 | 13:55 |
| bswartz | manager copies the data | 13:55 |
| bswartz | manager deletes the first share | 13:55 |
| bswartz | the second share becomes visible | 13:55 |
| bswartz | in this model, the driver never realizes that share 2 and share 3 are considered the same by the user | 13:56 |
| *** timcl has joined #openstack-manila | 13:56 | |
| bswartz | and the user never realizes that there were temporarily 2 shares with ID 1 | 13:56 |
| bswartz | all of the complexity is hidden inside the manager | 13:56 |
| u_glide | option 2 looks destructive for manila | 13:57 |
| ganso_ | ^ in fact there was never 2 shares with the same API ID... | 13:57 |
| bswartz | Option 2 is what the cinder team has done without realizing it | 13:58 |
| bswartz | they had some bugs, but they were able to fix them | 13:58 |
| vponomaryov | bswartz: looks like we came to situation when we need to rework DB schema - separate "data" part of a share and "identification". It will be useful for migration and future replication | 13:58 |
| ganso_ | vponomaryov: +1 | 13:59 |
| u_glide | it's better to move ownership of private driver data for particular share from one driver to another | 13:59 |
| bswartz | I can see benefits of having 2 IDs per share | 13:59 |
| ganso_ | we also cannot bet everything on private driver storage | 13:59 |
| bswartz | but the downside is complexity and confusion for developers | 13:59 |
| bswartz | u_glide: private driver storage is intended to be for a single driver only | 13:59 |
| bswartz | netapp's private data won't make any sense to HDS, and vice versa | 14:00 |
| bswartz | during a share migration, we would need to wipe the private data to avoid confusion in the driver code | 14:00 |
| u_glide | vponomaryov:+1 good idea | 14:01 |
| vponomaryov | bswartz: I guess if we do solution for future "replication", then migration will be case of it | 14:01 |
| ganso_ | bswartz: as we discussed yesterday, as far as I know, HDS backend would never be able to read netapp's private driver storage | 14:01 |
| ganso_ | bswartz: u_glide can confirm this | 14:02 |
| vponomaryov | ganso_: false | 14:02 |
| vponomaryov | ganso_: driver takes ID and requests data by IT | 14:02 |
| vponomaryov | ganso_: so, if you provided share ID, driver can read/write data | 14:02 |
| u_glide | bswartz: sometimes it could, for example when migrate share from "old" company solution to "new" | 14:03 |
| u_glide | vponomaryov is wrong, private driver data isolated on host level | 14:03 |
| *** Maike_ has joined #openstack-manila | 14:03 | |
| bswartz | u_glide: I'm not aware any drivers that need to do that today though | 14:04 |
| *** Maike_ has quit IRC | 14:04 | |
| bswartz | I think it's best to start from the assumption that nothing outside the driver that created the private share data will ever read it | 14:04 |
| u_glide | bswartz: agree | 14:04 |
| *** Maike_ has joined #openstack-manila | 14:04 | |
| *** mtanino has quit IRC | 14:05 | |
| u_glide | I think we should take approach proposed by vponomaryov and carefully design new changes | 14:05 |
| *** rushil has joined #openstack-manila | 14:05 | |
| ganso_ | vponomaryov: https://review.openstack.org/#/c/176877/14/manila/share/drivers_private_data.py LN 92 | 14:06 |
| bswartz | I'm not clear on how vponomaryov's proposal differs from mine | 14:06 |
| vponomaryov | bswartz, u_glide, ganso_: approach is following: create new DB table for "instances" of a share taht will be related to "identity" share table (existing) | 14:06 |
| bswartz | oh you're proposing new table too | 14:06 |
| bswartz | cknight: ping | 14:06 |
| vponomaryov | bswartz, u_glide, ganso_: in that case we will be able to migration as subcase of replication | 14:06 |
| cknight | bswartz: pong | 14:07 |
| vponomaryov | *to do | 14:07 |
| bswartz | cknight read history | 14:07 |
| *** Maike has quit IRC | 14:07 | |
| vponomaryov | ganso_: yes, I forget for that time about filter by host, sorry | 14:07 |
| bswartz | cknight: vponomaryov is proposing the 2 UUID option on steroids | 14:07 |
| u_glide | vponomaryov idea about new "share_instance" DB table sounds | 14:07 |
| u_glide | good | 14:08 |
| bswartz | I think it's worth considering | 14:08 |
| bswartz | it's not conceptually different from my 2 UUID proposal, but it's cleaner in terms of implementation | 14:09 |
| bswartz | and given that cinder has proven that the 2 UUID option can work, I'm not very nervous about it if we implement it early in liberty and test the hell out of it | 14:09 |
| bswartz | I'll have to give some thought to how this might work with replication | 14:10 |
| u_glide | but this new table will introduce new concept in manila - "instance of share", so proposal are different | 14:10 |
| bswartz | yes but we would never expose it directly to the user, right? | 14:10 |
| vponomaryov | exactly possibility to have more than one instance of a share is an issue for migration case | 14:11 |
| vponomaryov | bswartz; only by multiple export locations | 14:11 |
| u_glide | bswartz: right | 14:11 |
| *** sgotliv has quit IRC | 14:11 | |
| u_glide | vponomaryov: +1 | 14:11 |
| bswartz | well hold on | 14:11 |
| bswartz | the export locations would be tied to the instances, not the user visible share | 14:11 |
| bswartz | in the migration case, you would need to actually mount the 2 instances and copy data from one to the other | 14:12 |
| bswartz | the user would only ever see the export locations for the "active" instance of a share | 14:12 |
| vponomaryov | mount one export location to another | 14:12 |
| vponomaryov | /to/and/ | 14:12 |
| u_glide | bswartz: instance of share could be 'hidden' for user | 14:13 |
| ganso_ | we need to also consider what effort will be required from driver vendors, the best would be to minimize that | 14:13 |
| ganso_ | multiple export locations are going to be exposed to users, instances should not... instances need to be managed by core code for migration/replication purposes | 14:14 |
| *** lpetrut1 has joined #openstack-manila | 14:15 | |
| ganso_ | I think the instances table can be implemented a way that requires minimum, if any, effort from drivers | 14:15 |
| *** lpetrut has quit IRC | 14:16 | |
| ganso_ | there is still one small detail | 14:16 |
| bswartz | yes I think if we implemented share instances then drivers would just interact with those and they would look identical to existing shares from the driver's perspective | 14:17 |
| vponomaryov | share instances list should be possible to get by admin | 14:17 |
| vponomaryov | as he is resource maintainer | 14:17 |
| bswartz | yeah the admin should be able to see it all | 14:18 |
| ganso_ | currently, driver vendors use API ID for their physical shares, for instance: as soon as the request to create a share reaches the driver code, it needs to decide on an ID to store in its backend, so it uses the API ID. | 14:18 |
| ganso_ | how do we make they use the instance ID? | 14:19 |
| bswartz | ganso_: when it reached the driver the field would just be called "ID" | 14:20 |
| bswartz | the manager would hide everything that the driver didn't need to know | 14:20 |
| ganso_ | bswartz: but would it be in fact the instance ID? | 14:20 |
| bswartz | in this proposal, yes | 14:20 |
| vponomaryov | ganso_: oh, it is not a problem at all. Drivers still will get param "share", but it will have additional attributes | 14:20 |
| *** rushil has quit IRC | 14:21 | |
| vponomaryov | "identity" share will have subattrs for instances of shares | 14:21 |
| vponomaryov | so, driver interface should be the same | 14:21 |
| vponomaryov | drivers just can start consider new attrs | 14:21 |
| vponomaryov | at some moment | 14:21 |
| ganso_ | so we are not going to trick drivers by providing the instance ID instead of API ID? they are going to have to update the code | 14:22 |
| ganso_ | /s/the code/their code | 14:22 |
| cknight | ganso_: "trick drivers" == "make driver authors miserable" | 14:23 |
| *** rcallawa_ has joined #openstack-manila | 14:23 | |
| cknight | ganso_: If the UUID from 'manila list' doesn't match what I see on my backend storage, that's gonna be awful. | 14:23 |
| ganso_ | cknight: that is the problem | 14:24 |
| *** rcallawa_ has quit IRC | 14:24 | |
| ganso_ | in the migration demo I displayed at design summit, share X which previously had a export location of "/shares/X", after migration, it had "/shares/Y" | 14:25 |
| vponomaryov | wait, what tricks do you mean? With implementation of instances no tricks will be needed | 14:25 |
| ganso_ | Y would be other ID we are talking about | 14:25 |
| vponomaryov | ganso_: you provided export location it has nothing to ID | 14:26 |
| ganso_ | the generic driver back then used the API ID as export location name | 14:26 |
| vponomaryov | and? | 14:27 |
| u_glide | vponomaryov: +1 :) | 14:27 |
| vponomaryov | it does not make you use two different IDs | 14:27 |
| vponomaryov | for one share | 14:27 |
| vponomaryov | mount volume to old path and that all | 14:28 |
| vponomaryov | in migration logic | 14:28 |
| ganso_ | when we are going to create the new share on destination backend, unless we skip the API creating the new ID and use the same API ID, with a new instance ID, the driver will create a new share and post updates to the original API ID DB entry the source share is owner of | 14:28 |
| cknight | Unless there is a use case we haven't considered, having a separate shares instances table seems overcomplicated. I still prefer requiring drivers to be able to change the UUID of a share. It's not complicated, and they can either use the private storage mechanism or direct backend calls to achieve that. | 14:29 |
| *** rushil has joined #openstack-manila | 14:30 | |
| bswartz | cknight: vponomaryov suggested that it might benefit the replication case as well | 14:30 |
| u_glide | cknight: but we also need solution compatible with AZ and replication | 14:30 |
| bswartz | I haven't given that much thought yet | 14:30 |
| cknight | bswartz, u_glide: understood. Let's consider everything before deciding this one. | 14:31 |
| vponomaryov | bswartz: I bet you will agreee after giving it a thought | 14:31 |
| bswartz | yeah I need to give this a lot of thought | 14:31 |
| bswartz | vponomaryov: I have a separate question | 14:31 |
| bswartz | https://github.com/openstack/manila/blob/master/manila/db/sqlalchemy/models.py#L183 | 14:32 |
| bswartz | what is the purpose of the availability_zone column in the shares table? | 14:32 |
| vponomaryov | none | 14:32 |
| cknight | vponomaryov: Isn't that a Cinder holdover? | 14:32 |
| vponomaryov | left-over from cCinder | 14:32 |
| u_glide | cknight: +1 | 14:32 |
| bswartz | okay that's what I suspected | 14:32 |
| bswartz | just checking | 14:32 |
| cknight | bswartz: Might as well leave it there for now, since removing it is a breaking change, and it might be needed in the near term anyway. | 14:33 |
| vponomaryov | let it be, for future purpose | 14:33 |
| bswartz | I just wanted to make sure it wasn't used for anything -- we need a plan for how to handle AZs and it might involve simply reusing that column | 14:33 |
| cknight | If we do choose to remove it, we can do so safely after adopting microversions. | 14:34 |
| vponomaryov | bswartz: AZs are expected to be attr of "instance" table | 14:34 |
| bswartz | vponomaryov: we haven't agreed to that proposal yet ;-) | 14:35 |
| bswartz | it's an interesting idea with a lot of implications | 14:35 |
| vponomaryov | but it is obvious | 14:35 |
| u_glide | seems like we need detailed plan for feature sprints :) | 14:35 |
| *** esker has joined #openstack-manila | 14:35 | |
| ganso_ | yes, we need a proposal | 14:35 |
| bswartz | I'm sensitive to cknight's concern about developer confusion with additional IDs | 14:35 |
| u_glide | /s/feature/future | 14:36 |
| vponomaryov | bswartz: why additional? | 14:36 |
| u_glide | instance id's will be hidden for drivers | 14:36 |
| vponomaryov | bswartz: instance IDs will be used for export locations, and identity ID for user-facing get/delete , etc... | 14:36 |
| ganso_ | as far as I understood the instance table would be managed by core code only | 14:36 |
| bswartz | vponomaryov: today when we create a share using the netapp driver, you can run "manila list" and see the ID, and go to the backend and see a flexvol with a name matching that ID | 14:37 |
| bswartz | this is a convenience for developers | 14:37 |
| cknight | ganso_: If the instances table is used for replicated shares, the drivers would definitely need to see it. | 14:37 |
| bswartz | that would go away with the split ID scheme | 14:37 |
| ganso_ | API request ID X => core code gets instance ID A using API ID X => provide ID A to drivers, since it will be the driver's ID | 14:38 |
| bswartz | cknight: maybe or maybe not -- if we do things cleverly it might be avoidable | 14:38 |
| u_glide | bswartz: admin API manila share-instance-list will address this problem | 14:38 |
| vponomaryov | u_glide: +billion | 14:38 |
| ganso_ | bswartz: +1 I think that needs to go away | 14:39 |
| bswartz | that's an option | 14:39 |
| vponomaryov | cknight: don't forget about admin API with possibility to see instances | 14:39 |
| bswartz | ganso_: what needs to go away? | 14:39 |
| *** Maike_ has quit IRC | 14:39 | |
| vponomaryov | cknight: ops will use it too | 14:39 |
| ganso_ | u_glide: +1 +1 +1 lol | 14:39 |
| ganso_ | bswartz: the convenience | 14:42 |
| ganso_ | bswartz: sorry did not see your message | 14:42 |
| ganso_ | cknight: btw, my message above about providing ID A to drivers, so it can use as its ID, is what I called "tricking" drivers | 14:44 |
| ganso_ | cknight: I would prefer if drivers had a way of saying "for API ID X, I have the ID A which I store in my private driver storage, so I know all about it" | 14:45 |
| ganso_ | cknight: vponomaryov's idea of continue to provide the API ID X but with additional attributes that contains the active instance ID A would need a small update to driver code, same as private driver storage | 14:46 |
| ganso_ | (is everyone receiving my messages or has my IRC dropped and I have not yet realized?) | 14:47 |
| vponomaryov | its ok | 14:47 |
| ganso_ | vponomaryov: thanks | 14:47 |
| vponomaryov | s/its/it's/ =) | 14:48 |
| cknight | ganso_: thanks, I think I understand. I'm just hesitant to introduce a whole new table and extra set of IDs just to solve the migration problem. I'd like to see us consider additional use cases, such as replication, to see if there are other reasons to add the extra layer of complexity. | 14:54 |
| *** esker has quit IRC | 14:59 | |
| *** esker has joined #openstack-manila | 15:00 | |
| *** absubram has joined #openstack-manila | 15:02 | |
| *** absubram has quit IRC | 15:04 | |
| *** absubram has joined #openstack-manila | 15:04 | |
| *** mtanino has joined #openstack-manila | 15:12 | |
| openstackgerrit | sac proposed stackforge/puppet-manila: Add share driver options. https://review.openstack.org/186699 | 15:18 |
| *** lpetrut1 has quit IRC | 15:24 | |
| *** chen12 has quit IRC | 15:44 | |
| *** chen12 has joined #openstack-manila | 15:45 | |
| *** lpetrut has joined #openstack-manila | 15:51 | |
| *** absubram has quit IRC | 15:51 | |
| *** absubram has joined #openstack-manila | 15:56 | |
| *** timcl has quit IRC | 15:57 | |
| *** rushil has quit IRC | 15:58 | |
| *** dhellmann has joined #openstack-manila | 16:08 | |
| dhellmann | bswartz: I would like to cut a release of python-manilaclient on Monday to unblock the work on dropping the oslo namespace packages. The changes that will be released are listed in http://paste.openstack.org/show/245107/ -- Does that work for you? | 16:10 |
| bswartz | dhellmann: from what branch? | 16:10 |
| dhellmann | bswartz: master | 16:10 |
| dhellmann | as 1.2.0 | 16:10 |
| bswartz | 1.1.X is the liberty series | 16:11 |
| bswartz | why not call it 1.1.1? | 16:11 |
| dhellmann | semver | 16:11 |
| bswartz | semver? | 16:11 |
| dhellmann | you have feature additions and requirements changes so the minimum version needs to be bumped -- http://docs.openstack.org/developer/pbr/semver.html | 16:12 |
| bswartz | hmm | 16:12 |
| bswartz | okay that works for me | 16:12 |
| dhellmann | we're trying to get all of the libraries, including clients, to standardize on the way we convey info through the version numbers | 16:12 |
| bswartz | does anything need merging beforehand? | 16:12 |
| dhellmann | that's up to you, I'll cut from HEAD on Monday morning US Eastern | 16:13 |
| bswartz | okay | 16:13 |
| dhellmann | cool, thanks! | 16:13 |
| bswartz | I will be unreachable at that time but go ahead and push a tag | 16:14 |
| dhellmann | ok, I'll find some of the other cores if we run into issues | 16:14 |
| *** timcl has joined #openstack-manila | 16:28 | |
| *** esker has quit IRC | 16:38 | |
| *** lpetrut has quit IRC | 16:40 | |
| *** lpabon has quit IRC | 16:44 | |
| *** lpabon has joined #openstack-manila | 16:50 | |
| *** rushil has joined #openstack-manila | 16:52 | |
| *** lpabon has quit IRC | 16:54 | |
| *** xyang1 has quit IRC | 17:02 | |
| *** vbellur has joined #openstack-manila | 17:02 | |
| *** rushil has quit IRC | 17:13 | |
| *** rushil has joined #openstack-manila | 17:19 | |
| *** vponomaryov has quit IRC | 17:25 | |
| *** sgotliv has joined #openstack-manila | 17:42 | |
| *** sgotliv has quit IRC | 17:42 | |
| *** sgotliv has joined #openstack-manila | 17:42 | |
| ganso_ | bswartz: ping | 17:48 |
| bswartz | ganso_: pong | 17:49 |
| *** xyang1 has joined #openstack-manila | 17:50 | |
| ganso_ | bswartz: Do you know what is the liberty milestone deadlines for new drivers and new core features? | 17:50 |
| bswartz | https://wiki.openstack.org/wiki/Liberty_Release_Schedule | 17:50 |
| bswartz | L-3 (September 3) will be the feature freeze | 17:50 |
| ganso_ | yea but for Manila, I can assume that everything, drivers and features, will be accepted by L3? | 17:51 |
| bswartz | new features have to be submitted and mergeable 2 weeks before that to get review time | 17:51 |
| ganso_ | ok, so L-3 then | 17:51 |
| bswartz | you can never assume something will be accepted -- we'll only merge code that we're happy with | 17:51 |
| bswartz | but there are no special early deadlines | 17:51 |
| ganso_ | yes, sure | 17:51 |
| ganso_ | thanks! | 17:52 |
| bswartz | for a major new feature though, we would want to split it into pieces and merge them throughout the release | 17:52 |
| bswartz | a big giant feature at the last minute is going to make us too nervous | 17:52 |
| bswartz | I'm hoping to have something working for replication before august | 17:53 |
| bswartz | that means we have to sort out the AZ issues too before then | 17:53 |
| ganso_ | and migration even before that | 17:54 |
| bswartz | and we definitely need to reach a conclusion on single ID vs multiple ID and the concept of "share instances" in the next few weeks | 17:54 |
| ganso_ | yes | 17:54 |
| ganso_ | btw, data copy service... this is also going to be mandatory, right? | 17:54 |
| bswartz | so far I'm not convinced that share instances are any help for replicated shares | 17:54 |
| bswartz | ganso_: data copy service it nice to have, but something that should go in early if we're going to do it in this release | 17:55 |
| bswartz | it might be a good starting place because we can get it in mergeable shape with no dependencies | 17:55 |
| *** lpetrut has joined #openstack-manila | 18:12 | |
| *** lpabon has joined #openstack-manila | 18:16 | |
| *** sgotliv has quit IRC | 18:18 | |
| *** lpabon has quit IRC | 18:21 | |
| *** lpabon has joined #openstack-manila | 18:48 | |
| *** fthiagogv has quit IRC | 18:55 | |
| *** vbellur has quit IRC | 19:02 | |
| *** cknight has quit IRC | 19:15 | |
| *** cknight has joined #openstack-manila | 19:19 | |
| *** lpabon has quit IRC | 19:37 | |
| *** timcl has quit IRC | 20:02 | |
| *** openstack has joined #openstack-manila | 20:05 | |
| *** openstack has joined #openstack-manila | 20:30 | |
| *** rushil has quit IRC | 20:43 | |
| *** Triveni_ has quit IRC | 20:56 | |
| *** openstackgerrit has quit IRC | 20:59 | |
| *** openstackgerrit has joined #openstack-manila | 20:59 | |
| *** bswartz has quit IRC | 21:10 | |
| *** lpetrut has left #openstack-manila | 21:28 | |
| *** openstack has joined #openstack-manila | 21:31 | |
| *** marcusvrn has quit IRC | 21:53 | |
| *** akshai has quit IRC | 21:53 | |
| *** mdenny has quit IRC | 21:54 | |
| *** cknight has quit IRC | 22:17 | |
| *** lpabon has joined #openstack-manila | 22:28 | |
| *** lpabon has quit IRC | 22:42 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/manila: Updated from global requirements https://review.openstack.org/186945 | 22:45 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-manilaclient: Updated from global requirements https://review.openstack.org/186947 | 22:53 |
| *** sgotliv has joined #openstack-manila | 23:06 | |
| *** sgotliv has quit IRC | 23:07 | |
| *** ganso_ has quit IRC | 23:14 | |
| *** xyang1 has quit IRC | 23:52 | |
| *** bswartz has joined #openstack-manila | 23:53 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!