20:59:23 <hub_cap> #startmeeting reddwarf
20:59:24 <openstack> Meeting started Tue Mar 26 20:59:23 2013 UTC.  The chair is hub_cap. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:59:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:59:27 <openstack> The meeting name has been set to 'reddwarf'
20:59:40 <robertmyers> hello
20:59:51 <datsun180b> hello hello
21:00:00 * hub_cap waits 2 min for stragglers
21:00:10 <datsun180b> we're still in a retro
21:00:16 <hub_cap> >>> time.sleep(120)
21:01:07 <djohnstone1> Hi
21:01:14 <vipul> hey
21:02:19 <hub_cap> #link https://wiki.openstack.org/wiki/Meetings/RedDwarfMeeting
21:02:22 <SlickNik> hey guys
21:02:23 <hub_cap> time to start!
21:02:25 <esp1> yo
21:02:38 <hub_cap> #link http://eavesdrop.openstack.org/meetings/reddwarf/2013/reddwarf.2013-03-19-21.02.html
21:02:46 <hub_cap> #topic Action Items
21:03:24 <juice> Howdy
21:03:27 <hub_cap> vipul: yer up (thought u were in a meeting)
21:03:37 <SlickNik> Vipul just getting back from a meeting.
21:03:49 <hub_cap> ahhhh getting back
21:03:52 <SlickNik> Skip him to the end of action items...
21:04:05 <hub_cap> kk
21:04:25 <hub_cap> im asking grapex about reddwarf lint integration
21:04:27 <hub_cap> hes on the phone w/ me
21:04:40 <hub_cap> he has not done that yet
21:04:49 <hub_cap> #action grapex to patch reddwarf with xml lint integration
21:05:13 <SlickNik> Sounds good.
21:05:17 <hub_cap> next is me
21:05:36 <hub_cap> #action hub_cap to talk to everyone about the actions stuff at the summit
21:05:41 <SlickNik> yes, instance_actions.
21:05:44 <hub_cap> we need to brainstorm on it, since its not fleshed out
21:05:48 <hub_cap> no longer instance_actions
21:05:48 <SlickNik> I'm looking forward to that one.
21:05:53 <hub_cap> DEFFFFFFF
21:05:57 <SlickNik> ah, name change gotcha.
21:06:03 <vipul> bakc
21:06:06 <vipul> back sorry
21:06:13 <hub_cap> vipul: you have a few action items
21:06:18 <SlickNik> wb, just going through action items.
21:06:38 <SlickNik> Mine are:
21:06:50 <hub_cap> SlickNik: go head w/ yours now, the regex one
21:06:57 <hub_cap> SlickNik to update the release wiki page with regexps for release/pre-release
21:07:00 <SlickNik> I updated the python-reddwarfclient release wiki page with the reg-exps.
21:07:10 <hub_cap> SWEET
21:07:17 <datsun180b> nice
21:07:34 <SlickNik> Also, got the redstack refactoring patch checked in (thanks for the reviews all).
21:07:39 <hub_cap> woot!
21:08:00 <hub_cap> vipul and robertmyers: action items about the notifications blueprint
21:08:05 <vipul> Ok so i updated the Backups spec to call everything Backups instaead of snapshots
21:08:13 <vipul> so #1 is done
21:08:22 <vipul> #2, I still need to submit a patch to database-api
21:08:22 <SlickNik> nice
21:08:32 <vipul> #action vipul to submit patch for Backups API to database-api
21:08:51 <vipul> hub_cap: the notifications one.. I have not filed the blueprint
21:08:58 <hub_cap> okey, want me to file vipul?
21:09:07 <vipul> yes, please or get me a dummy
21:09:22 <SlickNik> this is for usage/billing notifications?
21:09:23 <hub_cap> ya dummy only
21:09:32 <robertmyers> SlickNik: yes
21:09:43 <hub_cap> vipul: https://blueprints.launchpad.net/reddwarf/+spec/dummydummy
21:09:48 <vipul> (heart)
21:09:52 <vipul> damn that didn't work!
21:09:56 <hub_cap> hhaahah <3
21:09:58 <hub_cap> < 3
21:09:59 <SlickNik> <3
21:10:22 <vipul> cool, i'll file the BP
21:10:30 <vipul> will need robertmeyers input
21:10:37 <hub_cap> okey. lets go on
21:10:37 <robertmyers> sure
21:10:45 <hub_cap> i htink the first actual item is notifications
21:11:00 <hub_cap> #topic Reddwarf Notifications
21:11:11 <vipul> So i left that in the meeting agenda since we didnt make progress
21:11:14 <hub_cap> so we have a blueprint now, but its not really filed
21:11:34 <hub_cap> ok vipul, lets make sure robertmyers gives u templates
21:11:34 <vipul> I'd like to get clarity on the this one this week
21:11:36 <hub_cap> ;)
21:11:40 <hub_cap> vipul: def!
21:11:41 <vipul> so let's file the bp and fill out details
21:11:43 <vipul> cool
21:11:50 <hub_cap> just ping robertmyers on irc
21:11:55 <vipul> will do
21:11:57 <vipul> thanks!
21:12:22 <hub_cap> so movign on?
21:12:28 <imsplitbit> yep
21:12:28 <vipul> Yes, lets
21:12:34 <hub_cap> #topic Backups Discussion
21:12:40 <SlickNik> Sounds like it. More discussion on that to come later.
21:12:43 <hub_cap> lets start w/ restore API decision
21:12:51 <vipul> do we have a decision :)
21:12:55 <juice> drum roll
21:13:00 <hub_cap> give me context...?
21:13:04 <hub_cap> im a bit out of the loop
21:13:16 <vipul> restorePoint: { instanceID | backupID }
21:13:20 <hub_cap> AHHHHHH
21:13:25 <vipul> OR
21:13:25 <juice> well you and mr simps where going to work it out
21:13:28 <SlickNik> type or no type, I think...
21:13:33 <vipul> right
21:13:33 <SlickNik> that is the question
21:13:47 <hub_cap> we will _not_ be using instanceID for teh initial iteration
21:13:51 <hub_cap> we had a long convo about it
21:14:11 <hub_cap> it will _only_ be restorePoint {backupUUID, and eventually a Date}
21:14:30 <vipul> so the use case where the backupUUID is really old and the date is really new
21:14:34 <vipul> and there are other backups in between
21:14:52 <vipul> how will that be implemented
21:15:13 <hub_cap> well.... seems like that would be a failure case
21:15:23 <hub_cap> we arent going to roll w/ a date from the first iteration
21:15:30 <hub_cap> i think weve decided to go w/ the manual backup case first
21:15:33 <SlickNik> fair enough.
21:15:37 <vipul> ah ok
21:15:38 <hub_cap> and our impl will _not_ have a date
21:15:49 <SlickNik> Very similar to what we are planning then.
21:15:54 <hub_cap> and we will let you guys solve the xtra+binlogs+date thing ;)
21:15:57 <vipul> so the first iteration of this thing is similar to ours.. you restore to the backup and not point in time
21:16:02 <hub_cap> correct
21:16:26 <hub_cap> ya we will put both impls (xtra/mysqldump) in the public for reddwarf installations to decide
21:16:31 <juice> thanks for the vote of confidence hub_cap :)
21:16:32 <hub_cap> so we will need that stratregy pattern
21:16:40 <hub_cap> juice: :D
21:16:45 <vipul> we liked your approach in hindsight :(
21:16:58 <vipul> but i guess we roll with this first
21:17:01 <hub_cap> vipul: haha ya i know...
21:17:02 <SlickNik> I was looking at stevedore actually.
21:17:04 <hub_cap> i did too ;)
21:17:16 <juice> robertmeyers is still working on the stream to swift approach though
21:17:18 <hub_cap> but hey, simple is better
21:17:20 <SlickNik> They have a good driver model that we can use for the strategy/plugin approach.
21:17:31 <hub_cap> SlickNik: ya? hmmm that might be a good use for it
21:17:37 <hub_cap> assuming u can config it
21:17:47 <hub_cap> and that its not something thats compiled into the python egg
21:18:08 <robertmyers> stevedore is good
21:18:21 <vipul> ok so how about
21:18:37 <hub_cap> backup unique name constraints?
21:18:46 <vipul> restorePoint: { backupRef: http://dddd/backups/backupID }
21:19:02 <hub_cap> im ok w/ that, i dont think it matters too much
21:19:12 <vipul> we have a precedense (if that's how you spell it) for refs
21:19:22 <hub_cap> as long as u can just do { backupRef: backupID } shorthand
21:19:35 <juice> precedence I think
21:19:36 <vipul> yea we can write the parsing logic to accept either
21:19:36 <hub_cap> w/ the flavor/image calls u can just pass the ids
21:19:44 <hub_cap> well let me ask this
21:19:45 <vipul> thanks juice!
21:19:52 <hub_cap> do we _need_ the ref?
21:19:57 <hub_cap> what is the reason for it
21:20:22 <robertmyers> well, we want to eventually add the date
21:20:35 <hub_cap> robertmyers: i dont think that affects the imageref
21:20:42 <hub_cap> i mean ref vs uuid
21:20:47 <vipul> consistency
21:20:51 <hub_cap> refs are for things that could be non local
21:20:53 <vipul> flavorRef
21:21:09 <hub_cap> sure i get that
21:21:19 <juice> precedents actually
21:21:22 <hub_cap> but those are from a legacy system
21:21:25 <hub_cap> lol juice
21:21:41 <hub_cap> and technically flavorRef is just a uuid now
21:21:44 <hub_cap> and imageRef _is_ a url
21:21:49 <hub_cap> cuz it comes from a different system
21:21:59 <vipul> ah ok
21:22:03 <hub_cap> if backups were their own system (like glance) then id see the need for urls
21:22:07 <hub_cap> example http://docs.openstack.org/api/openstack-compute/2/content/CreateServers.html
21:22:16 <hub_cap> sorry for multi post
21:22:17 <hub_cap> "name" : "new-server-test",
21:22:17 <hub_cap> "imageRef" : "http://servers.api.openstack.org/1234/images/52415800-8b69-11e0-9b19-734f6f006e54",
21:22:17 <hub_cap> "flavorRef" : "52415800-8b69-11e0-9b19-734f1195ff37",
21:22:34 <vipul> k cool, let's go with ID then
21:22:50 <vipul> do we want to name it Ref but accept UUID?
21:22:55 <SlickNik> There's some value in being agnostic of which system resources came from and using a ref across the board, though.
21:22:57 <vipul> or just name it 'backupID'
21:23:22 <hub_cap> hmmmmmmmmm
21:23:35 <hub_cap> let me touch base w/ our resident rest guru
21:23:57 <vipul> ok i'm going with BackupRef and allow the value to be either URI or UUID
21:24:06 <vipul> and fi that doesn't fly with him we can change easily
21:24:14 <hub_cap> vipul: fine by me for now
21:24:21 <SlickNik> Yeah, this is not clearcut…fine by me for now as well.
21:24:37 <vipul> i'll update the wiki
21:24:38 <hub_cap> #action hub_cap to bring findings for backupRef vs backupUUID
21:24:56 <hub_cap> so robertmyers whats the latest on streaming backups / failure handling
21:25:23 <robertmyers> I got it mostly working... just trying to deal with large files
21:25:46 <robertmyers> over 5GB need to be split up
21:26:06 <vipul> do you keep a counter as you go?
21:26:08 <hub_cap> oh ya swift file size limitations
21:26:13 <robertmyers> so it is a little tricky to do that while you are streaming
21:26:14 <SlickNik> @robertmyers: eagerly awaiting your initial patch set upload. :)
21:26:23 <robertmyers> :)
21:26:26 <hub_cap> http://docs.openstack.org/developer/swift/overview_large_objects.html
21:26:44 <robertmyers> well, I think the first I'll put a gist up for all to see
21:26:58 <SlickNik> Yes, would love to see what the integration points are. Patch set upload can come later.
21:27:05 <hub_cap> robertmyers: perfect tahtd be great
21:27:13 <hub_cap> ill also find imsplitbit's original code
21:27:22 <juice> thanks for sharing and the effort robertmyers
21:27:39 <SlickNik> That would be awesome!  Thx robertmyers and hub_cap.
21:27:41 <robertmyers> you welcome
21:27:50 <robertmyers> your welcome
21:27:51 <vipul> the download use case.. is that something we're also doing directly?
21:27:51 <robertmyers> :)
21:27:59 <vipul> or is that something we should consider swiftclient for
21:28:02 <robertmyers> you're
21:28:03 <hub_cap> https://github.com/imsplitbit/cf_stream_uploader imsplitbit ?
21:28:16 <imsplitbit> https://github.com/imsplitbit/cf_stream_uploader
21:28:17 <imsplitbit> yep
21:28:23 <hub_cap> damn im good
21:28:26 <imsplitbit> DEF poc code
21:28:29 <hub_cap> robertmyers: have a look-see at this too https://github.com/imsplitbit/cf_stream_uploader/blob/master/cfstream.py
21:28:33 <imsplitbit> but should give you an idea
21:28:55 <hub_cap> thatd be like 3 lines in ruby imsplitbit
21:29:04 <robertmyers> nice
21:29:09 <SlickNik> nice, thanks!
21:29:11 <datsun180b> oh don't start that fight
21:29:16 <hub_cap> ok on to "backup unique name constraints"
21:29:21 <SlickNik> #link https://github.com/imsplitbit/cf_stream_uploader
21:29:23 <hub_cap> #link https://github.com/imsplitbit/cf_stream_uploader/blob/master/cfstream.py
21:29:26 <hub_cap> LOL
21:29:32 <vipul> no answer :(
21:29:34 <imsplitbit> datsun180b, it would...
21:29:41 <imsplitbit> :-)
21:29:47 <hub_cap> so annashen and i talked about the name stuff, and she has changed the code to be driven by uuid
21:29:55 <vipul> robermeyers: are you addressing the download use case as well?
21:29:57 <hub_cap> im not sure we have a answer on the uniequeness tho right vipul?
21:30:09 <hub_cap> vipul: thats a restore, totally different beast ;)
21:30:41 <robertmyers> vipul: download is handled by the swift manifest file
21:31:01 <vipul> ok, so swiftclient would work for that
21:31:10 <vipul> assuming that we'll write the manifest
21:31:10 <robertmyers> probably
21:31:12 <hub_cap> stream download shoudl be HELLA easy
21:31:16 <robertmyers> yes
21:31:20 <vipul> cool
21:31:32 <hub_cap> so do we have any reason for constraining the name of a backup?
21:31:41 <hub_cap> we dont currently constrain a instance name
21:31:43 <robertmyers> yes
21:31:49 <hub_cap> why robertmyers?
21:31:54 * hub_cap is curious
21:32:01 <robertmyers> if we use if for the swift name
21:32:01 <hub_cap> this is the user supplied name robertmyers
21:32:03 <vipul> actually why don't we constrain the instance name
21:32:05 <datsun180b> shelling out to do md5sums, for shame
21:32:09 <hub_cap> vipul: cuz nova doesnt
21:32:17 <vipul> hmm i thought it did
21:32:17 <hub_cap> datsun180b: POC
21:32:28 <hub_cap> nope cuz all my instances are name foo ;)
21:32:34 <SlickNik> You can have 2 instances with the same name in nova.
21:32:36 <datsun180b> yes of course, i'm only ribbing him because it's required
21:32:36 <vipul> maybe that's nova client behavior
21:32:46 <imsplitbit> lol
21:33:21 <vipul> actaully it's a good point.. what shoudl the object be named in swift
21:33:23 <SlickNik> perhaps, vipul, I think there _is_ a client check...
21:33:24 <hub_cap> vipul:  its display_name
21:33:33 <hub_cap> vipul: likely something date based
21:33:47 <imsplitbit> datsun180b, there was actually a reason for that.  the code had to run in minimal memory space and for some reason it was hitting a ceiling for memory so I shelled out and that solved that
21:33:50 <hub_cap> since when u start a snap, i assume we will be in a "backup" state
21:33:53 <vipul> so why have a name at all
21:34:01 <hub_cap> vipul: context
21:34:11 <hub_cap> same reason why give a name at all for instances
21:34:13 <hub_cap> a uuid is ugly
21:34:21 <hub_cap> gives a human something readable
21:34:31 <hub_cap> but by no means should we name them off that
21:34:38 <datsun180b> i figure md5 is probably compiled and being purpose-build for that is going to blow four lines of python out of the water
21:34:49 <datsun180b> i don't mean to distract
21:35:00 <vipul> swift object name = date + backup name? something like that?
21:35:13 <vipul> when they are browsing swift, is it iimportant to give the same context i guess
21:35:21 <SlickNik> Yes, I agree..
21:35:21 <hub_cap> why not backup uuid????
21:35:30 <hub_cap> since a uuid is uu
21:35:58 <robertmyers> sure, that would be easy to restore too
21:36:00 <hub_cap> last ting i want to see tho is naming it something like this, 祈票禁神祝-backup
21:36:07 <robertmyers> ha
21:36:08 <vipul> lol
21:36:09 <SlickNik> lol
21:36:14 <hub_cap> lolly pop
21:36:32 <vipul> fair nuff - the name should be optional then
21:36:38 <hub_cap> welllllll.....
21:36:46 <hub_cap> name is not optional
21:36:47 <vipul> if we are doing automated backups...
21:36:49 <hub_cap> its just not unieque
21:36:56 <vipul> who cares what the anme is if it's date based
21:36:59 <SlickNik> not optional but unique.
21:37:08 <hub_cap> lol SlickNik 1/2 right
21:37:13 <hub_cap> not optional, not unieuq
21:37:16 <hub_cap> man i cant type
21:37:32 <hub_cap> it will be _exactly_ the same as the way our /instances name works
21:37:32 <SlickNik> yeah, that's what I meant.. typed it out wrong :P
21:37:35 <hub_cap> hehe
21:37:36 <robertmyers> what if we want to add the ability to do a single table backup or single database
21:37:37 <vipul> what are we going to name the snapshots when we make it automated then
21:37:49 <hub_cap> vipul: we can figure that out when we go automated
21:37:57 <hub_cap> blahdb-backupdate? or something liek that?
21:38:21 <SlickNik> I still like putting the name in the backup file though (instead of the UUID)
21:38:29 <vipul> agree with SlickNik
21:38:39 <vipul> if we're using it for context in Reddwarf.. why not the same context in swift
21:38:49 <SlickNik> because these are exposed to the user.
21:38:54 <robertmyers> well, could that be part of the backup extention?
21:38:58 <hub_cap> well lets not assume that a user should be having context wrt that
21:39:09 <hub_cap> we have not defined that a user can/shoudl remove them
21:39:15 <hub_cap> so why make it easy for them to ;)
21:39:16 <SlickNik> because even 祈票禁神祝:01/29/2013:00:00:00 has some meaning to the user, whereas a UUID does not.
21:39:16 <robertmyers> seems easy enough to factor out
21:39:31 <vipul> well they'll see it anyway.. (assuming you're putting it in public swift)
21:39:36 <hub_cap> sure we are
21:39:45 <hub_cap> bye vipul :P
21:39:50 <hub_cap> he mustve hit the wrong key combo
21:40:00 <vipul> don't hit command + delete
21:40:00 <hub_cap> cmd-Q'ing us vipul?
21:40:05 <vipul> lol
21:40:07 <juice> The name is swift must be unique
21:40:17 <hub_cap> yup juice
21:40:34 <juice> And unless its some meta data the name is mostly what they'll see in swift
21:40:37 <robertmyers> well, mostly true, you just over write the existing file
21:40:39 <vipul> ok we need a 'naming_strategy.py' :)
21:40:45 <hub_cap> juice: thats a good idea actually
21:40:53 <hub_cap> put the name / description in the metadata
21:41:15 <hub_cap> lol vipul
21:41:21 <SlickNik> heh
21:41:43 <annashen> actually, you got a second shot for the name that appearing in swift container for an object
21:41:54 <hub_cap> what do yall htink of that? uuid for the filename, and name/desc in the metadata for the file
21:42:32 <juice> Sounds good
21:42:32 <annashen> i will just sit and watch for the finals
21:42:44 <vipul> hmm not too thrilled but i can live with it
21:42:52 <SlickNik> I'm okay with that as long as the metadata is readily available/apparent in the UI.
21:43:00 <hub_cap> The only restriction on object names is that they must be less than 1024 bytes in length after URL encoding. For example, an object name of C++final(v2).txt should be URL encoded as C%2B%2Bfinal%28v2%29.txt and therefore be 24 bytes in length rather than the expected 16.
21:43:22 <hub_cap> do we really want to ahve to take swift naming considerations into account?
21:43:50 <annashen> no..
21:43:58 <hub_cap> :D
21:43:58 <vipul> we can make that a configurable thing.. we're not using a private swift.. it's going into their public cloud swift..
21:44:07 <vipul> so it's visible.. which is why i bring it up
21:44:18 <hub_cap> sure, neither are we...
21:44:43 <vipul> so if it is visible and they will see it.. the context argument should apply to swift object name as well me thinks
21:44:49 <hub_cap> id rather make it less understandable for now
21:44:59 <vipul> which may mean they're more likely to delete it :(
21:44:59 <hub_cap> i dont want to deal w/ constancy between the systems
21:45:21 <hub_cap> ok crap a user named it incorrectly in our system, so they go rename it cuz they dont like the missspell in swift
21:45:44 <vipul> well yea i guess that could happen as well
21:46:09 <vipul> let's go with UUID.. and if we need to.. we can make that a configurable/pluggable thing
21:46:11 <hub_cap> simplicity = uuid / metadata for things that dont matter and arent unique (names...)
21:46:15 <hub_cap> for sure vipul
21:46:25 <vipul> at the end of the day the name doesn't matter to reddwarf.. but it may to the user
21:46:29 <juice> #agreed
21:46:42 <hub_cap> ya its all code, we can figure it out
21:46:45 <SlickNik> I can live with UUID and name/desc in the metadata for now.
21:46:52 <SlickNik> sounds good.
21:46:58 <SlickNik> #agreed even
21:46:59 <vipul> ok the failure handling thing
21:47:16 <vipul> i put that in the agenda.. to see how we want to handle the case where streamed upload fails
21:47:18 <hub_cap> all for siliently failing and sayign nothing to customers?
21:47:33 <robertmyers> sure
21:47:34 <hub_cap> :P
21:47:34 <vipul> do we want to retry? or just fail
21:47:39 <hub_cap> retry for sure
21:47:40 <SlickNik> aye :P
21:47:47 <hub_cap> we shoudl ahve retry logic for X (configurable) retries
21:47:57 <hub_cap> honestly each chunk is gonna potentially fail
21:48:02 <hub_cap> so we need to add retry there
21:48:16 <robertmyers> ideally we'll do MD5 checksuming durging the backup too
21:48:46 <vipul> does swift give you a md5 for every segment?
21:49:05 <SlickNik> Where do we store the checksum(s)?
21:49:05 <hub_cap> md5 at the end i think
21:49:07 <vipul> we can calcualte md5 on the stream .. for every segment.. and comapre?
21:49:14 <robertmyers> I think so
21:49:46 <hub_cap> also u can give swift the md5 and itll compare it to make sure its clean
21:49:48 <vipul> SlickNik: just in memory calculate on th efly
21:49:51 <vipul> the fly
21:49:52 <robertmyers> the api takes an etag
21:50:17 <SlickNik> no, I mean, we want to verify on restore right?
21:50:42 <robertmyers> yeah the download process coudl do that
21:50:43 <hub_cap> def on restore too
21:51:05 <vipul> probably another case we should consider.. swift probably has the md5 for that object as metadata or something?
21:51:05 <hub_cap> we will cross that bridge when we do restores :D
21:51:24 <robertmyers> vipul:  it is the ETAG header
21:51:26 <vipul> we're working on that portion as well hub_cap
21:51:59 <hub_cap> oh nice as one shabang vipul?
21:52:16 <vipul> robermeyers: ok so it's going to be there for us
21:52:28 <vipul> hub_cap: yea in parallel i suppose
21:52:31 <hub_cap> SWEET
21:53:04 <SlickNik> gotcha robermyers.
21:53:06 <hub_cap> ok so do we feel comfortable w/ backup/restore now? should we move on?
21:53:11 <vipul> robermeyers: so there may be one use case.. where the user could potentially replace the segments
21:53:22 <vipul> and the md5 would be changed
21:53:45 <hub_cap> i think they would have to change the manifest too right robertmyers?
21:53:45 <robertmyers> well then that is their fault :)
21:53:52 <SlickNik> Well, we need to figure what are we using the md5 for.
21:54:03 <vipul> do we even want to consider that?  i guess the option would be to manually store the md5 of the entire thing somewhere
21:54:07 <robertmyers> yes, you can upload a new manifest
21:54:16 <SlickNik> If it's 1. to check data integrity, then it's fine to use the ETAG header.
21:54:54 <SlickNik> 2. If we're worried about security where someone can swap out the backup and change the MD5 if they have access to Swift. Then:
21:55:18 <SlickNik> a. We need to not use MD5 and use something more cryptographically secure
21:55:42 <SlickNik> b. We need to have a place to persist said hash
21:55:56 <vipul> SlickNik: Yea was just thinking in our db table
21:56:00 <vipul> but maybe that's an enhancement
21:56:02 <hub_cap> or throw up hands for now :)
21:56:13 <imsplitbit> yah the poc code used md5 just because it was cheap and there.  def need to use something better
21:56:13 <hub_cap> vipul: +1 to enhancement
21:56:14 <SlickNik> I like this guy ^^^ <3
21:56:36 <juice> Lets make it work then we can make it better then
21:56:38 <SlickNik> I'm all for staying simple now and enhancing later.
21:56:40 <hub_cap> lets make it more secure when a user actually goes and does that
21:56:42 <vipul> yup
21:56:43 <robertmyers> well in order to do anything more fancy, i don't think you can stream it
21:57:04 <vipul> you could encrypt as you stream so it is still an option
21:57:11 <hub_cap> yup
21:57:22 <hub_cap> we good? moving on?
21:57:24 <vipul> ye
21:57:25 <vipul> s
21:57:27 <robertmyers> yes
21:57:27 <imsplitbit> yep
21:57:30 <hub_cap> #topic Unmanaged mode (enable root) security considerations
21:57:31 <SlickNik> sounds good to me.
21:57:34 <hub_cap> not sure what this one is all about
21:57:42 <vipul> ok this one is when we enable root
21:57:55 <vipul> do we want to consider making this thing truly unmanaged
21:58:04 <vipul> so delete guest-agent.conf
21:58:14 <vipul> the thinking is.. as root they could potentially do destructive things
21:58:23 <vipul> and if they got a hold of the conf file
21:58:23 <hub_cap> _could_
21:58:33 <vipul> then they could get to DB, and whatever else
21:58:40 <vipul> so wanted to throw that out ther
21:58:42 <hub_cap> get a hold of the conf file?
21:58:49 <hub_cap> like using read infile?
21:58:55 <vipul> that
21:59:03 <vipul> which we could disable i guess
21:59:12 <hub_cap> or just make the user diff for that conf file
21:59:28 <hub_cap> they cant really get access to the shell unless mysql is compromised
21:59:30 <vipul> yea.. that's an option as well
21:59:45 <vipul> which i hear is easy to do from some of hte folks here..
21:59:55 <vipul> but besides that..
21:59:58 <hub_cap> to root mysql?
22:00:00 <vipul> we're not truly unmanged
22:00:08 <hub_cap> well they sux for not telling mysql ;)
22:00:16 <hub_cap> we dont want to be unmanaged
22:00:23 <vipul> since we can still support api operations
22:00:24 <hub_cap> we allow users to get root mysql today
22:00:27 <hub_cap> exactly
22:00:31 <hub_cap> if shit fails, we have no SLA
22:00:54 <hub_cap> but we will still give it the old college try
22:01:39 <hub_cap> soudn good vipul and co?
22:01:43 <vipul> right.. this probably needs more thought.. wanted to run it by you guys first
22:02:03 <vipul> it's fine as it is for now.. i'll confirm with our security guys
22:02:07 <hub_cap> im fine w/ more thought for sure
22:02:10 <hub_cap> ya def
22:02:18 <hub_cap> if they have insight id love to hear it
22:02:26 <SlickNik> so is the option then to lock down the mysql access account in the guest agent conf file?
22:02:28 <hub_cap> we effectively dont allow mysql to read the guest file
22:02:41 <vipul> yea that would probably work for now
22:02:47 <hub_cap> by using a different username
22:02:53 <vipul> or what managed / unamanaged means in general
22:02:57 <hub_cap> till my.cnf edits come out possibley vipul :P
22:03:08 <hub_cap> err a diff set of perms, not diff username (same diff...)
22:03:16 <SlickNik> Ah, okay.
22:03:23 <vipul> i gotta hard stop.. i'll discuss this later
22:03:28 <vipul> sorry gotta go to another meeting
22:03:59 <hub_cap> l8r vipul
22:04:09 <SlickNik> later vipul
22:04:17 <hub_cap> ok so if no more Qs we can go to freeforall discuss
22:04:20 <SlickNik> We've covered most of the agenda any way.
22:04:27 <hub_cap> yup
22:04:28 <SlickNik> I'm good.
22:04:30 <hub_cap> #topic Open Discussion
22:04:37 <hub_cap> anyone have anythign to add?
22:04:47 <SlickNik> Since we almost started a ruby vs python flame war...
22:05:02 <SlickNik> I'd like to draw your attention to this:
22:05:08 <juice> I'm good
22:05:11 <SlickNik> http://www.rackspace.com/blog/text-editor-madness-bracket-vote-for-your-favorite/
22:05:13 <juice> Ttyl
22:05:24 <SlickNik> But that's all I had. :)
22:05:28 <hub_cap> LOL SlickNik
22:05:59 <datsun180b> Everyone is entitled to their own opinion about the best text editor
22:06:09 <SlickNik> lol, I'm not saying anything.
22:06:20 <datsun180b> But that's the great thing about facts, you don't have to believe a fact for it to be true
22:06:35 <SlickNik> true that datsun180b
22:06:37 <hub_cap> okey w/ that ill end this, cuz datsun180b is likely standing and screaming
22:06:40 <hub_cap> #endmeeting