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