15:00:23 <bswartz> #startmeeting manila
15:00:24 <openstack> Meeting started Thu Jul  9 15:00:23 2015 UTC and is due to finish in 60 minutes.  The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:29 <openstack> The meeting name has been set to 'manila'
15:00:30 <bswartz> hello all
15:00:35 <cknight> Hi
15:00:36 <ganso_> hello
15:00:37 <markstur> hello
15:00:37 <vponomaryov> Hello
15:01:04 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting
15:01:50 <bswartz> only 2 topics today, so hopefully short meeting
15:02:02 <bswartz> #topic Midcycle Meetup
15:02:05 <toabctl> hi
15:02:08 <bswartz> #link https://etherpad.openstack.org/p/manila-liberty-midcycle-meetup
15:02:25 <bswartz> so the midcycle meetup is just 3 weeks away
15:03:04 <bswartz> a number of people have said they can't attend in person, and would like to attend remotely, so we will be doing video conference like last time
15:03:21 <lpabon> hi
15:03:24 <xyang1> Hi
15:03:33 <bswartz> anyone who can travel to join locally should contact me to find out about accomodations
15:04:09 * lpabon would really like to do remotely
15:04:23 <bswartz> I just created the etherpad to collect attendance information and to start collecting topic proposals
15:04:53 <bswartz> I'll be working to get a more formal agenda/schedule in the next 2 weeks
15:05:11 <bswartz> because there will be remote attendees, we will have timezone challenges like before
15:05:54 <bswartz> this time I will create timeslots for topics and we will try to stick with the schedule
15:06:33 <csaba> also if there will be a lot of remote joiners, we might have a severe race for hangout slots
15:07:14 <lpabon> csaba: what is the max on hangouts?
15:07:19 <bswartz> csaba: we will have audio conference as well as hangout
15:07:24 <vponomaryov> pabon: 15
15:07:29 <lpabon> if not I can do bluejeans
15:07:33 <lpabon> i think bluejeans is 99
15:07:39 <bswartz> so if the hangout fills up we can get additional people in audio-only
15:07:41 <lpabon> and we can record them
15:07:44 <ganso_> there should be a way to live stream the video so people on the audio bridge can get video feed
15:08:12 <bswartz> lpabon: my experience with bluejeans so far has not been great
15:08:17 <vponomaryov> what kind of video do you expect?
15:08:20 <bswartz> I'm not sure how well it will work for others
15:08:38 <lpabon> bswartz: well, I can do setup one if you need to. Let me know
15:08:39 <bswartz> google hangouts are tried and trusted, although the 15 person limit is a big problem
15:08:54 <ganso_> vponomaryov: slides, demos, code, etc
15:09:06 <csaba> vponomaryov: at least it's useful if the screen displays who's speaking as we can't expect all of us recongnize each other by voice
15:09:07 <lpabon> we can start with bluejeans and fallback to hangouts if you want
15:09:20 <bswartz> csaba: +1
15:09:24 <bswartz> I like that feature too
15:09:32 <bswartz> I don't know everyone's voice
15:09:46 <vponomaryov> csaba: not musician? =)
15:10:13 <bswartz> I'm open to other conference technologies but we should probably test it out if it's something we haven't used before
15:10:26 <csaba> vponomaryov: I'm almost deaf to one of my ears ;)
15:10:37 <bswartz> webex is another alternative to google hangouts but webex has it's own set of problems
15:10:41 <lpabon> bswartz: sure let me know.. i use bluejeans almost every day
15:10:50 <vponomaryov> bswartz: +1 for webex, why not?
15:11:04 <bswartz> vponomaryov: webex works poorly on Linux
15:11:18 <lpabon> webex doesn't love linux :(
15:11:27 <vponomaryov> bswartz: it allows to join using skype/phone
15:11:33 <vponomaryov> for audio
15:11:46 <lpabon> bluejeans allows audio phone dialin also
15:11:53 <bswartz> it works fine for audio and slide presentations
15:12:08 * lpabon has talked enough about bluejeans :)
15:12:33 <bswartz> but I'm not sure about video, and if anyone has never used webex before they might have fits trying to get it to work
15:13:17 * bswartz remembers doing some unholy things to install 32-bit JVM
15:13:38 <csaba> apage satanas!
15:14:14 <bswartz> anyways please add your name to the etherpad if you plan to join the meetup
15:14:19 <vponomaryov> bswartz : we are doing lots of unholy things just using openstack =)
15:14:30 <bswartz> and please propose some more topics so next week we can get a more formal agenda/schedule started
15:15:23 <bswartz> #topic share dismantling policies
15:15:31 <bswartz> #link http://thread.gmane.org/gmane.comp.cloud.openstack.devel/58419
15:15:43 <csaba> rraja: just in time, my topic is on ;)
15:15:48 <bswartz> csaba: you're up
15:16:28 <csaba> so there is that email that's linked, probably the question could be addressed on ml but as we don't have too much for today I thought we could talk it over here
15:16:32 * bswartz assumes everyone is reading the thread
15:17:03 <bswartz> csaba: are you familiar with what cinder does?
15:17:19 <csaba> bswartz: no, I'd be happy to hear that
15:17:45 <csaba> bswartz: I think you mean the first situation, when deleting shares
15:17:57 <csaba> s/think/assume/
15:17:59 <bswartz> the general contract of a delete is: when a user (tenant) deletes a share/volume, the data from that share/volume should never be accessible again to any other user/tenant
15:18:15 <bswartz> there's no guarantee that a administrator couldn't recover the data
15:18:29 <csaba> bswartz: OK, that's clear statement
15:18:59 <markstur> s/any other user/any user/
15:19:11 <csaba> and with unmanage the difference is that the data can come back?
15:19:18 <bswartz> markstur: yes
15:19:44 <bswartz> well unmanage is an admin-only operation
15:20:03 <vponomaryov> csaba, bswartz; unmanage just takes out share out of Manila control, data will still exist
15:20:26 <bswartz> yeah let's not bring unmanage into the discussion
15:20:35 <csaba> vponomaryov: but according to bswartz data can still exist with delete too ..
15:20:42 <csaba> bswartz: OK
15:21:15 <bswartz> in cinder there is a problem where delete user data can actually still be accessible to users (including OTHER users) if you don't set a specific option for the LVM driver
15:21:25 <bswartz> that's definitely NOT okay
15:21:43 <vponomaryov> bswartz: it takes lots of extra time
15:21:58 <vponomaryov> bswartz: and is disabled for testing
15:21:59 <bswartz> but we don't need to securely delete data so that nobody including the administrator can access it
15:22:09 <bswartz> vponomaryov: correct
15:22:32 <csaba> so then in cinder adheres the cited contract; implied generic driver adheres that contract in manila ... what's the situation with other drivers?
15:22:42 <bswartz> csaba: yes
15:23:11 <bswartz> csaba: I would expect that when you create a new share, it's always empty (no data in it)
15:23:16 <csaba> is this contract consensual enough in cloud computing to not have to make an explicit statement on it?
15:23:25 <bswartz> unless the share is created from a snapshot, of course
15:24:02 <bswartz> csaba: in a cloud context you have to trust the cloud admin with your data in any case, because the admin can ALWAYS read your data if he wants to
15:24:26 <bswartz> so there's little point is going to the extra effort of securely deleting data on the platters
15:24:36 <csaba> OK so I'm happy with these answers, we can get to the second part
15:25:22 <csaba> the disruptiveness of deny-access, whereby disruptiveness my home brewed terminology
15:25:36 <bswartz> I'm not sure how to understand the second question
15:25:43 <bswartz> is it about access-deny?
15:25:49 <csaba> to mean that on access revoking, all users who are not authorized are kicked out
15:26:01 <csaba> bswartz: indeed, only deny
15:26:18 <vponomaryov> csaba: just think how it is without Manila using vanilla NFS
15:26:35 <vponomaryov> access rights are verified on "mount" point
15:26:36 <bswartz> NFS and other protocols have defined semantics for when access is removed, I believe
15:26:57 <markstur> stale mount
15:27:03 <csaba> vponomaryov: according to my testing that is disruptive... after the export is removed, further syscalls fail with EACCES
15:27:12 <bswartz> if the admin tells the server to revoke access to an client, the server immediately starts denying requests from that client
15:27:24 <csaba> bswartz: yes, that's what I call disruptive
15:27:32 <bswartz> csaba: what error is returned would be up to the client though
15:27:52 <bswartz> clients cache data and could in theory continue operating from their cache for some time before they find out the server has cut them off
15:28:11 <bswartz> there's nothing we can do about that in any case -- that's NFS semantics
15:28:17 <csaba> yeah sure, it can all take effect only when data needs to go thru the wire
15:28:40 <csaba> so but other drivers might not drop the mount upon access being revoked
15:28:51 <bswartz> so I still don't understand what the alternative might be
15:28:57 <csaba> (which actually is the case with gluster_native
15:28:58 <csaba> )
15:29:04 <bswartz> deny-access means to deny access right now
15:29:13 <bswartz> how else could it be interpretted
15:29:22 <csaba> if the tenant has a mount of the share at the point of denial, the mount remains functional
15:29:27 <bswartz> oh
15:29:38 <csaba> however, new mounts cant be made
15:29:55 <csaba> that's what I call "non-distruptive denial"
15:29:56 <bswartz> so maybe deny access could be interpreted as no new mounts can be made, but existing mounts can continue?
15:30:00 <bswartz> okay
15:30:14 <bswartz> yeah I would say that's the wrong interpretation
15:30:18 <csaba> yeah, that's the semantical ambiguity I'm concerned about
15:30:42 <bswartz> I believe that deny should be disruptive, to use your term
15:30:54 <csaba> OK, clear point then...
15:30:58 <bswartz> does anyone disagree about that?
15:31:06 <cknight> csaba: Can you fix gluster_native to revoke access immediately upon access_deny?
15:31:07 <markstur> agree
15:31:10 <cknight> agree
15:31:14 <vponomaryov> should, but do we consider it as requirement for Manila?
15:31:33 <vponomaryov> are we ready to kick some backend support because of it?
15:31:41 <csaba> cknight: it will take some time, glusterfs changes will be needed
15:31:43 <bswartz> vponomaryov: yes, I think we should have a scenario test that verifies it
15:32:10 <cknight> bswartz: +1
15:32:29 <bswartz> scenario test:
15:32:29 <bswartz> 1) create share
15:32:29 <bswartz> 2) grant access
15:32:29 <bswartz> 3) mount share
15:32:29 <bswartz> 4) write some data
15:32:30 <bswartz> 5) deny access
15:32:30 <bswartz> 6) write more data
15:32:30 <bswartz> 7) validate the more data didn't get written
15:32:32 <vponomaryov> bswartz: scenario test is low-hanging-fruit, I am asking in general
15:32:58 <vponomaryov> bswartz: when some backend does not behave so and can not
15:33:17 <vponomaryov> ... and can not as expected
15:33:29 <bswartz> well I'm curious to know which backend could not implement those semantics
15:33:52 <vponomaryov> csaba: said that gluster_native does so
15:33:57 <csaba> so then as a reward for bringing this up may I ask for some grace time? :)
15:33:58 <bswartz> it seems like a severe limitation to not have a way to cut off user access on the server side
15:33:58 <vponomaryov> csaba: right?
15:34:10 <bswartz> csaba: just consider it a bug
15:34:11 <csaba> vponomaryov: yeah, that's what we just discovered
15:34:33 <csaba> bswartz: yeah we'll file one
15:34:58 <csaba> bswartz: how do you mean to get at 7) ?
15:35:03 <bswartz> csaba: I would fix it in liberty (sooner the better) and also propose a backport because it's a security issue for your driver
15:35:30 <u_glide> csaba: allow access and re-mount :)
15:35:31 <bswartz> csaba: for the scenario test there would need to be a second client with access that was not denied
15:35:43 <bswartz> or what u_glide said
15:36:17 <csaba> u_glide, bswartz : I thought we'd verify if the mount becomes defunct on denial
15:36:19 <bswartz> IMO a second client would be a cleaner way to write the test
15:36:53 <bswartz> csaba: we don't care what happens on the client side -- as I said the client defines its own behavior when it loses access
15:37:10 <bswartz> what we care about is that from the server side, nothing got modified after the access was denied
15:37:31 <bswartz> a similar test could be done to check that read access was also revoked, which would definitely require a second client
15:38:14 <csaba> bswartz: so there would be a window of time across with you check if server content is unchanged after denial?
15:38:29 <csaba> s/with/which/
15:38:49 <bswartz> should be pretty immediate when the API request succeeds
15:39:16 <bswartz> to make the test run stable-ly we might need to insert some fences or fsyncs
15:39:43 <csaba> bswartz: OK, that makes sense
15:40:16 <bswartz> we wouldn't want client caching behavior to make the test non-deterministic
15:40:28 <csaba> bswartz: yeah, that was my concern
15:40:46 <bswartz> okay so did we answer your questions?
15:40:55 <bswartz> I'll post a reply to the ML thread
15:41:07 <bswartz> I'm just slow on email so I hadn't gotten to it yet
15:41:20 <csaba> yep just let me know what's exactly a fence here? informal term or has an exact technical meaning?
15:41:57 <bswartz> in the case of the scenario test we'd just need to flush write caches after every data write
15:42:08 <bswartz> before going to the next step
15:42:18 <csaba> OK
15:42:25 <bswartz> I think a simple sync will do that
15:42:41 <csaba> yeah, so my questions got proper answers, thanks.
15:42:51 <bswartz> #topic open discussion
15:43:35 <bswartz> anyone have another topic?
15:43:42 <cknight> bswartz: Care to update folks on the progression of the replication design?
15:43:50 <lpabon> yes
15:43:55 <bswartz> cknight: no ;-)
15:44:05 <bswartz> lol
15:44:09 <lpabon> I have the topic of offline share expectation on resize
15:44:11 <cknight> bswartz: :-)
15:44:18 <lpabon> Should I send that out on the ML list instead?
15:44:27 <bswartz> lpabon go ahead
15:44:30 <lpabon> ok
15:45:37 <bswartz> for those interested in replication -- I think I mentioned last week that I think manila needs to support AZ and that the replication proposal needs updating based on that, and the update is not done
15:46:35 <bswartz> lpabon: ?
15:46:51 <lpabon> oh, I was just going to send it to the ML list :)
15:46:57 <bswartz> oh okay
15:47:08 <bswartz> we've got 13 minutes here but ML also works
15:47:16 <lpabon> ok, i'll start it
15:47:19 <bswartz> anyone interested in that can read the chat history in #manila from the last hour
15:47:45 <lpabon> it all started when I was reviewing the generic driver
15:47:55 <lpabon> support for shirnking a share
15:48:14 <lpabon> It takes the volume offline to be able to shrink the volume
15:48:42 <lpabon> It seemed to me that probably most storage systems can do this while online, but some may not
15:48:53 <lpabon> So, I asked on the #manila channel
15:49:02 <bswartz> I'm curious if we know of any system other than generic driver that can't do online expand of share
15:49:26 <lpabon> I'm almost 100% that gluster can do it online (expansion)
15:49:40 <bswartz> because if it's just a matter of making the generic driver better then we can undertake that challenge
15:49:55 <lpabon> bswartz: yeah i agree
15:50:25 <lpabon> maybe the question should be: What drivers/storage systems can resize while keeping the share online?
15:50:37 <lpabon> and which cannot..
15:50:39 <u_glide> lpabon: we had pool in ML
15:50:58 <ganso_> lpabon: Resize operation may be different for shrink and extend, for some backends
15:51:09 <lpabon> ganso_: agreed
15:51:20 <ganso_> a backend may be able to extend online, but requires to take share offline to shrink
15:51:31 <bswartz> yeah I'm more interested in extend than shink
15:51:41 <lpabon> What the concern is that to the user, there could be different behaviors on different shares, since they could be coming from different vendors
15:51:43 <bswartz> ganso_: +1
15:51:48 <lpabon> me too
15:52:23 <bswartz> I can live with shrink requiring the share to go offline, but extend really should be online if at all possible
15:52:34 <lpabon> But shrinking is important... Imagine paying $$ for some amount of storage space in one month due to a project.. then not needing that much storage the next...
15:52:46 <ganso_> hadnt we agreed that all vendors could extend online before, I dont remember
15:52:47 <lpabon> But what I am asking is really this:
15:53:04 <u_glide> ganso_: yes we had
15:53:15 <lpabon> Should we have the everyone conform to the same behavoir
15:53:16 <bswartz> lpabon: you have 2 recourses: you can suffer the downtime caused by a shrink or you can copy your data to a small share and delete the larger one
15:54:17 <lpabon> bswartz: absolutely true.  (it was be nice to have a "copy" function :-))
15:54:28 <ganso_> lpabon: I am working on that :)
15:54:44 <ganso_> I am implemeting a copy function for share migration
15:54:54 <lpabon> but still the question remains.. should the expected behavior be the same across all share vendors
15:55:14 <lpabon> that's really more of a philosophical question
15:55:34 <ganso_> we could have a shrink fallback that does exactly as bswartz said
15:55:49 <ganso_> create a smaller share, copy all data to it
15:56:03 <ganso_> and use the copy function implemented in manila core
15:56:04 <lpabon> but that takes time, plus the mount point may be different
15:56:12 <bswartz> generally speaking I'm in favor of complete consistency
15:56:18 <ganso_> true
15:56:30 <bswartz> I'm treating the generic driver and extend as a special case -- maybe it's the wrong thing to do
15:56:47 <lpabon> bswartz: yeah, I am not really coming up with an answer, just asking what we think should be the correct course
15:57:27 <lpabon> i think users will expect consistency across any share
15:57:36 <lpabon> consistency of behavior that is
15:57:48 <bswartz> inconsistent behavior making me very unhappy and I try to avoid it with designs that allow/enforce consistency
15:58:18 <lpabon> yeah, that is my concerrn also
15:58:19 <bswartz> the trouble here is that extend is such an important operation and I'm not willing to block it completely because one driver can't do it right
15:58:34 <bswartz> so I'm being hypocritical
15:59:22 <lpabon> bswartz: true, i agree, I'm just thinking we need to write it down on the API what the expected behavior is, so that customers selling Manila can tell their customers
15:59:28 <bswartz> we're almost out of time though so I think an ML post is called for
15:59:35 <lpabon> sure. will do
15:59:48 <ganso_> bswartz: +1
15:59:53 <bswartz> thanks everytone
15:59:59 <bswartz> everyone*
16:00:07 <bswartz> #endmeeting