16:01:11 <jgriffith> #startmeeting cinder
16:01:12 <openstack> Meeting started Wed Dec  4 16:01:11 2013 UTC and is due to finish in 60 minutes.  The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:16 <openstack> The meeting name has been set to 'cinder'
16:01:21 <eharney> hi
16:01:22 <jgriffith> hey hooooooooooooooo
16:01:26 <glenng> Greetings
16:01:28 <jgriffith> eharney: morning sir
16:01:29 <kmartin> hello all
16:01:29 <thingee> o/
16:01:38 <caitlin56> hi
16:01:39 <sgordon> \o/
16:01:41 <bswartz> hi
16:01:47 <aguzikova> hi
16:01:48 <zhiyan> hi all
16:01:50 <jungleboyj> morning all.
16:01:53 <jgriffith> nice... prompt attendance this morning
16:02:02 <joel-coffman> cheers
16:02:08 <jgriffith> joel-coffman: hola
16:02:09 <jungleboyj> :-)
16:02:12 <DuncanT> hey
16:02:16 * jgriffith is actuallyon time
16:02:22 <winston-d> o/
16:02:22 <jgriffith> yoooo... DuncanT
16:02:30 <jgriffith> alright... there's winston-d let's roll
16:02:51 <jungleboyj> Hey hey, the gang's all here.  Except avishay.  :-(
16:03:01 <jgriffith> #topic multi-attach
16:03:06 <kmartin> and hemna :(
16:03:06 <sgordon> ok
16:03:26 <sgordon> so i discussed this with zhiyan last week and attempted to frame a wiki page summarizing all the previous discussions on this
16:03:28 <kmartin> https://wiki.openstack.org/wiki/Cinder/blueprints/multi-attach-volume
16:03:37 <sgordon> and in particular highlighting outstanding issues/questions:
16:03:39 <sgordon> https://wiki.openstack.org/w/index.php?title=Cinder/blueprints/multi-attach-volume#Unresolved_Issues.2FQuestions
16:04:17 <avishay> Hi all
16:04:19 <sgordon> so in particular the two main ones zhiyan highlighted were finalizing the use of the volume and attachment status fields
16:04:29 <zhiyan> avishay: hi
16:04:36 <sgordon> and working out how to implement multi-attach as an extension to the core attachment functionality
16:04:50 <jungleboyj> that was fast avishay :-)
16:05:24 <avishay> Jungleboyj on my phone :-P
16:06:03 <sgordon> so per the wiki, volume attachment would be attached/detached and attachment status would be in-use / attaching / detaching
16:06:10 <sgordon> woops
16:06:17 <DuncanT> I'd also add 'Are there any data consistency requirements / expectations at all for multi-attach?' to the list of unresolved questions
16:06:44 <sgordon> DuncanT, right - so i think the expectation is that it's an explicit choice to share a volume
16:06:59 <sgordon> in the shared-volume blueprint it was suggested a volume must be explicitly marked "shareable"
16:07:25 <sgordon> and then it's expected that the consistency requirements are handled at the application / guest level
16:07:42 <jgriffith> sgordon: I agree with that
16:07:48 <bswartz> +1
16:07:51 <sgordon> what you of course want to avoid is any situation where someone could accidentally multi-attach
16:07:53 <jgriffith> sgordon: so personally this wiki is helpful IMO
16:07:54 <DuncanT> sgordon: I get that, but I mean, once a volume is marked as shared and attached shared, at the block level, what are the consistency expectations of the user? Same as an iSCSI mount? Less that that? Undefined?
16:08:03 <avishay> Sounds reasonable
16:08:14 <jgriffith> DuncanT: not sure I'm following you on that?
16:08:31 <sgordon> DuncanT, talking to the specific cluster app i looked at there is more that could be built on multi-attach to support clustered apps
16:08:37 <jgriffith> DuncanT: "consistency expectations of the user"
16:08:43 <sgordon> DuncanT, in particular yes improving the chain so that iSCSI reservations could be used
16:08:56 <sgordon> (for example)
16:09:01 <DuncanT> jgriffith: If I have it attached to vms A and B, and I do a write on B and a read on A of the same sectors, what should the result be under what circumstances?
16:09:20 <jgriffith> DuncanT: that's what I thought you might be getting at :)
16:09:36 <jgriffith> DuncanT: I've always said consumer beware or you're screwed
16:09:40 <jgriffith> maybe that's not sufficient
16:09:41 <sgordon> jgriffith, +1
16:09:42 <DuncanT> jgriffith: I'm fine with saying 'Same as iSCSI LVM', but I'd like it said
16:09:49 <caitlin56> DuncanT: that's a dangerous road to go down unless you stick with absolutely minimal guarantess. Before long the volume is a posix file.
16:09:58 <jgriffith> but I don't want Cinder to have any responsibility above the block device layer
16:10:04 <jgriffith> ie FS, consistency etc
16:10:20 <jgriffith> if that means it's too "icky" to do multiple R/W so be it
16:10:33 <DuncanT> I'm fine with minimal guarantees, I'd just like it stated early what they are
16:10:43 <avishay> Syncjronization must be in the guests
16:10:47 * jungleboyj just assumed multi-attach was ReadOnly.
16:10:51 <jgriffith> DuncanT: that's fair
16:10:52 <caitlin56> Stating what you cannot rely upon is a good idea.
16:11:00 <kmartin> DuncanT: jgriffith I'm pretty sure the Hypervisor help in this area
16:11:07 <jgriffith> jungleboyj: we've talked about that approach
16:11:25 <avishay> Kmartin. How so?
16:11:25 <caitlin56> Readonly is certainly simpler than shared write.
16:11:38 <sneelakantan> sgordon: what's the definition of a "read-only" attachment? Does that mean instance is not allowed to write anything to the volume, or that the written data is not persisted?
16:11:44 <sgordon> caitlin56, indeed - i was also wondering how this would impact snapshotting (for example)
16:11:47 <jungleboyj> It is cool if shared write can work, but sounds scary.
16:11:55 <kmartin> avishay: This is a common use case for clusters in ESX land
16:11:55 <sgordon> sneelakantan, the former - but i believe that it has to be enforced by nova
16:11:58 <DuncanT> Filesystems that can use multi-attach, like GFS, have certain requirements of the underlying storage. If you aren't a simple iSCSI mount, those requirements become important
16:12:15 <sgordon> sneelakantan, cinder simply stores whether the attachment is r/o or r/w
16:12:25 <jgriffith> kmartin: yeah, but they have the advantage of using their FS and controlling everything
16:12:28 <caitlin56> sgordon: that depends on who does the snapshot. ZFS won't have any problem.
16:12:28 <avishay> Kmartin ok
16:12:43 <kmartin> jgriffith: correct
16:12:50 <jgriffith> Anyway....  DuncanT makes a good point
16:12:52 <sgordon> caitlin56, right - so i think if we just say it's driver specific that's ok - just need to list which ones do/dont support it
16:13:02 <jgriffith> we DEF need to CAREFULLY and document the risks
16:13:16 <sgordon> jgriffith, yes and that's part of my intent with the wiki as well
16:13:20 <jgriffith> and make sure we have an excellent ref use case doc
16:13:24 <sgordon> i wanted to more explicitly document the design for this
16:13:31 <jgriffith> sgordon: yeah... very cool
16:13:33 <caitlin56> jgriffith: agreed. ANd that warning should include "if you don't like this uncertainty, use a file system."
16:13:34 <sgordon> as i know it's been discussed a lot over at least the last 12 months
16:13:36 <jgriffith> sgordon: thanks for that
16:13:40 <jgriffith> sgordon: :)
16:14:04 <avishay> A EULA should pop up when you try and make you agree to terms :-)
16:14:12 <DuncanT> An example documented use-case would be really useful
16:14:19 <bswartz> avishay: lol
16:14:26 <sgordon> DuncanT, ok - i think i have the details for that
16:14:37 <sgordon> DuncanT, will likely mean some other blueprints as well, probably on nova :)
16:14:38 <jgriffith> DuncanT: +1
16:14:47 <avishay> Duncan +1
16:14:48 <kmartin> yes, thanks sgordon for pullind this together
16:14:50 <jgriffith> DuncanT: TBH that's something I think we could improve on ALOT overall
16:15:09 <caitlin56> I think we should state that generally volumes have a single writer. We're allowing you to do multiple, but it is up to you to get them to coordinate as though they were a single writer.
16:15:17 <DuncanT> jgriffith: Definitely.
16:15:37 <DuncanT> caitlin56: 'coordinate' has no meaning without a /lot/ more detail
16:15:43 <sgordon> yeah
16:15:54 <sgordon> so in the example i am looking at traditionally it would use SCSI reservations
16:16:06 <sgordon> but to support that we also need virtio-iscsi support in nova, and NPIV support
16:16:11 <sgordon> not just multi-attach
16:16:16 <caitlin56> Duncant: what 'coordiation' is required is dependent on your specific application.
16:16:30 <sgordon> i'd be interested in the way other solutions co-ordinate this as well though
16:16:40 <DuncanT> caitlin56: It is also totally and utterly dependant on the facilities provided by the block device
16:16:52 <kmartin> sgordon: we'll need Fibre Channel as well
16:16:55 <DuncanT> caitlin56: When flushes and barriers happen and such
16:16:57 <sgordon> kmartin, +1
16:17:23 <kmartin> sgordon: we can help in the FC area
16:17:32 <caitlin56> DuncanT: yes, but we don't tell people how to write multi-processor safe programs. We just tell them it is their problem.
16:17:36 <sgordon> ok - so i think that gives me plenty to follow up on in terms of detail
16:17:43 <sgordon> to take to IRC/list
16:17:58 <jgriffith> sgordon: thanks for putting this together
16:18:07 <jgriffith> sgordon: maybe we'll actually move forward on it in I :)
16:18:10 <sgordon> any comments on how this would be implemented as an extension vs the core attachment functionality?
16:18:18 <DuncanT> caitlin56: Actually we also have very clear memory barrier instructions with clearly understood semantics, *then* tell people it is there problem
16:18:21 <kmartin> sgordon: jgriffith +1
16:18:23 <sgordon> zhiyan probably has a better understanding of I as to what that means
16:18:26 <jgriffith> it seems we're all finally starting to kind of agree on doing it
16:18:28 <avishay> Sgordon thanks!
16:18:34 <jgriffith> or at least giving up fighting about it :)
16:18:44 <sgordon> well i think what's important, and what i want to do
16:18:53 <sgordon> is continue driving the discussion forward and documenting any decisions
16:18:56 <winston-d> sgordon: virtio-scsi or virtio-iscsi?
16:19:06 <sgordon> it will help not just with implementation but user docs later as well
16:19:10 <caitlin56> sgordon: I am at a loss as to how to do multi-attach while keeping the ucrrent volume status.
16:19:15 <sgordon> (i come from a docs background)
16:19:26 * DuncanT will be happy to have a demo workload that is expected to work at the point we call ourselves 'done'... that will clear up most of my issues
16:19:38 <DuncanT> caitlin56: See the wiki page for ideas
16:19:45 <kmartin> should we talk about the second issue on multi-attach
16:19:45 <jgriffith> DuncanT: or create a whole bunch of new ones :)
16:19:57 <jgriffith> kmartin: probably
16:20:03 <kmartin> extension vs. core
16:20:07 <DuncanT> jgriffith: Almost certainly both ;-)
16:20:08 <sgordon> kmartin, +1
16:20:44 <zhiyan> jgriffith: you know we talked this on summit, but there's no conclusion. iirc team like make multi-attach as an extension in cinder but core
16:20:57 <jgriffith> zhiyan: :(
16:21:09 <jgriffith> zhiyan: yes this get's ugly IMO
16:21:15 <zhiyan> jgriffith: but currently i don't think cinder is ready to support a separated extension structure.
16:21:27 <sgordon> yes, so to me this is probably the more pressing issue as a blocker
16:21:34 <sgordon> we can work through use cases, detail etc. as a team
16:21:40 <jgriffith> If we go with the "no extension modifies tables" it makes this (and other) extensions pretty much not worth the trouble
16:22:01 <jgriffith> thingee: you were working on a proposal for something outside of the DB for persistent data?
16:22:28 <sgordon> winston-d, virtio-scsi sorry
16:22:34 <avishay> admin_metadata?
16:22:40 <thingee> jgriffith: yes
16:22:54 <thingee> I do apologize but I didn't find time last week to write something up
16:23:03 <jgriffith> thingee: no worries
16:23:13 <jgriffith> thingee: my question is based on the work you've done....
16:23:15 <zhiyan> avishay: yes, iiuc, it's admin_metadata .. but is it?
16:23:17 <thingee> I would like new extensions to assume they have their own table though
16:23:20 <winston-d> thingee: it was thanks giving, you were not supposed to work. :)
16:23:27 <jgriffith> thingee: is it worth the extra effort rather than creating a table? :)
16:23:35 <jgriffith> thingee: Oh?
16:23:44 <jgriffith> thingee: now I'm confused
16:24:03 <jgriffith> I'm not sure about shoving everything under the sun in to admin_meta
16:24:12 <jgriffith> that could get very ugly and ineffecient I think
16:24:35 <zhiyan> jgriffith: +1
16:24:36 <thingee> I mentioned in the last summit that we could think of extensions as a package. Installing it would introduce new tables, modifications to existing workflows on the api and manager, new rest api extension, etc
16:24:47 <caitlin56> Tracking the state of multiple dynamic attachments doesn' t sound like "admin" metadata to me.
16:25:11 <jgriffith> thingee: ohhh... sorry I think I missed that part
16:25:22 <jgriffith> thingee: that kinda solves the buld of the issues here IMO
16:25:25 <thingee> jgriffith: Don't think so. We had disagreements about this
16:25:42 <jgriffith> thingee: well.. I think I might have "misunderstood" what you were saying
16:25:42 <thingee> or at least I was told this wasn't worth time to spend on
16:26:02 <DuncanT> caitlin56: The term 'admin' here just means 'not seen directly by the user' and is a historical oddity
16:26:15 <jgriffith> #topic extensions and the DB
16:26:29 <avishay> Need to list pros and cons but could be cool
16:26:33 <jgriffith> Since I may have snarled this conversation at the summit without knowing what was being proposed
16:26:40 <jgriffith> let's see if we can figure something out
16:27:08 <thingee> I'd like to write up a proposal and then have that be changed over to the dev docs to assist new people.
16:27:10 <jgriffith> IUC the proposal is that only CORE functionality modifies existing DB tables?
16:27:16 <DuncanT> Limiting extentions to their own table(s) seems like a totally reasonable compromise to me
16:27:20 <kmartin> should with give thingee a little time to write up his proposal and then talk about it
16:27:31 <jgriffith> DuncanT: I agree... somehow I missed that part of the disucssion in HK
16:27:39 <jgriffith> or didn't understand it...
16:27:42 * jgriffith feels stupid
16:27:46 <thingee> jgriffith: right, extensions should avoid modifying the existing table. The problem with that though is you end up with a lot of joins
16:27:57 <DuncanT> jgriffith: I don't think that *was* the discussion in HK
16:28:13 <thingee> DuncanT, jgriffith: oh it was. the last informal session
16:28:23 <thingee> I mentioned a new table, but people brought up the issue of joins
16:28:24 <avishay> Yep
16:28:26 <jgriffith> thingee: I believe you :)
16:28:39 <DuncanT> jgriffith: The joins problem was what I pointed out, then we got very circular and decided to give Thingee time to solve it all ;-)
16:28:50 <glenng> *remembers that*
16:28:56 <jgriffith> DuncanT: that sounds like us ;)
16:28:57 <thingee> whew
16:29:03 <avishay> Haha
16:29:06 * thingee was not talking jgriffith's dog
16:29:09 <guitarzan> so the idea of "extensions can slightly modify core behavior" is a non starter?
16:29:13 <jgriffith> LOL
16:29:14 <zhiyan> thingee: yes we did
16:29:25 <guitarzan> admin actions reset status for example
16:29:37 <jgriffith> guitarzan: good example
16:29:40 <DuncanT> guitarzan: They can only via defined points in the task flows was a proposal
16:30:11 <jgriffith> guitarzan: however that's modify an existing column... different
16:30:19 <caitlin56> So how is the state of a shared volume reflected in tables for those who did not install the extension?
16:30:20 <guitarzan> jgriffith: oh? I didn't catch that
16:30:23 <guitarzan> jgriffith: carry on then :)
16:30:26 <jgriffith> guitarzan: the idea was modifying the table schema should be avoided
16:30:33 <winston-d> should we revisit all existing extensions and promote some of them to be core?
16:30:37 <guitarzan> jgriffith: ahh, hopefully there aren't many gripes against that
16:30:46 <thingee> winston-d: that's a whole other debate
16:30:55 <jgriffith> winston-d: yes we should
16:31:03 <jgriffith> but not today :)
16:31:10 <thingee> jgriffith: thank you
16:31:14 <winston-d> jgriffith: :)
16:31:40 <jgriffith> so the "join" problem does have potential to be an issue
16:31:56 <jgriffith> but this is what I ws getting at (I think) in HK
16:32:05 <jgriffith> in a lot of cases it's probably NOT going to be a problem
16:32:25 <jgriffith> and I think that we should consider this sort of thing on a case by case basis
16:32:42 <jgriffith> I understand the concern and need to keep from going crazy here
16:32:45 <DuncanT> I think we can wait intil an instance where it comes up and worry about it then... we aren't carving this rule in stone, we can revisit it
16:32:47 <sgordon> caitlin56, which state(s) in particular were you thinking about?
16:33:07 <jgriffith> I'm just not sure if hard line rules really are a good thing in terms of progress
16:33:08 <sgordon> caitlin56, to someone who doesnt have that extension whether it is shareable or not doesn't seem interesting to me, it's just another volume?
16:33:12 <caitlin56> Like whether the volume is attached?
16:33:19 <sgordon> caitlin56, same as today no?
16:33:21 <jgriffith> sgordon: +1
16:33:28 <DuncanT> sgordon: +1
16:33:38 <avishay> Thingee: i can implement replication by modifying the create-volume flow
16:34:06 <avishay> Thingee: want to try your idea with it?
16:34:10 <thingee> avishay: the idea would be the extension itself would inject a task into the existing flow
16:34:42 <jgriffith> thingee: I really like/d that idea
16:34:43 <avishay> Yes...though i would have to replace a task too
16:34:55 <jgriffith> and I think for 90+% of our extensions that works
16:35:14 <avishay> I think its a really neat idea
16:35:24 <jgriffith> ok... I don't want to get too in the weeds
16:35:46 <jgriffith> avishay: thingee it would be cool if we worked on something with replication as a first pass at trying this
16:36:05 <sgordon> jgriffith, yeah i think that gives me enough in mind to progress multi-attach anyway - zhiyan would you agree?
16:36:14 <jgriffith> I was hoping we could more clearly define what we want to do here in terms of policy
16:36:20 <jgriffith> ie extensions/db etc
16:36:20 <sgordon> indeed
16:36:22 <thingee> #action thingee writes a proposal and possibly example code to demonstrate a new ext. with table and injecting tasks
16:36:27 <kmartin> agree with jgriffith, this should stop us from moving forward on the multi-attach
16:36:31 <zhiyan> sgordon: yes, thanks. will follow this up later
16:36:50 <jgriffith> So... I want to see if I have this right (this time)
16:37:01 <jgriffith> We want to move forward trying to behave such that:
16:37:11 <jgriffith> 1. Extensions shouldn't mess with schema of existing tables
16:37:27 <jgriffith> 2. Extensions should inject into taskflow
16:37:43 <jgriffith> 3. Extensions that need DB info should use their own "new" tables in the DB
16:37:51 <jgriffith> Is that pretty much accurate?
16:38:09 <thingee> yes
16:38:36 <jgriffith> Ok, I think I'm good with saying we "try" that
16:38:40 <sgordon> yeah
16:38:51 <jgriffith> anybody have objections to the idea?  Or questions?
16:38:51 <avishay> +1
16:38:52 <zhiyan> jgriffith: thingee: sounds good, but i'm thinking does this can work well for multi-attach particular case. i'm thinking we need modify current volume table scheme..
16:38:54 <kmartin> sounds good
16:39:08 <jgriffith> zhiyan: well that's kinda the point
16:39:10 <sgordon> zhiyan, so i think the key question for us is where to store that a volume is shareable
16:39:18 <sgordon> zhiyan, sounds like "elsewhere"
16:39:23 <jgriffith> zhiyan: maybe we can be creative and do it differntly without modifying existing schema
16:39:36 <sgordon> yes, i need to consider that some more
16:39:37 <jungleboyj> jgriffith: Sounds good.
16:39:53 <zhiyan> jgriffith: humm...i will think about it..
16:39:54 <jgriffith> sgordon: I hate to say this but I would use types :)
16:40:00 <caitlin56> But if you store the fact that a volume is shareable "Elsewhere" how does a compute node know that it cannot take exclusive ownership of a volume?
16:40:00 <avishay> Need an array of instance ids, no?
16:40:13 <sgordon> jgriffith, that is actually probably a cleaner suggestion than anything else :)
16:40:23 <guitarzan> it seems more like attachments become a first class citizen
16:40:47 <DuncanT> caitlin56: To be decided.
16:41:05 <jgriffith> sgordon: and honestly that's what types are for IMO
16:41:06 <winston-d> caitlin56: compute node can query cinder ?
16:41:25 <sgordon> really the compute node is told it's got r/o or r/w, even in multi attach it assumes it has ownership
16:41:33 <caitlin56> winston-d: using which schmea? I think you end up addig an extra state enum to the "core" at the minimum.
16:41:34 <kmartin> sorry, I need to run.
16:41:37 <sgordon> it's the application / guest that handles that it's not exclusive
16:41:42 <jgriffith> sgordon: caitlin56 that's easier to solve atually
16:41:43 <DuncanT> Or the multi-attach can inject into the flow and include it in the connection data that it is possibly shared
16:41:55 <jgriffith> sgordon: caitlin56 there's provider/connection info that I added
16:41:55 <sgordon> right
16:42:05 <jgriffith> kmartin: no worries... catch ya later
16:42:12 <sgordon> so i dont think it's insurmountable
16:42:14 <jgriffith> Ok... we need to save time for ACL
16:42:23 <jgriffith> I think we all kinda of agree on this
16:42:24 <sgordon> the direction we covered here is definitely helpful in terms of moving the design forward
16:42:29 <jgriffith> it could be challenging but I think it's doable
16:42:35 <jgriffith> and I think it's efficient
16:42:49 <jgriffith> if it ends up being something that is insurmountable we can look at an exception process
16:42:55 <jgriffith> but we should at least try
16:43:01 <jgriffith> everybody cool with that?
16:43:06 <sgordon> so i will try and update the wiki to reflect what we've discussed and then we can continue on list etc
16:43:17 <jgriffith> sgordon: sounds good to me
16:43:21 <winston-d> yup, please try not to mess up with existing schema
16:43:22 <DuncanT> sgordon: +1
16:43:26 <zhiyan> sgordon: thanks for working on that
16:43:27 <jgriffith> winston-d: :)
16:43:29 * sgordon believes thingee put an action on the more formal proposal for extensions
16:43:34 <avishay> Cool
16:43:36 <sgordon> i will cover the multi-attach wiki
16:43:40 <jgriffith> sgordon: yes he did
16:43:55 <jgriffith> ok... I feel better about that subject now :)
16:44:18 <sgordon> #action sgordon to update multi-attach wiki with today's comments/concerns and further discussion on list
16:44:35 <jgriffith> #topic ACL
16:44:40 <jgriffith> alatynskaya: ping
16:44:48 <alatynskaya> yes, hello)
16:44:49 <aguzikova> hello again
16:44:56 <jgriffith> alatynskaya: aguzikova hey there
16:45:13 * rushiagr trudges into the meeting, feeling sorry for being late the umpteenth time
16:45:15 <aguzikova> we've added more details here:
16:45:18 <aguzikova> #link https://etherpad.openstack.org/p/icehouse-cinder-acls-for-volumes
16:45:58 <aguzikova> and we have a suggestion to hold weekly separate meetings for ACL
16:46:09 <aguzikova> is this a good idea?
16:46:28 <jgriffith> aguzikova: the separate meetings?
16:46:40 <jgriffith> aguzikova: probabaly/maybe
16:46:49 <DuncanT> I worry that separate meets will miss feedback from people who only have a peripheral interest but a good eye for spotting problems
16:46:54 <alatynskaya> if there would be a lot of questions to design
16:47:03 <jgriffith> aguzikova: guitarzan DuncanT thingee I have a question about the whole idea in general though....
16:47:31 <jgriffith> So IMO this is a neat feature for sure... but what I'm wondering is "is it useful"
16:47:42 <jgriffith> is there demand for something like this?
16:47:51 <jgriffith> or are we solving a problem that doesn't really exist?
16:49:01 * jgriffith hears crickets
16:49:01 <DuncanT> We've had questions about it, and examples of why customers want it, but I'm not sure it is a huge thing.
16:49:15 <aguzikova> ACL is a good foundation for flexible read-only-volumes, public-volumes features
16:49:17 <guitarzan> I haven't heard much
16:49:20 <caitlin56> jgriffith: it might be a "real issue" once we have multi-attach.
16:49:22 <alatynskaya> jgriffith: is the current realisation of public volumes  throug admin metadata is quite ok?
16:49:31 <alatynskaya> aguzikova: +1
16:49:52 <alatynskaya> acl is flexible enough
16:49:57 <jgriffith> aguzikova: that makes sense
16:50:18 <alatynskaya> and also for multi-attach
16:50:21 <jgriffith> aguzikova: I wonder if there's a different approach that could be taken here though
16:50:29 <jgriffith> something a little less complex
16:50:36 <thingee> I know I led the original speaker down the road of it being a core feature, but I think after a later discussion I changed my vote.
16:50:38 <rushiagr> ACLs would definitely be neater
16:50:53 <DuncanT> The usecases we were provided are much more basic than multi-attach... just about stopping most uses inside a tenant being able to do dangerous things
16:50:54 <jgriffith> like maybe doing something in keystone
16:50:58 <thingee> I do apologize about that
16:51:13 <jgriffith> DuncanT: like what?
16:51:25 <DuncanT> jgriffith: e.g. volume transfer
16:51:54 <jgriffith> DuncanT: disable a user from being able to xfr?  Why is that dangerous though?
16:52:21 <winston-d> DuncanT: tech support doesn't need admin privilege?
16:52:22 <jgriffith> sorry... I shouldn't side track the discussion
16:52:24 <caitlin56> DuncanT: and can you really prevent it, if the user can read the volume, can't they do anything with what they read?
16:52:44 <DuncanT> caitlin56: Different problem space
16:53:00 <jgriffith> So my concern is that doing this breaks down a lot of the tenant security things that we have in place
16:53:30 <jgriffith> I'm concerned that this would introduce all sorts of security issues
16:53:37 <DuncanT> jgriffith: My usecases are all subtractive from the current tenant roles, not adative like public volumes
16:53:43 <jgriffith> unless it was a pure extension that could be completely disabled
16:54:05 <caitlin56> jgriffith: I also like the very simple implied ACL that each volume is controlled by the Tentant Admin that owns it.
16:54:22 <jgriffith> DuncanT: seems odd to take away any of the things that we expose
16:54:30 <jgriffith> DuncanT: but you're the SP not me
16:54:47 <guitarzan> DuncanT: we would probably use rbac for the "limit transfer" case
16:54:52 <guitarzan> and not necessarily do it per volume
16:55:10 <guitarzan> but that's kind of a guess
16:55:23 <alatynskaya> caitlin56:  in our case Tentant Admin is volume owner and it can manage his volume
16:55:24 <jgriffith> I'd like to hear other peoples thoughts/concerns about ACL
16:55:26 <DuncanT> guitarzan: RBAC is fine but only the SP can define the roles
16:55:32 <jgriffith> in gernal
16:55:35 <guitarzan> DuncanT: that's true
16:55:37 <jgriffith> general
16:55:51 <DuncanT> guitarzan: That enables some things but ACLs have the potential to be way more flexible
16:55:59 <guitarzan> DuncanT: totally agree
16:56:09 <wolsen> it seems that ACLs are generally a good thing, but I suspect some place like keystone may be a better place as there's probably a more general use case across the board than just cinder volumes requiring ACLs
16:56:27 <caitlin56> alatynskaya: I think that's the point jgriffith is hinting at, without multi-attach do we need any ACLs other than tracking the volume owner?
16:56:41 <jgriffith> wolsen: I sort of had the same though, until it was suggested folks may only want to limit certain operations
16:56:55 <jgriffith> in which case it becomes more complex to go tht route and you might as well put it all in Cinder
16:57:25 <jgriffith> DuncanT: guitarzan the "flexibility" is kinda what concerns me
16:57:39 <wolsen> jgriffith: agreed that it becomes more complex that way, but when looking at the bigger picture I think it might be painful having x implementations of ACLs across the full stack
16:57:40 <jgriffith> DuncanT: guitarzan does swift or anybody else have this concept?
16:57:47 <guitarzan> swift does acls
16:57:48 <notmyname> ?
16:57:53 <jgriffith> wolsen: agreed
16:57:54 <DuncanT> Swift does, yes
16:58:00 <jgriffith> notmyname: LOL
16:58:02 <guitarzan> notmyname: has a ping on swift :)
16:58:05 <winston-d> DuncanT: so the 'virtual private cloud' that AWS has, is it an example of RBAC within account/tenant?
16:58:07 <notmyname> indeed :-)
16:58:09 <alatynskaya> and glance also has
16:58:23 <jgriffith> alatynskaya: good point
16:58:26 <DuncanT> winston-d: I think so, yes
16:58:38 * jgriffith needs to look at swifts implementation
16:58:44 <DuncanT> winston-d: And a pretty good example complex usecase
16:58:49 <guitarzan> glance has acls?
16:58:50 * notmyname is available for questions
16:58:51 * jgriffith is going to type in "swift" all day to bug notmyname
16:58:54 * guitarzan looks it up
16:59:25 <zhiyan> alatynskaya: glance just using backend store's acl, like swift
16:59:27 <jgriffith> we're going to run out of time
16:59:33 <DuncanT> swift's implementation has issues too... you need to touch keystone to add new combinations, like "add only, no delete or over-write"
16:59:33 <caitlin56> Cinder ACLs should be simpler than Swift ACLs, but folloiwng the Swift pattern makes sense.
16:59:38 <guitarzan> I think we might need to clarify in tenant acl vs out of tenant acls?
16:59:41 <jgriffith> alatynskaya: aguzikova would you be available to talk in #cinder for a few minutes?
16:59:56 <hartsocks> if you need a few minutes, we're probably going to run short today anyway.
17:00:10 <aguzikova> jgriffith, yes,of course
17:00:10 <jgriffith> caitlin56: why would they be simpler?  You're either implementing them or not IMO
17:00:12 <alatynskaya> yes
17:00:26 <jgriffith> Let's all move over to #cinder and give up the room
17:00:33 <jgriffith> #endmeeting cinder