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