21:02:04 #startmeeting reddwarf 21:02:05 Meeting started Tue Mar 19 21:02:04 2013 UTC. The chair is vipuls|away. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:02:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:02:09 The meeting name has been set to 'reddwarf' 21:02:10 hi 21:02:12 #link https://wiki.openstack.org/wiki/Meetings/RedDwarfMeeting 21:02:16 Agenda for today ^^ 21:02:52 we'll wait another min for people to trickle in 21:03:13 vipul you are still set to away 21:03:22 oh crap 21:03:25 this damn linkinus 21:03:45 better 21:03:59 ok let's start 21:04:04 #link http://eavesdrop.openstack.org/meetings/reddwarf/2013/reddwarf.2013-03-05-21.59.html 21:04:09 recap from last meeting ^^ 21:04:26 phew... 21:04:27 here 21:04:30 http://eavesdrop.openstack.org/meetings/reddwarf/2013/reddwarf.2013-03-12-21.01.html 21:05:05 #action Vipul to update snapshot wiki with outcome of ongoing backup vs snapshot discussions 21:05:14 next item.. 21:05:18 SlickNik: security gruops? 21:05:36 Implementation of Security Groups is done. 21:05:52 And I have the code-reviews out on gerrit. 21:06:11 The server side one is failing the Jenkins tests cause the client side changes aren't in yet.. 21:06:17 one sec…let me get the links.. 21:06:19 grapex, cp16net: can you guys take a look when you get a chance? 21:06:36 vipuls: Sure. 21:06:54 #link https://review.openstack.org/#/c/24511/ (Client Side Security Groups Changes) 21:07:01 thanks SlickNik 21:07:09 I have the next item still TODO 21:07:17 #action vipul to upload snapshots API to database-api 21:07:25 next item.. 21:07:25 #link https://review.openstack.org/#/c/23161/ (Added support for Security Groups via a new extension. (Server-side)) 21:07:35 up 21:07:37 sup* 21:07:43 oh yeah sorry 21:07:49 lol ^ 21:07:59 Yes, would appreciate you guys taking a look! Thanks! 21:08:04 SlickNik: any update on the redstack trim? 21:08:08 my typing is terrible today 21:08:22 * cp16net needs to take a typing tutor class... 21:08:32 they still have those? 21:08:46 Just got done with the redstack trim this morning, so I'm in the process of testing it out. 21:08:59 Expect a review for it by this evening 21:09:03 awesome! 21:09:19 grapex: yer up.. 21:09:28 Want to make sure I test it well since it's a bunch of bash refactoring. 21:09:34 #action Grapex to check if he learned action. 21:09:39 D'oh! 21:09:43 yay! :) 21:09:49 lol 21:09:50 grapex: http://eavesdrop.openstack.org/meetings/reddwarf/2013/reddwarf.2013-03-12-21.01.html 21:09:51 lol 21:09:56 you're on the wrong one maybe 21:10:02 grapex: xml validation 21:10:07 Oh yeah! 21:10:15 I had a ton of success there 21:10:38 I was able to hook into XML lint fairly easily and only need to make this a non-obtrusive pull request to Reddwarf 21:10:52 cool... 21:11:04 #action grapex to patch reddwarf with xml lint integration 21:11:05 What I'm thinking is I'll just add some test configuration options that, if present, will tell it to call xmllint each time a request or response body is sent through the client 21:11:34 I can pipe it into the xmllint process's stdin and xmllint is pretty good about giving non-zero return codes if anything is wrong 21:11:37 yea that would be cool.. what about just plain xsd validation? 21:11:43 That's an option too 21:11:45 does it do that? 21:11:52 you give it a --schema option 21:11:57 nice 21:11:59 so I've been able to use it for the Rackspace docs schema 21:12:01 however 21:12:07 I've gotten back errors for nearly every call 21:12:10 heh 21:12:28 which given how complicated XML schemas are and the fact this was never validated before might just be all be valid errors 21:12:35 or it could be some finicky thing I'm doing wrong 21:12:38 Anyway 21:12:43 maybe schema is out of date 21:13:16 I can do one pull request with all these feautes, but they'll be turned off. If we want to actually run xmllint we'll need to probably do that in the real mode tests later since we'll have more control of dependencies on the VM. 21:13:31 ok cool look forward to it 21:13:36 thats awesome grapex 21:13:38 We could run them with tox but xmllint would have to be available on the ci VMs. 21:13:48 we will see the xsd in action! 21:13:52 Cool, I'll get that make that PR soon then. 21:14:00 That's awesome grapex. 21:14:10 next item was hub_cap schooling us on instance_actions 21:14:11 I think running them with the real mode tests makes sense. 21:14:16 we never did get a chance to do that 21:14:24 ah, yes. 21:14:24 By the way 21:14:46 In Reddwarf-Integration, you may have noticed that "example" directory under tests 21:15:17 I got that working in Rackspace recently - it was easier to set everything up, but going forward if we want to generate / validate example snippets for the OpenStack docs it's an option 21:15:41 It's another can of worms so we don't need to discuss it this meeting, but I just want to make everyone aware that it's totally doable 21:16:02 I was able to hook it into the super fake mode used by Reddwarf when it runs with tox so the examples generate in one second. 21:16:04 so it geneartes things we can add to docs? 21:16:08 Yes 21:16:26 I know the StackForge docs are in formation now, so maybe this is a conversation for later 21:16:34 that would be a nice add to the new docs 21:16:37 but its very doable 21:16:46 yea we should try to auto-gen as much as we can 21:16:50 I'm not entirely sure what that is/how it works. I can chat with you about it later, grapex. 21:17:04 the big trick is figuring out where everything lives, since there's several repos involved when I do it for Rackspace. 21:17:13 SlickNik: Ok. 21:17:15 CI also has hooks in Jenkins to run doc jobs, so I wonder if we can set it up with that. 21:17:43 #action hub_cap to school us on instance_actions and how they could be used elsewhere 21:17:50 :D 21:18:09 ok next item was for annashen.. 21:18:15 they are getting close to done moving but itll be ahr still... so school next wk :) 21:18:15 who may not be online yet.. 21:18:26 hub_cap: anytime 21:18:56 i'll do the update for annashen, she's got a more complete patch up of the migration.. 21:19:07 may still need some tweaks, but reviews appreciated 21:19:30 next item was for me.. to update python-reddwarfclient with oslo setup.py so we don't have to hard-code version 21:19:46 i was told to wait for a fix that was in flight by mordred 21:20:16 #action vipul to port setup.py from oslo to python-reddwarf client to version no longer hard-coded 21:20:44 I missed my next action item, so I'm going to do it as soon as this meeting is over. 21:20:55 #action SlickNik to update the release wiki page with regexps for release/pre-release 21:20:59 great! then we're done! 21:21:13 #topic Quota issues 21:21:22 oh damn.. 21:21:33 my vipul|away nick started the meeting 21:21:46 lol 21:21:51 #topic Quota Issues 21:21:57 no, really…he's not away. :) 21:22:09 hub_cap, esp1 you guys wanted to talk about this? 21:22:18 eh, sure 21:22:35 esmute and I are still working out some stuff with the int-tests 21:22:43 should have something by tomorrow. 21:23:08 lol vipuls|away 21:23:54 ok anything else we need to discuss on quotas, hub_cap? 21:24:18 going once.. 21:24:44 #topic Limits Update 21:24:59 Anything to discuss around Limits 21:25:11 I think we're done with this and all merged 21:25:32 I think so too. Nothing to discuss from my side. 21:25:46 grapex/hub_cap? 21:26:16 We're good 21:26:23 #topic Security Groups Update 21:26:29 I was really glad to see that got simplified, so good job again. 21:26:41 yep, thanks esp 21:26:46 It wasn't bad before, but it was nice to see the code shrink. 21:27:04 Not much other than what I said before. 21:27:17 vipul: yep 21:27:38 Both patches are on gerrit for review, so take a look and I would appreciate comments/feedback. 21:27:46 SlickNik: cool thanks! 21:27:58 SlickNik: I'll try to get to it soon. 21:28:08 Cool, thanks grapex. 21:28:10 #topic Reddwarf Notifications (metering events) 21:28:21 vipuls|away: sry just barely checking the meeting, im fine 21:28:31 robertmyers: should know more on notifications 21:28:32 I was hopign to get some discussion going around notifications in reddwarf 21:28:51 we're looking at adding some code in to basically meter usage of reddwarf resources 21:28:57 using something similar to nova-notifications 21:29:00 we have them working on our private code 21:29:13 using the oslo notifications 21:29:20 robertmeyers: anything you can share about that? like message format, etc 21:29:31 Yeah, we wanted to discuss that with you guys. 21:29:36 robertmeyers: and any plan to push up to trunk? 21:29:41 we need to start a blueprint or wiki page 21:29:47 yes 21:29:55 +10000 21:30:29 we've got some requirements internally and they'd like to agree on format 21:30:41 i'd rather present a format than adopting what they have specified we 21:30:43 so we dont' diverge 21:30:59 +1 to not diverging. 21:31:01 any estimate on when? I can start the bluepritn on it, if you can help add some content 21:31:20 sure, I can add what we have 21:31:36 cool, thanks robertmeyers! 21:31:46 basically the format is json and you can add any fields you want 21:31:48 #action vipul to file blueprint on reddwarf-notifications 21:31:59 right, i guess i meant what do the messages look like 21:32:03 like the structure of the json 21:32:04 so we just need to make sure we have all the data we need 21:32:48 I can add that to the wiki or blue print with examples 21:32:57 and also are you guys relying on other components to give you some notifications? or is everything around instances/volumes/etc emitted from reddwarf 21:33:00 easier than reading here 21:33:02 vs say like cinder emitting volume info 21:33:07 yep agree 21:33:22 ok i'll bug you on #redddwarf once i get something basic up 21:33:25 vipul: It's emitted from Reddwarf 21:33:39 all our notifications are comming from taskmanager currently 21:34:04 grapex, robermeyers: cool that's probably what makes the most sense.. 21:34:19 there are some corner cases where nova events may need to be used.. like say an instance crashes 21:34:23 and reddwarf doesn't know about it 21:34:29 so we'll need to work through that 21:34:35 you can listen on multiple hosts too 21:34:50 vipul: Ultimately when notifications and events get more mature it would be very nice to "listen" to them from Reddwarf somehow, if that was universally possible 21:35:16 grapex: Yep that would be great to have reddwarf be reactive to nova events 21:35:59 Yes, that would be very cool if we could actively do something on say an instance crash… 21:36:14 #action robermeyers to help define the events in the blueprint 21:36:17 Maybe they could get piped into Marconi or something, that'd be pretty cool. Or if we didn't have to poll and take naps when we created a server but just got notified when it was ready. 21:36:47 yep 21:37:24 ok cool.. then we'll check up on this next week 21:37:30 by marconi you mean macaroni? 21:37:31 :-P 21:37:50 lol cp16net - actually i don't know if there is much code in place for that project yet 21:37:55 still early stages 21:38:02 cp16net: It should've been macaroon, those are delicious 21:38:05 needs to boil a little 21:38:21 #topic Snapshots vs Backups 21:38:36 let's try to capture what we've been discussing on email threads 21:38:45 you'd prefer the resource be called /backups 21:38:56 +1 21:39:14 vipuls: Yeah, I think so 21:39:26 I think we can live with that.. no attachment to snapshots 21:39:34 It could of course list snapshots 21:39:49 so can you enumerate the types of backups? 21:39:54 but if we ever figure out a way to also back up bin logs and stuff, it could list those too, maybe with slightly different fields 21:40:22 Maybe I'm being shortsighted on this-its hard to figure out how the API should look to stay flexible, but it feels like all it really needs is a "type" field 21:41:08 where type = snapshots | mysqldump | binlog | etc? 21:41:13 So you'd get a list of "backups" and just check "type" to determine if it had certain fields... although this may violate REST laws. I'm not sure how inheritance is handled with REST resources. 21:41:15 Yes 21:41:51 We could add a query parameter to only get back certain types 21:42:12 we may need to research that something like doesn't violate any OpenStack standards 21:42:14 I would prefer the sub-attributes 'type', 'href' remain fixed 21:42:37 and we don't dynamically add / remove attributes based on the type 21:43:14 vipuls: I can see how dynamically adding or removing attributes might be a violation of REST 21:43:34 so when creating a 'backup' do you need to specify the type? 21:43:51 Maybe the href could point to other resource types, so if we really felt extra info was necessary, we could list them there. 21:44:08 vipul: Yes 21:44:25 does that feel like we're exposing too much of the low-level implementation to the user? 21:44:43 should they care whether they get mysqldump as a backup vs a lvm snapshot vs xtrabackup? 21:44:45 we would also need to have an optional field for a date to restore from 21:45:04 vipul: Maybe they would, if for example they wanted a mysqldump for absolute portability 21:45:24 Or lets say they wanted to restore using a random file they uploaded to swift 21:45:34 then they'd need to give us the type so we'd know how to handle it. 21:45:45 grapex: yea I think the bring-your-own side of it makes sense.. 21:46:06 The other issue is if you're dealing with a random file you uploaded to swift, let's say its xtrabackup 21:46:18 then you make a snapshot, and you can list it, and its using xtrabackup 21:46:44 those are both the same type of thing but also a bit different, in that in one case the Reddwarf API will have info on when you made that backup, the time, the instance ID it came from, etc 21:47:19 So that's why I a "format" field might make sense- the type then might be "swift" or "snapshot", and format would be "mysqldump" or "xtrabackup" 21:47:56 So in the case of a snapshot the user could specify a Reddwarf backup resource URL for the href instead of one from swift 21:48:07 i like format to specify mysqldump | xtrabackup | etc 21:48:21 but even the xtrabackup may end up in swift 21:48:36 so at that point does it get confusing when they are specifying snapshot as a type vs swift 21:49:44 I think our plan is to put the files in the users Cloud Files container, but what if a provider had only a limited swift deployment and wanted to put all the snapshots in one super users container or something, in that case they might only want their users to specify what to backup from using Reddwarf Backup URLs and not swift urls directly 21:49:53 Do we want to support any other "format" other than swift? 21:50:12 SlickNik: Exactly. mordred had that idea about backing up to volumes 21:50:39 we're not going to do that, but if the type could mean the href was a resource other than swift it could be possible. 21:50:51 so it we have two abstractions the format or backup mechanism and the storage 21:51:10 sounds rather straightforward 21:51:14 so i think we can do it with 'format' + 'ref' (type is unnecessary) 21:51:19 juice: yes, I think so. Type = backup mechanism (swift directly, via Reddwarf) and then format is the actual file type 21:51:30 except type is now 'format' 21:51:53 format = xtrabackup | mysqldump 21:52:04 ref = 'uri to snapshot' | 'uri to swift' 21:52:13 does that not suffice? 21:52:23 vipuls|away - I think that makes sense 21:52:36 let's keep the two concerns separate 21:52:39 vipul: Maybe. It would mean we'd have to, in reddwarf, parse the URI to determine if it was a swift uri or a snapshot one 21:52:45 that sounds good 21:52:53 right.. i think URI should be meaningful 21:53:07 if we had a dedicated 'type" it might be easier. I worry the URI alone might make it too hard to make it extensible later. 21:53:15 so if it's a /backup resource.. we assume we have a record 21:53:43 hmm... 21:54:16 like /backup/1/restore ? 21:54:48 i guess i meant the ref would = 'http://localhost:8779/v1/tenant/backup/backup_id' 21:54:58 and that would signify an entry in our DB 21:55:00 I think that makes sense. 21:55:01 vs.. 21:55:20 http://cloudfiles.rax|hpcloud.com/container/object 21:55:22 and the meta data format, ref would be associated to the entry yes? 21:55:56 where is the whiteboard in this chat? 21:56:04 seriously :) 21:56:08 heh 21:56:12 Maybe we should have a video conference for this 21:56:20 google hangout ? 21:56:28 +1 21:56:32 i'd like to get this sorted out 21:56:36 robertmyers: We could try that. 21:56:47 +1, google hangout/skype/whatever. 21:56:48 we can do skype or g+ 21:56:50 google hangout would work just find 21:56:58 s/find/fine 21:57:09 what about minutes 21:57:20 I have to call makeup and wardrobe 21:57:20 the date? 21:57:22 you can record them 21:57:28 i see 21:57:30 oh 21:57:44 can we pounce on this tmw morning? 21:57:57 what time works good for you guys robertmeyers, grapex? 21:58:02 juice: Sure, I'll email all parties concerned 21:58:04 early afternoon austin time 21:58:21 id lke to be part of said chat/email 21:59:09 1pm CST works for me 21:59:21 or is it CDT 21:59:22 that works for me too 21:59:29 I'd really like it if Daniel Morris go on it, he's the malcontent who started us down this path. :) 21:59:49 that's 11PDT? 21:59:52 should have known :) 21:59:55 He's schedule is pretty packed, looks like he's free at 2:00 your time 22:00:06 i'm ok with that as well 22:00:42 1400PDT works fine with me as well. 22:01:15 SlickNik: Cool 22:01:21 ok couple of other things that we've been whiteboarding re snapshots 22:01:27 Is everyone looking good for 1400PDT? 22:01:56 sea-crew is good 22:02:03 yup 22:02:11 representin' da 206 22:02:19 west-side! 22:02:29 \/\/ 22:02:33 hehe 22:02:36 nice 22:02:38 heh 22:03:23 anyway.. in the create snapshot scenario.. xtrabackup needs to ensure enough free space 22:03:36 so the idea was to create and attach a temporary volume 22:04:00 for the purposes of backing up the data and detaching after upload to swfit 22:04:43 we can share some white-board activity diagrams w/you guys before the conference call if needed 22:05:38 Could we make that optional? 22:06:16 yes, we can make that flag driven -- but the other option would be backup to root partition or something 22:06:57 do you guys have thoughts on other ways to do this? 22:07:11 And we can't really guarantee that the root partition would be big enough/wouldn't impact performance…. 22:08:44 We've been thinking about the same thing- how to make sure backups don't eat into existing resources. I'm not sure where we've landed yet. 22:09:20 ok we'll go over our plan, we can discuss if there is pushback 22:09:50 ok anything else ? 22:10:39 #topic Open Discussion 22:10:44 nope, not from my side. 22:11:03 last call 22:11:13 things got quiet 22:11:19 think we're good 22:11:35 ok grapex: we'll wait for your invite 22:11:40 i think that's a wrap then 22:11:48 Sounds good. Thanks all... 22:11:48 vipul: I'll be sending it soon! 22:12:02 #endmeeting