21:04:18 <vipul> #startmeeting reddwarf
21:04:19 <openstack> Meeting started Tue Jun  4 21:04:18 2013 UTC.  The chair is vipul. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:04:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:04:22 <openstack> The meeting name has been set to 'reddwarf'
21:04:31 <vipul> #topic action items
21:04:37 <vipul> #link http://eavesdrop.openstack.org/meetings/reddwarf/2013/reddwarf.2013-05-21-21.04.html
21:04:56 <vipul> I missed this meeting, but looks like we didn't how a whole to actioned
21:05:03 <vipul> ugh can't type
21:05:07 <vipul> whole lot actioned
21:05:21 <vipul> esmute: any update on log archiving rdjenkins?
21:05:31 <grapex> vipul: Wow that is a seriously show list of action items
21:05:44 <grapex> *short
21:05:58 <imsplitbit> grapex: we're all done
21:06:04 <imsplitbit> :)
21:06:17 <grapex> Great meeting everyone!
21:06:26 <datsun180b> A new record!
21:06:41 <esmute> vipul: Havent got on it yet :-(
21:06:57 <vipul> #action esmute to work with SlickNik to get rdjenkins logs archived
21:07:01 <esp> hey
21:07:07 <esp> did I miss it?
21:07:08 <vipul> straggler
21:07:09 <esmute> I guess i will have to give that task back to SlickNik
21:07:31 <vipul> #topic Next meeting time
21:07:34 <vipul> #link https://wiki.openstack.org/wiki/Meetings/RedDwarfMeeting
21:07:36 <vipul> agenda ^^
21:07:51 <vipul> Ok, it seems like we want to discuss an alternate meeting time?
21:08:10 <datsun180b> so we're solid that we're meeting at 2pdt/4cdt?
21:08:14 <imsplitbit> WEWT!
21:08:32 <imsplitbit> are we solid on that time?
21:08:40 <imsplitbit> I don't remember what times were discussed
21:08:44 <vipul> are folks ok with this time?
21:08:44 <juice> 11/1
21:08:48 <vipul> or we we want to change it
21:08:50 <grapex> Originally we wanted to move the time to earlier
21:08:54 <grapex> For everyone in CDT
21:08:55 <juice> 1/3
21:08:56 <cp16net> yeah
21:08:59 <datsun180b> that's what i want to know, there was some confusion
21:09:00 <cp16net> that would be nice
21:09:03 <imsplitbit> yeah I think juice had it 11/1
21:09:04 <grapex> but the issue is hub_cap has conflicts with that an OpenStack meetings
21:09:04 <hub_cap> heyo
21:09:13 <imsplitbit> oh
21:09:18 <imsplitbit> who's hub_cap?
21:09:19 <vipul> #link https://wiki.openstack.org/wiki/Meetings
21:09:21 <hub_cap> imma create a doodle
21:09:27 <juice> that's about the only time slots that would realistically work
21:09:27 <hub_cap> http://www.doodle.com/
21:09:38 <vipul> do we wanna pick another day?
21:09:40 <hub_cap> #action hub_cap to create a doodle for meeting times (http://www.doodle.com/)
21:09:44 <hub_cap> yes vipul
21:09:48 <hub_cap> ill doodle up some times
21:09:54 <vipul> nice
21:10:01 <imsplitbit> doodle away
21:10:29 <vipul> #topic Backup Validation
21:10:34 <juice> we have stand ups at 10:30 pst
21:10:43 <hub_cap> ok juice i wont put it around that time
21:10:45 <juice> backup validation did we kill this one earlier
21:10:52 <imsplitbit> I'm fine with 5am/7am
21:10:57 <imsplitbit> :)
21:11:04 <vipul> you might be the only one here :)
21:11:13 <juice> backup validation - store disk util in reddwarf
21:11:32 <juice> validate volume size is equal to or greater than that value stored in the backup db
21:11:36 <vipul> juice: do we store zipped size currently or acutal?
21:11:39 <juice> …on instance create
21:11:52 <juice> we will need to store actual size
21:12:04 <juice> not sure what value storing zipped size gets us
21:12:09 <vipul> ok i thought there was something in metadata about the size today
21:12:29 <vipul> right we need to store actual
21:12:29 <hub_cap> vipul: ive updated the wiki plz refresh at your convienence
21:12:35 <juice> there probably is but we will capture the actual size separately
21:12:39 <vipul> hub_cap: done
21:12:45 <hub_cap> <3<3
21:12:49 <vipul> juice: ok sounds good
21:13:03 <vipul> so do we consider the backups-api patch good to merge then?
21:13:08 <vipul> since this shouldn't hold that up
21:13:12 <juice> its' already merged
21:13:17 <juice> this is an enhancement
21:13:19 <vipul> w00t.. even better
21:13:27 <juice> a new blue print created by mr hub_cap
21:13:38 <vipul> ok cool
21:13:39 <vipul> moving on then
21:13:44 <juice> the backup api documentation should be merged
21:13:54 <vipul> #topic Notifications - Exists event
21:13:56 <juice> I don't see a reason throwing out the bathwater with the baby
21:14:12 <vipul> juice: you want to discuss updates on this one?
21:14:25 <hub_cap> :D im the blueprint ghostwriter
21:14:42 <juice> yes - just want to clarify on the previous topic that the documentation as is
21:14:50 <juice> is good enough for now
21:15:07 <juice> and when we add the validation we will put a note about the error in the documentation
21:15:19 <robertmyers> juice: yes, that is the plan
21:15:27 <juice> thanks robertmyers
21:15:31 <juice> so onto exists
21:15:45 <juice> We are working on getting this merged
21:15:57 <juice> I had a few good comments from grapex and cp16net
21:16:03 <juice> those are in the latest patch set
21:16:09 <vipul> hub_cap: refresh agenda when you get a chance
21:16:21 <juice> we are doing some testing here in our pre-prod env
21:16:22 <hub_cap> coo
21:16:53 <juice> not sure if there are any outstanding questions/feedback on that one
21:17:20 <juice> anyone?  anyone?  (in my ferris bueller teacher voice)
21:17:45 <vipul> ok looks like we're good on that
21:17:50 <vipul> #topic Heat Update
21:17:55 <hub_cap> hey thats me
21:17:58 <vipul> go for it
21:18:10 <hub_cap> so heat will be a very nice add, from what i gather
21:18:33 <hub_cap> im currently hacking away at a custom template for deb based installs that will set passwd and eventaully install guest
21:18:56 <grapex> cdb-scd
21:18:58 <hub_cap> it was a bit rough to get started but i understand how heat works now
21:19:01 <cp16net> im out, peace
21:19:10 <juice> l8r
21:19:24 <vipul> grapex: confused
21:19:31 <imsplitbit> bai
21:19:32 <hub_cap> and heat is in a place that we can use it now, it pretty good as it stands
21:19:41 <hub_cap> vipul: grapex likes saying random shit
21:20:00 <grapex> vipul: Hai guys my Mac is stuttering like the '80's Cinemax mascot
21:20:02 <vipul> lol i figured as much
21:20:04 <hub_cap> so thats all i have now. ill have a template for real in a day or 2
21:20:16 <hub_cap> grapex: max headroom?
21:20:18 <vipul> hub_cap: so does that make our image minimal?
21:20:32 <hub_cap> vipul: it makes us able to run any uec image
21:20:41 <hub_cap> so the imagebuilder stuff becomes a moot point i think
21:20:54 <vipul> we may want to still do that since install on the fly will slow boot
21:20:59 <hub_cap> i might be speaking too soon since im using the imagebuilder's image to upload
21:21:11 <hub_cap> well it downloads a uec image vipul
21:21:25 <hub_cap> so we can just do the same thing it does, cache 1x and use
21:21:37 <hub_cap> but again im not 100% sure yet
21:21:39 <hub_cap> more to come in the future
21:21:51 <imsplitbit> :-
21:21:53 <imsplitbit> :-D
21:21:59 <hub_cap> and the template can sub out the mysql version / package too
21:22:00 <vipul> we shall wait
21:22:06 <imsplitbit> "I'll be done in 2 days... or maybe not at all"
21:22:07 <hub_cap> so it should be pretty extensible
21:22:13 <hub_cap> imsplitbit: GOTO hell
21:22:15 <imsplitbit> :)
21:22:16 <vipul> lol
21:22:30 <hub_cap> that is all
21:22:50 <vipul> alright
21:22:57 <vipul> #topic API Validation Update
21:23:02 <vipul> juice: is this you?
21:23:12 <juice> little progress on this
21:23:21 <juice> have all the schema's defined
21:23:32 <juice> working on the code to slide it in the pipeline as a filter
21:23:35 <vipul> so we're going with json-schema to validate?
21:23:41 <juice> yes sir
21:23:44 <vipul> nice
21:23:47 <imsplitbit> noice
21:23:51 <juice> pass in a dict of the request and it validates
21:24:00 <juice> I have tests for the schemas and responses
21:24:18 <juice> it's pretty tight framework but then it takes a bit of practice to get the schema just right
21:24:21 <vipul> are we putting them in the reddwarf project?
21:24:41 <vipul> cuz i think we had xsds that were in reddwarf-int?
21:24:45 <juice> it has a few limitations/quirks but it follows the json schema spec quite closely
21:24:58 <vipul> we should probably put them in reddwarf proper
21:25:02 <juice> there are currently in reddwarf
21:25:22 <juice> what does putting them in reddwarf-integration buy us?
21:25:37 <vipul> nothing.. it makes it harder to manage
21:25:41 <juice> or rather, why would we put them there? to generate documentation or something
21:25:47 <vipul> i think i saw schemas there
21:25:58 <hub_cap> reddwarf proper
21:26:00 <vipul> anyone want to elaborate on this comment? "Many groups are doing this now"
21:26:03 <hub_cap> period
21:26:08 <hub_cap> yes vipul i wrote it
21:26:18 <hub_cap> there was talk about 2 projects adopting things
21:26:24 <hub_cap> some are doing json schema
21:26:27 <hub_cap> but some others are using wsme
21:26:28 <juice> hub_cap was trying to peer pressure me :)
21:26:34 <hub_cap> :D
21:26:38 <juice> smoke it kid everyone is doing it :)
21:26:42 <hub_cap> so eventually there will be some oslo stuff
21:26:46 <hub_cap> juice: ok!
21:27:03 <hub_cap> but we might end up moving away from json schema is what it seems, possibly
21:27:07 <hub_cap> since pecan/wsme can do it
21:27:13 <hub_cap> but thatll require a complete wsgi rewrite
21:27:16 <vipul> so we're monving to pecan/wsme?
21:27:17 <hub_cap> so we shou move forward for now
21:27:18 <juice> pecan?
21:27:21 <juice> wsme?
21:27:30 <hub_cap> juice: pecans fall from the wsme tree
21:27:38 <juice> oh yes - of course
21:27:54 <hub_cap> #link https://pypi.python.org/pypi/WSME
21:28:01 <hub_cap> but id say we wait for those
21:28:03 <vipul> is there a mandate?
21:28:09 <hub_cap> #link https://pypi.python.org/pypi/pecan/0.3.0
21:28:13 <hub_cap> no but thre is a movement
21:28:25 <hub_cap> we are the _only_ project using oslo.wsgi
21:28:31 <juice> this seems small enough of an effort for now, I don't see any reason to hold up and wait
21:28:32 <vipul> no way..
21:28:33 <vipul> nova?
21:28:38 <hub_cap> so it never caught on... and everyone is doing it their own way
21:28:40 <hub_cap> nope vipul
21:28:46 <hub_cap> markmc mentioned that
21:28:54 <juice> and it's more or less orthogonal to the the rest of the project being a filter
21:29:03 <hub_cap> ya juice keep moving w/ it
21:29:07 <hub_cap> we need good validation
21:29:18 <vipul> so much for being good citizens and using oslo
21:29:19 <hub_cap> just saying we shold watch what other groups are doing too
21:29:25 <hub_cap> heh right vipul?
21:29:52 <vipul> is pecan support going ot be in oslo then?
21:30:01 <hub_cap> probably eventually
21:30:01 <vipul> or we just ditch oslo for the web layer?
21:30:14 <hub_cap> i honestly dont know at this point
21:30:16 <hub_cap> we wait
21:30:21 <hub_cap> oslo.wsgi works for us
21:30:29 <hub_cap> ill hack it up when the time comes
21:30:39 <vipul> k
21:30:59 <vipul> #topic Validation of API input in Services vs Models
21:31:43 <vipul> what's this one about?
21:31:48 <juice> I was going to ask the same
21:31:51 <esmute> is this about the database name validation that merged last week?
21:31:56 <vipul> related to validating the db-user ?
21:31:59 <hub_cap> it merged?
21:32:02 <hub_cap> i put it on b4 it had merged
21:32:03 <datsun180b> i think so
21:32:07 <hub_cap> but yes it was about esmute's stuff
21:32:17 <hub_cap> i didnt want it to sit for more time
21:32:20 <vipul> do we have a guideline on these things?
21:32:25 <esmute> you +2'ed hub_cap
21:32:34 <juice> I have a related question when we are done with this
21:32:42 <juice> o/
21:32:43 <hub_cap> well good esmute!
21:32:47 <esmute> haha
21:32:56 <juice> o?
21:32:57 <vipul> so some things that touch the db make sense to be validated at the db layer
21:33:06 <vipul> since the underlying db may be different and there may be different rules
21:33:24 <hub_cap> example?
21:33:26 <datsun180b> right, we may not have the same rules for, for example usernames, should we switch db flavors
21:33:36 <vipul> database name is the example
21:33:40 <vipul> sorry db-user name
21:33:45 <hub_cap> oh i was thnking the infra db
21:33:49 <datsun180b> maybe some future impl doesn't allow db names that start with underscores
21:33:49 <hub_cap> and was confused
21:34:07 <hub_cap> im good now
21:34:10 <vipul> yep what datsun180b said
21:34:31 <juice> jsonschema can do pattern validation
21:34:42 <juice> or regex validation
21:34:42 <datsun180b> on the other hand, maybe our api has restrictions that aren't forbidden in the impl
21:34:56 <vipul> datsun180b: which is definitely the case.. since we have a backdoor
21:35:00 <datsun180b> exactly
21:35:00 <hub_cap> yes datsun180b both of your cases are valid
21:35:39 <vipul> i think esmute mentioned a use case where not-validating and creating a user through the backdoor breaks other apis
21:35:51 <datsun180b> i know the case
21:35:58 <juice> me too :)
21:36:02 <esmute> me too
21:36:14 <datsun180b> create a db that fails the validation and then try to list dbs, and you'll get 400s for a simple db list
21:36:14 <vipul> please enlighten us :D
21:36:21 <esmute> so validation is still done in the models.. at least for DB stuff
21:36:52 <datsun180b> 400 being "bad request"
21:37:09 <esmute> so what was done was to have teh validation in not all the db requests....
21:37:14 <esmute> for example listing DBs.
21:37:16 <vipul> datsun180b: but that should be fixed with esmute's patch? (list dbs at least)
21:37:21 <datsun180b> ideally
21:38:05 <vipul> esmute: but doesn't this still break like the grant api?
21:38:13 <vipul> you can list the users, but you can't do much more with them
21:38:24 <hub_cap> we should pass this off for now and think about it
21:38:28 <datsun180b> oh was that not part of the changes?
21:38:33 <esmute> you can list DB with bogus names that were created via the backdoor (root user)
21:38:34 <hub_cap> cuz this is gonna bite us for _every_ type of db in the future
21:38:43 <esmute> but you cannot delete them via the api
21:38:43 <datsun180b> we'd better bite first
21:39:14 <esmute> because when you try to deletethem, the validation code will prevent you
21:39:14 <hub_cap> datsun180b: exactly!
21:39:34 <datsun180b> i think our primary concern with validation is to fight exploitation, and our second is making sure that our resources can be referred to properly and uniquely with our url schema
21:39:46 <esmute> just so that we are all in the same page, we are talking about https://review.openstack.org/#/c/28850/
21:40:05 <hub_cap> esmute: i didnt +2 that! ;)
21:40:26 <esmute> oops. Sorry hub_cap.. I mistook you with grapex
21:40:38 <hub_cap> esmute:  grapex is my better half
21:40:41 <datsun180b> oh i don't think i approved that one either, i wanted tests
21:40:50 <imsplitbit> esmute: we all do that
21:40:54 <imsplitbit> they're basically twins
21:40:54 <esmute> there are tests there
21:41:00 <vipul> datsun180b: so what about just url-encoding when we do a list? i think we need to rethink the validation
21:41:11 <datsun180b> i hadn't seen them since, my last comment was against patch 2
21:41:11 <hub_cap> imsplitbit: im danny devito, and grapex is ahhhnald
21:41:17 <grapex> Guys am I hearing I didn't minus 2 enough? I tried my best!
21:41:26 <esmute> what i can do is add a new test that makes sure it skips the validation when it should
21:41:48 <datsun180b> esmute: i think a test needs to create a bad instance with a backdoor before all of the other tests run
21:41:58 <datsun180b> esmute: if none of them are interrupted we don't have a problem
21:42:01 <grapex> hub_cap: Because we all know recessive genes are worse somehow. :)
21:42:08 <hub_cap> HA
21:42:29 <datsun180b> i mean 'db' and probably also 'user' instead of 'instance'
21:42:58 <esmute> datsun180b: Ok. we need to have the agent mocked for that , no?
21:43:24 <datsun180b> yeah, that test can be mocked pretty easily
21:43:32 <hub_cap> shall we move this convo and move on? seems like we know we can write a test and keep vigilant of it
21:43:40 <datsun180b> #agree
21:43:44 <datsun180b> we need to discuss this more
21:43:50 <hub_cap> #agree w #agree
21:43:51 <esmute> ok
21:44:00 <vipul> #topic Create Schema vs Database
21:44:14 <hub_cap> huh? whats this? IR confused
21:44:15 <vipul> something to consider w/future version of our API
21:44:27 <hub_cap> ohhhhhhh u mean the api
21:44:33 <vipul> not all database types refer to database the way mysql does
21:44:41 <datsun180b> like the name SchemaController?
21:44:54 <hub_cap> i think vipul means from the customer facing perspective, ya?
21:44:58 <vipul> is that what it's really named?
21:45:02 <vipul> hub_cap: yes, customer facing api
21:45:03 <datsun180b> and the fact that it doesn't really create schemas so much as databases
21:45:11 <vipul> instances/id/schema
21:45:25 <datsun180b> then again i'm no dba
21:45:54 <vipul> well specifically oracle.. it's referred to as schema
21:45:55 <hub_cap> so heres the deal. most people i know who _arent_ dbas or who dont work w/ krow say database
21:46:18 <imsplitbit> :-)
21:46:19 <hub_cap> http://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_5004.htm
21:46:21 <datsun180b> and when you create one in mysql in particular, "create database" is the way to go
21:46:44 <datsun180b> i know how much as anecdotal evidence helps an argument
21:46:51 <hub_cap> heh datsun180b
21:46:52 <vipul> http://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_6014.htm
21:46:54 <vipul> :D
21:46:57 <imsplitbit> oddly enough the mysql workbench used to refer to creating database as creating schema
21:47:20 <hub_cap> Use the CREATE SCHEMA statement to create multiple tables and views and perform multiple grants in your own schema in a single transaction.
21:47:31 <datsun180b> well what would you know, all you have over me is extensive experience working with databases...oh
21:47:33 <hub_cap> will we be doing that? if so we shoudl use schema stuff
21:48:24 <hub_cap> imho we are doing database stuff, not schema stuff
21:48:26 <vipul> Yea i am not sure what the right way is... just got some feedback that this was confusing to some
21:48:27 <imsplitbit> also mysql information_schema refers to dbs as schema
21:48:41 <vipul> right, performance_schema, etc
21:48:46 <imsplitbit> exactly
21:48:51 <hub_cap> http://docs.oracle.com/cd/B19306_01/server.102/b14231/create.htm#i1008985
21:49:27 <datsun180b> my whole point is since i have no formal idea of what i'm talking about so i vote however imsplitbit does
21:49:28 <hub_cap> but then again im totally _not_ a dba
21:49:35 <hub_cap> datsun180b: #agree
21:49:36 <datsun180b> because i defer to him
21:49:58 <vipul> and maybe we route both urls to the same thing :D
21:50:12 <vipul> but something to consider for v2 or v3 or whenever
21:50:46 <hub_cap> vipul: id prefer not to, since in things like oracle create schema is drastically different than create database
21:50:56 <hub_cap> im not saying we _dont_ do schema stuff
21:51:10 <hub_cap> id prefer to not call it create schema if we arent doing anthing more than createing a database tho
21:51:20 <vipul> fair enough
21:51:25 <vipul> maybe it's an additional set of calls
21:51:31 <vipul> that really creates a schema instead
21:51:37 <imsplitbit> hub_cap: this is a much bigger discussion
21:51:45 <hub_cap> yes it is imsplitbit
21:51:50 <hub_cap> fwiw, mysql docs say
21:51:50 <hub_cap> CREATE DATABASE creates a database with the given name. To use this statement, you need the CREATE privilege for the database. CREATE SCHEMA is a synonym for CREATE DATABASE as of MySQL 5.0.2.
21:52:02 <hub_cap> but again thats _just_ for mysql :)
21:52:09 <imsplitbit> hub_cap: thats because mysql was designed to be simplified
21:52:16 <imsplitbit> a schema is a database
21:52:20 <imsplitbit> but it is beyond that
21:52:22 <datsun180b> maybe the distinction should be left to the impl and it just happens to be that mysql does that for us
21:52:25 <imsplitbit> it is a definition of constraints
21:52:38 <hub_cap> sure but its something our users need to understand
21:52:43 <imsplitbit> in the mysql context it means its a folder where table files get put
21:52:51 <imsplitbit> right
21:52:58 <datsun180b> i'd like to hope the understand the difference about the time they pick the impl they're using
21:53:10 <hub_cap> datsun180b: simple is better :)
21:53:14 <imsplitbit> schema is more "cross platform" :-)
21:53:17 <hub_cap> vipul: see the can u opened ;)
21:53:26 <hub_cap> is it imsplitbit?
21:53:26 <imsplitbit> most DBMS' refer to them as schema
21:53:46 <vipul> hub_cap: yea we should probably table this since it's not going to be decided here
21:53:54 <hub_cap> imsplitbit: def
21:53:56 <imsplitbit> well the ones that require you to wear your big boy pants
21:53:57 <hub_cap> vipul: double def
21:54:03 <hub_cap> imsplitbit: HAH
21:54:15 <datsun180b> select count(*) from nice_things where we_can_have_one = 1;
21:54:17 <imsplitbit> mysql is kinda "my first dbms"
21:54:22 <datsun180b> 0 rows returned
21:54:23 <vipul> imsplitbit: i've heard it be called schema in oracle for the most part
21:54:44 <datsun180b> wait see i'm no dba, it would return one row, count = 0
21:55:14 <hub_cap> vipul: this is interesting and non authoritative
21:55:14 <vipul> ok onto the next thing?
21:55:14 <hub_cap> Now that we have a database we can create schemas inside the database. A schema is defined as a user that owns data such as tables, views, indexes, and so forth. If a user has no data of their own and just connects and queries for information then they are not considered a schema. This is the difference between a schema and a user. Also you may be familiar with other database systems and will notice that what Oracle calls a schema the other
21:55:25 <hub_cap> yes plz :)
21:55:34 <datsun180b> is there a #motion-to-table
21:55:40 <hub_cap> #move-on
21:55:41 <vipul> #tabled
21:55:45 <hub_cap> #help
21:55:52 <vipul> #topic Incubation Status
21:55:54 <hub_cap> #plzgodhelp
21:55:58 <vipul> lol
21:56:02 <hub_cap> ummmmmmmm really?
21:56:02 <vipul> this one's for you hub_cap
21:56:09 <hub_cap> ok we are um, incubated
21:56:11 <hub_cap> done
21:56:11 <datsun180b> hub_cap i think you're hashtagging by mistake
21:56:14 <vipul> what does it mean??
21:56:21 <hub_cap> #doublerainbow
21:56:38 <vipul> do we have an update on when we move to openstack github
21:56:49 <vipul> or when we can leverage openstack-ci for gate?
21:56:50 <hub_cap> yes i know exactly when we move
21:56:55 <hub_cap> when we get a name
21:57:01 <hub_cap> mark collier is _still_ on vacation
21:57:12 <hub_cap> so we wont get any traction till he gets back on that
21:57:25 <vipul> kk
21:57:49 <vipul> is there a list of things that we need to do prior to next summit?
21:57:56 <vipul> or is this process pretty open-ended
21:58:04 <hub_cap> really just heat
21:58:08 <hub_cap> thats the only thing they want to see done
21:58:12 <hub_cap> thats my biggest prio
21:58:35 <vipul> ok cool
21:58:57 <vipul> #topic Open Discussion
21:59:09 <vipul> anything else to discuss?
21:59:28 <imsplitbit> replication api ideas
21:59:43 <juice> can someone give me the quick run down of class type/module and responsibility
21:59:44 <imsplitbit> I've started spit balling on the replicationa and clustering concepts wiki page
21:59:53 <juice> go ahead imsplitbit
21:59:55 <vipul> imsplitbit: sorry i've been out how's that been going
22:00:05 <imsplitbit> I'd love to hear from anyone and everyone on what I've got
22:00:11 <imsplitbit> they're very early ideas
22:00:14 <vipul> can you link here again?
22:00:19 <imsplitbit> but I'd love collaboration on it
22:00:21 <imsplitbit> wait one
22:00:36 <hub_cap> ill wait 2 for u
22:00:41 <imsplitbit> #link https://wiki.openstack.org/wiki/Reddwarf-MySQL-Replication-and-Clustering-Concepts#Ideas_for_API
22:01:02 <imsplitbit> basically noodling so far so don't feel like you gotta hold back
22:01:08 <imsplitbit> if it's stupid, it's stupid
22:01:12 <datsun180b> > noodling
22:01:12 <imsplitbit> lets get it worked out
22:01:37 <imsplitbit> I'd like to have a final proposal no later than the end of the week
22:01:45 <imsplitbit> so we can at least get some poc code started
22:01:45 <vipul> nice.. thanks for getting this started
22:01:58 <vipul> so the idea is to do a cluster api from the start?
22:02:04 <hub_cap> http://sportbloggingp445.files.wordpress.com/2012/02/noodling-small.jpg
22:02:08 <hub_cap> ^ ^ noodling
22:02:20 <hub_cap> vipul: the idea is that mysql replication is a type of cluster
22:02:21 <imsplitbit> well the idea that hub_cap and I had was that there's so much in common between the two we just treat them the same
22:02:22 <datsun180b> thanks for that
22:02:34 <hub_cap> > 1 nodes treated as a single entitiy
22:02:48 <imsplitbit> and perhaps we call it something other than cluster/s
22:02:49 <hub_cap> w/ add/drain/remove ops just like any other cluster
22:02:58 <hub_cap> i proposed marshmallows
22:02:59 <hub_cap> it didnt fly
22:03:05 <imsplitbit> so as to not imply true clustering
22:03:12 <imsplitbit> marshmallows
22:03:16 <hub_cap> imho cluster is fine
22:03:16 <vipul> does that mean you can't create a single instance.. and later replicate it?
22:03:24 <hub_cap> u can vipul
22:03:37 <hub_cap> some types of clustering wont allow it, but master/slave will allow "promoting"
22:03:40 <imsplitbit> no theres an idea in there somewhere that lets you create a "cluster" from an existing instance
22:03:40 <hub_cap> so to speak
22:03:53 <vipul> ok i see it
22:04:15 <hub_cap> so stick your arm down a catfish's throat on it some and give feedback
22:04:24 <imsplitbit> please
22:04:24 <hub_cap> sry i mean noodle on it
22:04:28 <vipul> heh
22:04:29 <imsplitbit> lol
22:04:43 <imsplitbit> hub_cap: you've never been noodling
22:04:45 <imsplitbit> I have
22:04:55 <hub_cap> imsplitbit: grats
22:04:56 <imsplitbit> brings out your inner redneck
22:05:07 <hub_cap> oh im sure it does. fwiw i would TOTALLY do it
22:05:19 <imsplitbit> but thats another story for another time
22:05:33 <imsplitbit> thanks for looking at it guys and I look forward to hearing from ya
22:05:36 <hub_cap> we are 5min over
22:05:43 <vipul> juice: you had something?
22:05:44 <imsplitbit> I'm done
22:05:48 <hub_cap> likely my fault mostly
22:05:49 <imsplitbit> juice had something
22:05:51 <grapex> Awesome work imsplitbit.
22:05:59 <imsplitbit> thx
22:05:59 <hub_cap> ya imsplitbit now code it
22:06:11 <grapex> And test it. :p
22:06:17 <juice> when I say models you say ?
22:06:18 <esmute> yeah.. that was cool. Im reading it now imsplitbit
22:07:04 <hub_cap> juice: sledoms?
22:08:19 <vipul> kate upton?
22:08:19 <juice> ok that's a bit corny - I am just wondering in our architecture document if we have a well established responsibilities for each class/class type/module
22:08:19 <juice> hubba
22:08:54 <vipul> not sure i've seen that documented anywhere
22:09:25 <juice> going through the exists feature, I felt a little lost as two what Tasks, Models, Services are supposed to do.  And then why There is a christmas tree of classes for Instances
22:09:36 <juice> I should have use pyramid
22:10:26 <juice> s/use/used
22:11:09 <vipul> api layer = Service, delegates to Tasks to coordinate, which delgates to models to persist or remote model
22:11:15 <juice> The reason for asking is that it may be a bit of a challenge to keep consistency as new devs come on
22:11:24 <vipul> yea, it's not very consistent..
22:11:45 <vipul> i think the Tasks stuff was never really completed.. since there seems to be a concept of task state
22:11:51 <vipul> which isn't really reported on or acted on
22:12:00 <vipul> i could be wrong though
22:12:04 <juice> I just wanted to know the gospel so that while there may be inconsistencies, at least I know the intention
22:12:58 <imsplitbit> CAN I GET A WITNESS?!?
22:14:04 <juice> can you see the light?!
22:14:16 <imsplitbit> preach on brother!
22:14:19 <imsplitbit> preach it
22:14:24 <imsplitbit> :)
22:14:56 <vipul> i guess that's a wrap?
22:14:57 <juice> I was looking for a link to blues brothers scene with james brown
22:15:02 <vipul> looks like most people have checked out
22:15:19 <imsplitbit> yeah I spose thats a wrap?
22:15:29 <vipul> #endmeeting