| openstackgerrit | zhongshengping proposed openstack/puppet-manila master: Prepare Stein M2 https://review.openstack.org/629722 | 01:25 |
|---|---|---|
| openstackgerrit | jacky06 proposed openstack/manila-ui master: Update hacking version to latest https://review.openstack.org/628471 | 02:50 |
| openstackgerrit | jacky06 proposed openstack/manila-ui master: Update hacking version to latest https://review.openstack.org/628471 | 02:51 |
| openstackgerrit | jacky06 proposed openstack/manila-ui master: Update hacking version https://review.openstack.org/628471 | 02:51 |
| *** pcaruana has joined #openstack-manila | 07:51 | |
| *** logan- has quit IRC | 09:21 | |
| *** erlon has joined #openstack-manila | 09:24 | |
| *** logan- has joined #openstack-manila | 09:28 | |
| *** logan- has quit IRC | 09:28 | |
| *** e0ne has joined #openstack-manila | 09:33 | |
| *** ganso has joined #openstack-manila | 09:50 | |
| *** mmethot has quit IRC | 09:55 | |
| *** mmethot has joined #openstack-manila | 09:56 | |
| openstackgerrit | Merged openstack/manila-ui master: migrate legacy job to bionic https://review.openstack.org/629545 | 10:07 |
| *** luizbag has joined #openstack-manila | 10:40 | |
| openstackgerrit | Merged openstack/python-manilaclient master: Run manilaclient-dsvm-neutron-functional on bionic https://review.openstack.org/629550 | 10:44 |
| *** e0ne has quit IRC | 10:47 | |
| *** e0ne has joined #openstack-manila | 10:50 | |
| *** openstackgerrit has quit IRC | 11:05 | |
| *** openstackgerrit has joined #openstack-manila | 11:47 | |
| openstackgerrit | Tom Barron proposed openstack/manila master: DNM - debug intermittent migration test failures https://review.openstack.org/629444 | 11:47 |
| openstackgerrit | Tom Barron proposed openstack/manila master: DNM - test using oslo walk in db migrations https://review.openstack.org/629837 | 11:47 |
| openstackgerrit | Tom Barron proposed openstack/manila-ui master: DNM - test manila-ui gate with new dummy job and py3 https://review.openstack.org/629538 | 12:24 |
| *** vollman has joined #openstack-manila | 12:34 | |
| *** e0ne has quit IRC | 13:30 | |
| openstackgerrit | Tom Barron proposed openstack/python-manilaclient master: DNM - run functional tests with py3 https://review.openstack.org/629536 | 13:31 |
| openstackgerrit | Tom Barron proposed openstack/manila-ui master: Run dsvm job uner python3 https://review.openstack.org/629538 | 13:44 |
| *** e0ne has joined #openstack-manila | 14:10 | |
| *** jmlowe has quit IRC | 14:16 | |
| *** jmlowe has joined #openstack-manila | 14:33 | |
| *** jgrosso has joined #openstack-manila | 14:53 | |
| *** jmlowe has quit IRC | 14:58 | |
| *** jmlowe has joined #openstack-manila | 14:59 | |
| *** carlos_silva has joined #openstack-manila | 15:02 | |
| *** tobias-urdin has joined #openstack-manila | 15:08 | |
| tobias-urdin | we have some interest in deploying manila, just to be certain after reading docs and going through the drivers | 15:09 |
| tobias-urdin | if we use ceph (can deploy cephfs) and need to support network multi tenancy and nfs, is the cephfs native driver what we need? | 15:09 |
| gouthamr | tobias-urdin: the manila team's in a weekly meeting on #openstack-meeting-alt | 15:11 |
| gouthamr | however, short answer to your question -> network multi-tenancy, i.e, exporting shares on tenant share networks is not supported with the CEPHFS driver for either protocol (cephfs, nfs) yet | 15:12 |
| tobias-urdin | is there any driver matrix or similar that could tell me which do support our requirements? | 15:13 |
| gouthamr | yes | 15:15 |
| * gouthamr looks up link | 15:15 | |
| gouthamr | tobias-urdin: for rocky, switch to the release appropriate: https://docs.openstack.org/manila/rocky/admin/share_back_ends_feature_support_mapping.html | 15:16 |
| gouthamr | the feature you're looking for is called "DHSS=True" | 15:16 |
| tobias-urdin | gouthamr: thanks! | 15:16 |
| openstackgerrit | kay proposed openstack/python-manilaclient master: Add missing organizational unit (--ou) parameter in manila cli https://review.openstack.org/613298 | 15:51 |
| * tbarron upgrades bswartz to handing out salmon | 16:01 | |
| gouthamr | oooh | 16:01 |
| xyang | tbarron: do you have a minute? I meant to bring it up during the meeting but we are running out of time | 16:01 |
| bswartz | Large trout are the best fish for IRC | 16:02 |
| tbarron | bswartz: agree, but in seattle coffee and salmon seem appropriate | 16:02 |
| tbarron | xyang: s'up? | 16:02 |
| tbarron | xyang: i'll be back in a couple minutes but go ahead and talk | 16:03 |
| xyang | gouthamr and I talked about making "create volume from snapshot" an optional capability in CSI at KubeCon. I want to see if there are other filesystems that have the same requirements? | 16:03 |
| xyang | gouthamr said CephFS has this requirement | 16:03 |
| gouthamr | xyang: looks like its only CEPHFS so far: https://docs.openstack.org/manila/rocky/admin/share_back_ends_feature_support_mapping.html#mapping-of-share-drivers-and-share-features-support | 16:04 |
| xyang | gouthamr: oh, okay. got it | 16:04 |
| gouthamr | although we separated concerns assuming there are other drivers that can support snapshots but not efficient cloning from them | 16:04 |
| xyang | looks like there are a couple more that didn't implement create share from snapshot | 16:05 |
| xyang | Hitachi HSP and Quotabyte | 16:06 |
| xyang | Quobyte | 16:06 |
| gouthamr | ah, those don't support creating snapshots too | 16:06 |
| xyang | oh, that's true:) | 16:07 |
| tbarron | xyang: the manila experience says we should separate the various snap capabilties | 16:08 |
| tbarron | xyang: plain snap, create from snap, mount snap | 16:08 |
| tbarron | xyang: for block devices plain snap has no value but for filesystems they allow | 16:09 |
| tbarron | file and subtree retrieval even when there is no efficient way to retrieve the whole filesystem at a point in time | 16:09 |
| tbarron | xyang: does that make sense? | 16:10 |
| xyang | Initially I did propose "create volume from snapshot" as a separate capability but it was removed to address a review comments. I couldn't think of anyone who can support create snapshot but not create volume from it. | 16:10 |
| xyang | at that time | 16:10 |
| tbarron | xyang: I suspect the same for EFS etc. | 16:10 |
| xyang | so now we have a use case for it. I can bring this back | 16:10 |
| tbarron | xyang: the alternative is to say that if you can make snaps then there is a fallback slow create from snap available | 16:11 |
| tbarron | that performs very poorly | 16:11 |
| tbarron | gouthamr has suggested to me that in CSI context that may be what is wanted | 16:12 |
| tbarron | for application portability across clouds | 16:12 |
| xyang | what is a "slow create from snap"? Do you still want to implement "create volume from snapshot" though? | 16:13 |
| tbarron | I'd like to understand that argument more, but iiuc the idea is that cross-cloud app portability requires | 16:13 |
| tbarron | xyang: well that's what I'm trying to understand. I guess the argument | 16:13 |
| xyang | gouthamr said user can choose individual file to restore, but not the whole filesystem | 16:13 |
| tbarron | xyang: that's true for the filesystems I'm talking about, yes. | 16:14 |
| xyang | so my understanding is that it will be a manual process. not through "create vol from snap" CSI function | 16:14 |
| tbarron | xyang: but in theory one could tar and untar the whole snapshot, it's just not an efficient operation. | 16:14 |
| tbarron | xyang: and in traditional context not worth saying you can "create from snap" if that's all you support | 16:15 |
| tbarron | xyang: but if I understood gouthamr correctly he was suggesting that CSI may not be a traditional context in this sense | 16:15 |
| tbarron | xyang: that the goal is application portability, including the volumes requiired, across clouds | 16:16 |
| tbarron | xyang: if that's true, then it's hard to see show that could ever be efficient in the sense of traditional arrays or snapshotting filesystems | 16:17 |
| tbarron | xyang: so I need to learn more about the goals of snapshotting for CSI | 16:17 |
| xyang | the goal of CSI snapshot is that you can eventually restore data from it if needed | 16:18 |
| xyang | that's the basic goal | 16:18 |
| tbarron | xyang: how long is "eventually"? | 16:25 |
| *** jmlowe has quit IRC | 16:25 | |
| tbarron | xyang: that seems a different goal than we had in OpenStack, where creating from snap was supposed to be an efficient operation | 16:26 |
| xyang | tbarron: we don't really have a hard time requirement:). I'm just saying the purpose of a snapshot is that you can use it to create a volume when needed | 16:26 |
| tbarron | xyang: fixed time, not proportional to the data amount in the volume | 16:26 |
| xyang | it is different actually. while cutting snapshot should be very fast. uploading snapshot can be very consuming. for cloud providers like AWS and GCE, upload is part of the create snapshot process | 16:27 |
| tbarron | xyang: I guess I'd like to understand the use cases better, how long does upload for AWS, GCE volumes take? | 16:27 |
| tbarron | xyang: it may be that the file systems that wouldn't say they support create from snap in OpenStack context can do the same as AWS and GCE ... | 16:28 |
| xyang | tbarron: but we can't freeze the application for hours if it takes that long to create snapshot | 16:29 |
| tbarron | xyang: ack, let me double check but I don't think that snap creation time is an issue | 16:30 |
| xyang | upload could take hours, depending on the size. but we separate cut snapshot and upload. so when cut is complete CSI driver needs to return and then we know we can unfreeze | 16:30 |
| tbarron | xyang: does the spec actually say "freeze" or leave how the snap is done safely up to the back end? | 16:31 |
| *** jmlowe has joined #openstack-manila | 16:32 | |
| xyang | the spec talks about "freeze", but we have not implemented that part yet. That is something we are working on now | 16:36 |
| *** e0ne has quit IRC | 16:38 | |
| openstackgerrit | Tom Barron proposed openstack/manila-ui master: Run dsvm job under python3 https://review.openstack.org/629538 | 16:44 |
| tbarron | xyang: I guess you are aiming for application consistency (and portability), not just crash consistency of the volume. | 17:34 |
| xyang | yes | 17:37 |
| tbarron | xyang: that makes sense then, thanks | 17:51 |
| xyang | tbarron: you are welcome | 18:14 |
| openstackgerrit | Tom Barron proposed openstack/python-manilaclient master: DNM - run functional tests with py3 https://review.openstack.org/629536 | 18:23 |
| openstackgerrit | Tom Barron proposed openstack/python-manilaclient master: Eliminate str() in python-manilaclient https://review.openstack.org/629913 | 18:23 |
| openstackgerrit | Merged openstack/manila stable/queens: Improve service instance module debug logging https://review.openstack.org/629669 | 18:25 |
| openstackgerrit | Tom Barron proposed openstack/manila stable/pike: Improve service instance module debug logging https://review.openstack.org/629915 | 18:26 |
| *** carlos_silva has quit IRC | 18:31 | |
| openstackgerrit | Merged openstack/manila-ui master: Run dsvm job under python3 https://review.openstack.org/629538 | 18:36 |
| openstackgerrit | Merged openstack/manila-ui master: Update hacking version https://review.openstack.org/628471 | 18:36 |
| *** e0ne has joined #openstack-manila | 19:00 | |
| openstackgerrit | Tom Barron proposed openstack/python-manilaclient master: Eliminate str() in python-manilaclient https://review.openstack.org/629913 | 19:09 |
| *** luizbag has quit IRC | 19:12 | |
| openstackgerrit | Tom Barron proposed openstack/python-manilaclient master: Python3 compatability changes https://review.openstack.org/629913 | 19:49 |
| *** erlon has quit IRC | 20:32 | |
| *** zul has quit IRC | 20:35 | |
| *** jmlowe has quit IRC | 20:44 | |
| *** openstackgerrit has quit IRC | 20:50 | |
| *** openstackgerrit has joined #openstack-manila | 20:52 | |
| openstackgerrit | Goutham Pacha Ravi proposed openstack/python-manilaclient stable/rocky: Return is_default as a value instead of a function object https://review.openstack.org/629932 | 20:52 |
| openstackgerrit | Merged openstack/manila stable/rocky: Set paramiko logging to DEBUG level https://review.openstack.org/629671 | 21:00 |
| openstackgerrit | Tom Barron proposed openstack/manila stable/queens: Set paramiko logging to DEBUG level https://review.openstack.org/629933 | 21:01 |
| *** jmlowe has joined #openstack-manila | 21:07 | |
| *** e0ne has quit IRC | 21:13 | |
| *** ganso has quit IRC | 21:25 | |
| *** e0ne has joined #openstack-manila | 21:30 | |
| *** e0ne has quit IRC | 21:33 | |
| *** jgrosso has quit IRC | 21:39 | |
| openstackgerrit | Merged openstack/manila stable/pike: Adjust ssh timeouts https://review.openstack.org/629555 | 21:42 |
| *** pcaruana has quit IRC | 21:46 | |
| openstackgerrit | Merged openstack/manila stable/rocky: Change ssh_utils parameter to correctly send keepalive packets https://review.openstack.org/629670 | 22:34 |
| openstackgerrit | Tom Barron proposed openstack/python-manilaclient master: Python3 compatability changes https://review.openstack.org/629913 | 22:35 |
| openstackgerrit | Tom Barron proposed openstack/manila stable/queens: Change ssh_utils parameter to correctly send keepalive packets https://review.openstack.org/629941 | 22:37 |
| *** e0ne has joined #openstack-manila | 22:55 | |
| *** e0ne has quit IRC | 22:58 | |
| *** erlon has joined #openstack-manila | 23:33 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!