16:00:33 <jgriffith> #startmeeting cinder
16:00:34 <openstack> Meeting started Wed Apr  3 16:00:33 2013 UTC.  The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:38 <openstack> The meeting name has been set to 'cinder'
16:00:44 <jgriffith> hey everybody!
16:00:51 <rushiagr> jgriffith: o/
16:00:51 <eharney> hello
16:00:54 <dachary> hi
16:01:03 <rushiagr> sorry, missed the last meeting. Was a bit sick
16:01:15 <avishay> hey
16:01:16 <jgriffith> rushiagr: hope you're feeling better
16:01:21 <jgriffith> avishay: hola!
16:01:24 <thingee> o/
16:01:30 <jgallard> hi
16:01:33 <jgriffith> and there's the man thingee
16:01:40 <jgriffith> alright... let's get started
16:01:40 <rushiagr> jgriffith: yes
16:01:45 <bswartz> I'm a bit sick this week, but I'm here
16:01:49 <kmartin> hello
16:01:58 <jgriffith> kmartin: howdy
16:02:01 <vincent_hou> hi
16:02:04 * DuncanT wakes up
16:02:06 <jgriffith> Ok... so short agenda at: https://wiki.openstack.org/wiki/CinderMeetings#Agenda_for_next_meeting
16:02:10 <jgriffith> DuncanT: !!!!
16:02:18 <jgriffith> I thought you were on vacation!
16:02:37 <jgriffith> Alright... good turn out this week
16:02:40 <DuncanT> Got back this morning
16:02:43 <jgriffith> Let's get started
16:02:50 <jgriffith> #topic finalize session topics
16:03:08 <jgriffith> http://summit.openstack.org/
16:03:21 <jgriffith> So I've narrowed it down a bit
16:03:21 <avishay> jgriffith: for first-timers at the summit, can you give a quick intro as to how a session is run?
16:03:35 <jgriffith> avishay: sure... good idea
16:03:46 <jgriffith> So each session is about 45 minutes
16:04:01 <jgriffith> That's going to include your time to get everybody in the room, get started and present your topic
16:04:11 <jgriffith> We almost ALWAYS run out of time
16:04:19 <jgriffith> The idea behind the sessions...
16:04:36 <jgriffith> They're intended to be design sessions, not user sessions, tutorials etc
16:05:02 <jgriffith> They're intended to make design and feature decisions for the upcoming dev cycle
16:05:25 <jgriffith> Unfortunately it's common for folks not involved in the project to wander in and try to learn about OpenStack
16:05:35 <jgriffith> So....
16:05:43 <avishay> Presenter shows up with intro slides, then discussion?
16:06:04 <thingee> avishay: slides is optional from what I've seen. some people just began with an etherpad up
16:06:06 <jgriffith> avishay: doesn't even need to be that formal (ie the intro slides)
16:06:22 <jgriffith> it's a pretty ad-hoc deal, and it's mostly about collaborating and working
16:06:26 <avishay> ok
16:06:40 <jgriffith> Don't get carried away worrying about formal presentation etc
16:06:43 <creiht> often just having an ehterpad up works while you discuss something works very well
16:06:48 <avishay> if i don't have to make slides, i'm a happy camper
16:06:53 * creiht goes back to lurking :)
16:06:53 <jgriffith> creiht: +1
16:06:59 <jgriffith> I was going to get to that
16:07:06 <jgriffith> etherpad is the BEST way to go about things
16:07:15 <dachary> :-D a few slides with URLs & references are helpful, IMHO
16:07:18 <jgriffith> that way everybody get's to contribute and take notes and we have a record
16:07:29 <thingee> dachary: I'll give you a giant QR code
16:07:40 <jgriffith> dachary: that's not really the point of the design session though
16:07:42 <dachary> neat :-)
16:07:44 <avishay> thingee: :)
16:07:55 <jgriffith> I *think* there are some recordings of design sessions out on the web
16:08:09 <jgriffith> I'll see if I can find some and provide a link to folks that haven't experienced the mahem yet ;)
16:08:23 <avishay> haha
16:08:41 <jgriffith> So the key thing here is it's the rare opportunity that we all get to meet face to face and has some of our decisions out
16:08:45 * DuncanT hopes there are no videos...they're all going to make him out as an argumentative sod...
16:08:54 <jgriffith> DuncanT: HA!!!
16:09:03 <creiht> DuncanT: we already new that anyways :)
16:09:04 <bswartz> jgriffith: the design summit sessions are broadcast but not recorded
16:09:08 <creiht> knew
16:09:20 <jgriffith> bswartz: some have been recorded
16:09:29 <jgriffith> anyway.....
16:09:38 <jgriffith> avishay: does that help?
16:09:43 <bswartz> the conference sessions are definitely recorded -- I've looked and failed to find any design session videos
16:09:56 <avishay> jgriffith: yes, sure does - thanks!
16:10:04 <jgriffith> kmartin: DuncanT thingee creiht did I miss anything important to point out?
16:10:08 <kmartin> to create a new eithepad start here, https://etherpad.openstack.org/ then being it up in your session
16:10:23 <kmartin> sounds good
16:10:26 <DuncanT> jgriffith: I think that covers it
16:10:52 <jgriffith> Key things....
16:10:57 <jgriffith> Show up and start ON TIME!!!!
16:11:08 <jgriffith> If you're an attendee... show up ON TIME!!!
16:11:31 <thingee> sounds good to me. Expect to run out of time and to have this be a stepping stone towards a decision. Spend the design summit discussing things are difficult to convey over ML and irc
16:11:31 <jgriffith> The alloted time goes by VERY quickly and there's never a shortage of discussion
16:11:33 <bswartz> seriously -- it's often standing room only if you're late
16:11:42 <jgriffith> thingee: exactly
16:12:00 <jgriffith> the idea is to focus on the *hard* things
16:12:15 <dachary> any advice on how to make sure people get a chance to speak ? sometime it's difficult to say something without interrupting
16:12:17 <thingee> otherwise you'll be a bit discouraged if you expected everyone to agree right away :)
16:12:25 <jgriffith> and to have a few beers with the folks we all work with throughout the world on a daily basis :)
16:12:47 * thingee thinks jgriffith needs to take a break during the summit this time
16:13:01 <jgriffith> thingee: sadly my employer doesn't agree :)
16:13:15 <DuncanT> dachary: That's really up to whomever is running the session
16:13:45 <jgriffith> dachary: you'll kinda see how it goes, but usually getting people to be able provide input is not a problem with our groups
16:13:49 <jgriffith> in fact it's the opposite
16:14:01 <thingee> heh
16:14:04 <jgriffith> the harder part is keeping some focus in the group
16:14:15 <bswartz> dachary: getting a seat towards the front of the room helps
16:14:19 <jgriffith> so the only thing I would say....
16:14:28 <DuncanT> Are we planning on an early unconference like last year to rough some of this stuff out without the extended audience? It seemed to really help last year to get the core team singing from roughly the same hymn sheet...
16:14:35 <jgriffith> be respectful, let people talk, especially presenters
16:14:41 <bswartz> DuncanT: +1
16:15:03 <jgriffith> DuncanT: yeah, probably on some of the topics we'll want to do that
16:15:17 <jgriffith> but I also think we're more cohesive than we were at this time last year
16:15:17 <thingee> ah yes, they call the front the fish bowl...at least it was that back at bexar. But you should be speaking up if you're in the front or have a real invested interest and now just on facebook on your lappy :)
16:15:18 <kmartin> bswartz: don't give out to many of the secrets :)
16:15:20 <jgriffith> and we're a bigger group
16:15:31 <thingee> now=not
16:15:43 <kmartin> did we get a bigger room this year?
16:15:59 <jgriffith> kmartin: I sure hope so
16:16:00 <jgriffith> :)
16:16:21 <jgriffith> Ok... we can talk more about what to expect etc in cinder channel
16:16:41 * avishay looks at the #topic .. sorry for hijacking :P
16:16:44 <jgriffith> #topic Finalize session topics
16:17:14 <jgriffith> I've hacked things a bit here
16:17:31 <jgriffith> Combined a couple of sessions and just removed one or two altogether
16:17:43 <jgriffith> I've got it down to 7 remaining
16:17:57 <jgriffith> Which puts about 3 over budget
16:18:08 <kmartin> see a few ones showed up since the last meeting
16:18:16 * DuncanT still sees bazzilions on the list
16:18:18 <jgriffith> kmartin: yeah, baremetal
16:18:29 <kmartin> Cinder FC SAN Zone/Access Control Manager
16:18:47 <jgriffith> Yeah...
16:19:02 <avishay> jgriffith: how many total do we get?
16:19:10 <jgriffith> avishay: about 12
16:19:46 <jgriffith> avishay: I may be able to steal a session or two if needed
16:19:58 <avishay> jgriffith: I think my topic on capabilities is similar to winston's on extra specs - i'd be happy to co-present with him
16:20:09 <avishay> (if it's indeed the case)
16:20:16 <jgriffith> avishay: yeah, that's what I put in the review I believe
16:20:33 <avishay> oh, he has two...
16:21:08 <avishay> I would say "Standardizing vol type extra spec as driver input" and "Cinder Capability Standardization" are similar
16:21:29 <avishay> Also "Revisit backend capabilities/stats reporting" is in the same direction
16:21:54 <jgriffith> avishay: notice I refused "Revist backend...."
16:22:25 <jgriffith> avishay: or do you guys not see the review status and notes?
16:22:42 <avishay> jgriffith: yes i did, but if you need you can probably refuse mine too and winston and i can do 1 session on volume types / extra specs / etc
16:22:58 <avishay> jgriffith: i don't see the notes, just status
16:23:10 <jgriffith> avishay: Ok, so that's what I stated in the notes
16:23:21 <jgriffith> I'll send updates to all of you that I lumped together :)
16:23:51 <DuncanT> Unit testing can easily become a unconference... I don't think it is of that much general interest
16:23:55 <jgriffith> Out of the ones that remain... we need to pick what we want to cover
16:24:05 <jgriffith> DuncanT: that'll work
16:24:08 <DuncanT> (We might have already agreed that last week... rings a bell)
16:24:35 <thingee> DuncanT: definitely intersted in it. I just thought it would be more useful for us cinder folks.
16:25:19 <jgriffith> Ok... so "cinder plugin interface"
16:25:34 <jgriffith> Just to clarify
16:25:57 <jgriffith> The idea here is that 3'rd party drivers would no longer be a part of the Cinder project proper
16:26:17 <jgriffith> Vendors would be free to do their own thing and distribute how the see fit
16:26:26 <jgriffith> What that would mean for us though...
16:26:46 <jgriffith> Is some architecture/framework to provide some black-box compatability testing/verification
16:26:53 <vincent_hou> remove all the drivers?
16:26:58 <jgriffith> Some sort of certification process
16:27:12 <jgriffith> vincent_hou: ultimately that's sort of what it boils down to
16:27:14 <DuncanT> That sucks and would mean an epic amount more work
16:27:24 <jgriffith> DuncanT: up front it would for sure
16:27:45 <guitarzan> we basically just test ours functionally
16:27:49 <kmartin> I think the community would suffer with quality of the drivers and cinder as a whole as most active members have drivers
16:27:55 <DuncanT> (and that is a rather more apocalyptic vision of what was proposed than I understood it to be)
16:28:17 <jgriffith> guitarzan: yeah, so actually it is sort of what you guys are doing anyway
16:28:42 <avishay> IMHO the session would be a heated debate with no outcome
16:28:42 <jgriffith> Ok, so it sounds like we're not ready to go down that path
16:28:47 <bswartz> -1 on plugin interface/removing drivers
16:28:49 <jgriffith> I'll nix it
16:28:49 <guitarzan> I think we did have a bit of discussion about this a couple weeks ago in the meeting
16:29:03 <kmartin> avishay: bswartz +1
16:29:08 <guitarzan> it didn't sound clear what it would mean, since it seems we already have a plugin interface :)
16:29:13 <thingee> I think it would be a lot of work upfront, however, core would have more bandwidth to spend well, on core.
16:29:14 <dachary> jgriffith: it makes sense to me since there is no way to run actual integration tests with proprietary solutions. It would be good however, to keep free software drivers for which a tempest can be run using standard packages.
16:29:18 <jgriffith> just FYI, this is more along the lines of how Quantum is working I believe
16:29:33 <jgriffith> dachary: huh?
16:29:36 <vincent_hou> issue: who is supposed to ensure the further quality of the drivers
16:29:49 <vincent_hou> community?
16:29:52 <jgriffith> dachary: There's no suggestion that the reference impl driver would go away
16:30:03 <jgriffith> vincent_hou: the vendor providing the driver
16:30:12 <jgriffith> so no need to debate it sounds like
16:30:24 <jgriffith> doesn't seem that there's much interest in this so we can just move on
16:30:34 <jgriffith> Next one:
16:30:35 <dachary> jgriffith: I was refering to ceph. I understand that lvm is going to stay. Does that make sense ?
16:30:55 <DuncanT> I think we can aim to put some more though into the subject for the next summit? There are clearly people who already work that way, so how the core supports / doesn't support such endeavours *is* an issue, but I don't think it is a pressing one yet
16:31:28 <jgriffith> DuncanT: +1
16:31:40 <jgriffith> dachary: Oh I see...
16:31:51 <DuncanT> (I'd rather put the thought into how to test what we have while it is easy, then deal with the hard problems later)
16:31:52 <jgriffith> dachary: well that's riddled with some other issues that I'd be concerned about
16:32:18 <jgriffith> DuncanT: agreed
16:32:26 <jgriffith> I think right now that's a better thing to focus on
16:32:32 <jgriffith> Ok
16:32:39 <jgriffith> #topic independent scheduler
16:32:52 <jgriffith> I'm not sure how I feel about this one
16:33:10 <jgriffith> It's a neat idea, but we haven't really identified a real problem here as of yet that I'm ware of
16:33:13 <jgriffith> aware
16:33:41 <DuncanT> It seems to mostly just work. Might need some tweeking to the retry logic, but that seems like bug fixing not design work
16:33:59 <jgriffith> DuncanT: what seems to mostly just work?
16:34:04 <DuncanT> It is not entirely deterministic, but that isn't necessarily a sensible design aim
16:34:13 <DuncanT> jgriffith: Having two schedulers runnign
16:34:23 <bswartz> what is the current remedy when the node hosting your scheduler or API service goes poof? just detect this case and start up a new one?
16:34:24 <jgriffith> DuncanT: you mean in our current code
16:34:38 <jgriffith> bswartz: build an HA cinder setup
16:34:43 <jgriffith> just like in Nova
16:34:45 <DuncanT> jgriffith: Yeah. I only smoke tested it but it looks basically good though non-deterministic
16:34:52 <jgriffith> DuncanT: got ya
16:35:14 <DuncanT> Nova works fine with multiple copies of the scheduler too... no need to mess with pacemaker etc
16:35:20 <jgriffith> So my take on this is...
16:35:26 <DuncanT> Much nicer from an HA POV
16:35:38 <jgriffith> I'd rather focus on HA guides for implementation than go down this built in approach
16:35:51 <bswartz> +1
16:36:00 <dachary> +1
16:36:12 <hemnafk> +1
16:36:15 <jgriffith> As we move into H we can revisit if vincent_hou would like
16:36:21 <avishay> +2
16:36:21 <jgriffith> vincent_hou: sound reasonable?
16:36:24 <DuncanT> I much prefer to make multiple copies work / keep working
16:36:38 <vincent_hou> cool
16:36:54 <jgriffith> vincent_hou: my only reasoning here is setting priorities, not because I don't like the idea
16:37:20 <vincent_hou> ;-) i understand.
16:37:27 <jgriffith> cool
16:37:30 <jgriffith> alrighty....
16:37:38 <jgriffith> #topic cinder for baremetal
16:38:02 <jgriffith> I'm interested in this but to be honest I need some more detail than what's provided
16:38:12 <jgriffith> anybody have any insight on this one?
16:38:32 <bswartz> I know we have some customers who are already using cinder for baremetal, so I'm not sure what's missing
16:38:34 <hemna> What do we need to support it other than what we are doing for nova already?
16:38:54 <jgriffith> So this is the problem I think
16:39:09 <jgriffith> I don't think any of us are on the same page WRT what they're going for here
16:39:23 <bswartz> who proposed it?
16:39:23 <jgriffith> I suspect this is manage local storage on a baremetal install maybe?
16:39:35 <jgriffith> Robert Collins
16:40:00 <clarkb> lifeless: ^
16:40:10 <jgriffith> clarkb: thank you :)
16:40:17 <dachary> #link http://summit.openstack.org/cfp/details/45
16:40:28 <clarkb> it is early morning his time right now but should be around in a few hours?
16:40:47 <jgriffith> if folks would like I'll ping him later and get some details
16:41:11 <jgriffith> Ok... that's what I'll do
16:41:14 <guitarzan> it almost sounds interesting just because I have no idea what it means :)
16:41:22 <thingee> guitarzan: +1
16:41:27 <jgriffith> #action jgriffith sync up with lifeless on cinder baremetal
16:41:32 <jgriffith> guitarzan: indeed! :)
16:41:57 <jgriffith> Ok, the only other one I had some questions about
16:41:59 <bswartz> the session proposal scores high on buzzword compliance
16:42:07 <jgriffith> bswartz: haha
16:42:14 <dachary> my interpretation is that it's about attaching a LV directly to the VM without going thru iSCSI
16:42:15 <jgriffith> #topic volume give/take
16:42:26 <avishay> dachary: that's what i thought as well
16:42:28 <jgriffith> dachary: I believe you're correct but dont' want to guess
16:42:37 <hemna> dachary, isn't that the job of nova's baremetal support though?
16:42:40 <jgriffith> and it's useful in other places (Glance)
16:42:45 <jgriffith> anyway....
16:42:50 <jgriffith> DuncanT: give/take
16:43:03 <jgriffith> Is this something that's really high demand?
16:43:23 <winston-d> Hey, guys. Sorry I'm late.
16:43:31 <jgriffith> and is it full of peril to update context on volumes to change tenant ID?
16:43:31 <DuncanT> jgriffith: We've people interested in it. It's really a special case of ACL though...
16:43:41 <avishay> winston-d: hey!
16:43:42 <dachary> #link https://wiki.openstack.org/wiki/VolumeTransfer
16:43:50 <jgriffith> DuncanT: So if we get ACL's implemented it *should* help with this
16:44:00 <avishay> I wanted to say, this seems like it has overlap with the ACL topic
16:44:02 <winston-d> Avishay hi
16:44:08 <bswartz> is there any session to cover multi-attach? because give/take sounds like a degenerate case of multi-attach
16:44:11 <DuncanT> jgriffith: Yeah...
16:44:24 <jgriffith> bswartz: yes there is and no it's not the same
16:44:26 <DuncanT> Multi-attach != give-take
16:44:33 <hemna> bswartz, yah jgriffith and us want to talk about multi-attach
16:44:33 <bswartz> ok
16:44:34 <avishay> bswartz: http://summit.openstack.org/cfp/details/130
16:44:50 <jgriffith> give-take in a nut-shell is transfer volumes among tenants
16:44:56 <jgriffith> CMIIW DuncanT
16:45:13 <hemna> bswartz, we want to allow ESX cluster nodes to attach the same volume
16:45:16 <jgriffith> So here's the thing on give/take
16:45:27 <jgriffith> I don't know that's it's going to be a terrible thing to implement
16:45:33 <DuncanT> You're spot on. It just adds a bit of beurocracy to make it hard to do by accident
16:45:37 <jgriffith> and I don't know that there's a huge debate on whether to do it or not
16:45:49 <jgriffith> I think we can has that one out unconf or even over IRC
16:45:55 <DuncanT> I've not heard anybody who hates it...
16:46:03 <jgriffith> and I'd rather get ACL's figured out before trying to tackle it
16:46:16 <jgriffith> I think some implementation details may fall out as a result of ACL's
16:46:19 <DuncanT> Sure. Can we just mention it at the ACL session? Then anybody who might want to kick off will know about it
16:46:28 <jgriffith> DuncanT: For sure!
16:46:31 <avishay> DuncanT: +1
16:46:39 <dachary> +1
16:46:40 <jgriffith> I think we weave it in as a use case of ACL's
16:46:43 <jgriffith> or a motiviator
16:46:43 <winston-d> +1
16:46:53 <jgriffith> or whatever you somebody wants to call it :)
16:47:24 <vincent_hou> DuncanT: is the ACL for cinder project only?
16:47:51 <DuncanT> vincent_hou: I'm not the main driver for ACLs, just an interested bystander
16:48:02 <jgriffith> vincent_hou: isn't ACL's you?
16:48:23 <vincent_hou> yes, i submitted it
16:48:39 <dachary> #link http://summit.openstack.org/cfp/details/98
16:49:22 <winston-d> Vincent_Hou will u attend this summit?
16:49:32 <vincent_hou> yes
16:49:42 <winston-d> Cool
16:49:43 <vincent_hou> visa received today
16:49:43 <dachary> vincent_hou: "Use case: several users can share the data in one volume." do you mean read-only ?
16:49:57 <jgriffith> vincent_hou: DuncanT I've approved the ACL and added the note about give/take
16:50:01 <jgriffith> and the link to the give/take wiki
16:50:05 <vincent_hou> yes. it came from that use case.
16:50:18 <jgriffith> I'll expect the two of you to synch up and run this one together if that's ok?
16:50:52 <vincent_hou> ok.
16:50:54 <avishay> dachary: VMs might share read-write volumes too...
16:50:55 <DuncanT> Sure
16:51:23 <jgriffith> Everybody good with read/only multi-attach?
16:51:29 <dachary> avishay: that is scary :-)
16:51:37 <bswartz> jgriffith: no
16:51:43 <kmartin> jgriffith: yes
16:51:45 <bswartz> read/write multi attach is important
16:51:46 <avishay> dachary: why?  some file systems / applications handle it just fine
16:51:56 <avishay> bswartz: +1
16:51:58 <jgriffith> bswartz: sure
16:52:06 <vincent_hou> yes
16:52:06 <jgriffith> I have no problem with looking into that
16:52:14 <dachary> avishay: interesting
16:52:18 <jgriffith> My focus however first is R/O multi-attach and go from there
16:52:30 <xyang> hemna: is there a session on multiattach in nova too?
16:52:38 <hemna> I don't know.
16:52:48 <bswartz> I fail to understand why it's hard to do -- we go out of our way to prevent multi attach
16:53:01 <kmartin> bswartz: I'll be talking about that in the same session with jgriffith
16:53:03 <hemna> There is a group here at HP that is working on the ESX changes to support attaching a volume to multiple vmware server nodes.
16:53:11 <bswartz> at the driver level multi-attach can already work
16:53:15 <jgriffith> bswartz: really?
16:53:19 <hemna> I'd just like to avoid needing to touch every driver to support it.
16:53:25 <jgriffith> it's not that it's hard to do, it's that it breaks shit!
16:53:48 <DuncanT> bswartz: It is hard because data consistency issues crop up all over the shop
16:53:59 <JM1> what's the use case for R/W multi-attach?
16:54:01 <guitarzan> we just need a --yes-i-really-mean-it flag
16:54:05 <jgriffith> latencies, consistencies, lost data, encryption
16:54:15 <jgriffith> guitarzan: +1 :)
16:54:22 <bswartz> JM1: the use case for R/W multi attach is clustered filesystems with a quorum disk
16:54:34 <jgriffith> JM1: allowing somebody to F'themeselve in a serious manner
16:54:35 <DuncanT> We also need a guest stress test IMO
16:54:47 <thingee> guitarzan: that really does exist for RGW :)
16:54:49 <kmartin> jgriffith: we can discuss in the session that's what we are working on
16:54:49 <JM1> bswartz: and people want to run such things on cloud storage?
16:55:03 <bswartz> JM1: absolultely
16:55:19 <DuncanT> So that people who *think* they've gotten it right can test at least some of the edge cases
16:55:19 <jgriffith> Sounds good... I've modified the description to include discuss R/W multi-attach
16:55:20 <guitarzan> folks definitely want multiattach (RW/clustered/whatever)
16:55:25 <JM1> bswartz: what kind of benefit does it give them?
16:55:34 <jgriffith> guitarzan: indeed
16:55:37 <hemna> DuncanT, we wrote some python stress tests to test out our drivers.  I'd like to eventually make it usable by others in cinder to stress test cinder itself.
16:55:45 <hemna> guitarzan, +1
16:55:59 <jgriffith> and I think we'll get there, but I'm wonderinf if it needs limits via things like Gluster plugin, NFS plugin etc
16:55:59 <DuncanT> JM1: Clustered FS in the cloud makes some types of HA really easy
16:56:02 <jgriffith> anyway....
16:56:10 <bswartz> JM1: the ability to run existing applications that rely on clustered filesystems and quorum disks (such as any Microsoft Clustering solution)
16:56:20 <jgriffith> #topic encryption
16:56:34 <guitarzan> thingee: rgw?
16:56:38 <jgriffith> So it doesn't seem like anybody else has been following the ML discussions on this
16:56:47 <jgriffith> but you REALLy need to take a look at this IMO
16:56:51 * bswartz has
16:56:57 <jgriffith> It has VERY serious implications for all of us
16:57:19 <bswartz> evil encryption is evil
16:57:22 <avishay> that sounds rather ominous
16:57:27 <guitarzan> all of the discussions sound very handwavy to me
16:57:31 * DuncanT is a bit behind, I assumed it would get properly hashed out at the summit - the way they are proposing to do it in nova is just broken, for usability and security
16:57:41 <jgriffith> DuncanT: don't assume :)
16:57:51 <avishay> I still don't understand the thread model
16:57:52 <DuncanT> Oh dear
16:57:56 * hemna waves hands
16:58:00 <jgriffith> So if folks are following this and have input, I'm a bit disappointed that I've been the only one objecting
16:58:12 <avishay> *threat model
16:58:14 <DuncanT> I objected to two reviews ont he subject
16:58:26 <jgriffith> DuncanT: indeed!  thanks for that BTW
16:58:33 <jgriffith> avishay: what do you mean?
16:58:38 <jgriffith> avishay: you mean why it's bad?
16:58:42 <hemna> which subject?  encryption? or multi-attach ?
16:58:43 <DuncanT> Discussing the implementation details on the mailing list is just painful
16:58:54 <jgriffith> DuncanT: that's very true...
16:59:01 <avishay> jgriffith: no, what they are trying to solve.  what is trusted?  what are they trying to protect against?
16:59:02 <jgriffith> So we have a session in Cinder and in Nova that should not overlap
16:59:06 <jgriffith> so we can all attend both
16:59:35 <jgriffith> avishay: https://wiki.openstack.org/wiki/VolumeEncryption
16:59:44 <DuncanT> I'm hoping to get our encryption guy to go to both too
17:00:00 <jgriffith> So encryption aside
17:00:10 <jgriffith> It take a key management piece out of Cinder
17:00:12 <thingee> avishay: the focus isn't exactly vendor centric. the fear is once we have something, no one would be working with it really. some backends might have their own solution to this already.
17:00:16 <dachary> before any kind of encryption can be implemented, there needs to be a way to store keys, which is missing.
17:00:20 <jgriffith> which I think is full of issues
17:00:34 <avishay> jgriffith: i've seen that, but it doesn't answer my question - it goes right into architecture without going into the threat model first
17:00:47 <jgriffith> The other thing is the fact that if you're device does things like encryption built-in or de-dup, or compression this could cause some unexpected behaviors
17:00:58 <jgriffith> avishay: they touch on it
17:01:14 <jgriffith> but regardless, I didn't write it so you're not going to get insight from me :)
17:01:17 <jgriffith> and we're out of time
17:01:39 <jgriffith> but I wanted to make sure folks were aware of this and that they look at the patch etc
17:01:56 <DuncanT> "There are some additional unknowns about how the encrypted device will  interact with other OpenStack features. For example,  exporting/snapshotting volumes and live migration will need to be  investigated"
17:01:57 <avishay> i'd like a summit topic on it and get it all sorted out
17:02:07 <jgriffith> think about implications, alternative implementations (ie same impl in Cinder) that the drivers can over-ride with their own impls
17:02:18 <jgriffith> avishay: as I just said, you've got two
17:02:31 <jgriffith> Ok...
17:02:32 <thingee> avishay: It's in the first paragraph of the intro
17:02:39 <thingee> thanks, bye!
17:02:40 <thingee> :)
17:02:47 <jgriffith> thanks everyone
17:02:54 <jgriffith> #endmeeting