22:00:28 <hub_cap> #startmeeting reddwarf
22:00:29 <openstack> Meeting started Tue Feb 12 22:00:28 2013 UTC.  The chair is hub_cap. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:32 <openstack> The meeting name has been set to 'reddwarf'
22:00:38 <hub_cap> we will give a bit more before we begin
22:01:03 <vipul> oh it has begun
22:01:12 <hub_cap> lul
22:01:13 <hub_cap> z
22:01:21 <datsun180b> Just after the buzzer
22:01:31 <hub_cap> #link http://wiki.openstack.org/Meetings/RedDwarfMeeting
22:01:43 <hub_cap> #topic action items
22:01:45 <hub_cap> #link http://eavesdrop.openstack.org/meetings/reddwarf/2013/reddwarf.2013-02-05-22.00.html
22:02:25 <hub_cap> aight lets get this ball rolling, vipul youre up. got a link for that blueprint on roles?
22:02:34 <vipul> yup
22:02:43 <vipul> #link https://blueprints.launchpad.net/reddwarf/+spec/api-policies
22:03:00 <hub_cap> very nice. any progress on it as of yet?
22:03:12 <vipul> i think the for things like 'enable root user' we'll want to support more granular roles
22:03:16 <vipul> not yet..
22:03:28 <hub_cap> vipul: sure the approach nova has lets u define any arbitrary role
22:03:34 <hub_cap> the policy file stuff
22:03:43 <vipul> cool... i think it may be a simple port, we'll see
22:03:56 <hub_cap> ya i thik so too :) like limits :D
22:04:08 <vipul> gotta love copy/pasta
22:04:12 <hub_cap> yuuuuuuuuup
22:04:13 <SlickNik> heh
22:04:24 <hub_cap> djohnstone: youre next but lets let it ride till the actual repose update section
22:04:34 <djohnstone> k
22:04:41 <hub_cap> kaganos: hows the percona stuff comin?
22:04:46 <hub_cap> well crap... lets wait on that too
22:04:50 <hub_cap> since we have topics for both :P
22:04:57 <hub_cap> lulz
22:05:13 <SlickNik> sounds good.
22:05:15 <kaganos> i'll need a bp as well
22:05:20 <vipul> #action hub_cap to create a couple more dummy bps
22:05:24 <hub_cap> word
22:05:24 <kaganos> do we need one for every project?
22:05:33 <hub_cap> we prolly need like 5 for all of them :)
22:05:35 <hub_cap> or more
22:05:36 <kaganos> need one for reddwarf and one for reddwarf-integration
22:05:49 <hub_cap> so i suck. i havent started a markdown yet for the api. We havent made much progress on it but id like to propse a breakout session to discuss the api at the summit
22:06:02 <hub_cap> ill talk about that in a bit, i talked to ttx about how we fit in
22:06:04 <kaganos> or an "ok" to checkin with a single one
22:06:28 <vipul> kaganos, i think we'll just create one for each .. hub_cap please create dummy for both projects
22:06:34 <hub_cap> roger
22:06:42 <hub_cap> dkehn is not present. anyone have a update on his snapshot bp?
22:07:01 <vipul> he is working throught he schema design at the moement
22:07:13 <hub_cap> coo
22:07:18 <vipul> i think he is making progress, some things will change -- like xtrabackup
22:07:25 <vipul> from the consistent-snapshots bp
22:07:26 <hub_cap> well then... thats all of our action items w00t
22:07:41 <SlickNik> wow, new record.
22:07:43 <hub_cap> #topic Quotas / Limits Updates
22:07:45 <vipul> new more action items
22:07:48 <vipul> need
22:07:56 <SlickNik> But only because we punted two of them to later discussions :P
22:07:56 <cp16net> 7 min
22:07:59 <hub_cap> def, we arent workin hard enough!!
22:08:02 <hub_cap> SlickNik: SHHHHHHHHH
22:08:08 <kaganos> vipul, started talking like Yoda ??
22:08:20 <vipul> kaganos: LOL
22:08:26 <hub_cap> so lets start w/ the public code wrt this topic. how are absolute and rate limits comin
22:08:26 <vipul> it was bound to happen
22:08:42 <hub_cap> and remember absolute limits == quotas :)
22:08:54 <vipul> Esmute ^
22:09:09 <SlickNik> He's coming on, one sec.
22:09:09 <vipul> why the name change/
22:09:11 <grapex> hub_cap: I thought they were more "extreme" edgy forms of limits marketed to a younger crowd.
22:09:22 <vipul> heh
22:09:24 <Esmute> quota are going well.
22:09:37 <hub_cap> LOL those are absolut limits grapex
22:09:43 <Esmute> i have created all the db tables, models and i have done reservation for both create/delete instances
22:09:45 <datsun180b> I think it's more absolute limits ⊆ quotas
22:09:49 <imsplitbit> grapex, you're thinking of iXTREME Limits
22:09:56 <grapex> lol
22:09:57 <Esmute> i also wrote unit tests against the reservation engine
22:10:00 <hub_cap> great Esmute
22:10:03 <imsplitbit> and it's newer cousin eXTREME Limits
22:10:09 <hub_cap> good progress
22:10:11 <djohnstone> hub_cap:  You mentioned that we were going to look at hammering out a /limits/ API call but I completely forgot about that when we were talking yesterday
22:10:24 <Esmute> what is missing is a way to allow users to set quota limits on tenants...
22:10:29 <hub_cap> djohnstone: ya we should work thru that during this discussion
22:10:42 <Esmute> as of now, the quota limits are configurables and will start with a default value.
22:11:05 <hub_cap> cool. i think its ok to pull that in as a v1 and then add api calls if u want to do them in 2 reviews
22:11:05 <Esmute> i will add an api for users to set/update quota limits
22:11:13 <hub_cap> okey
22:11:20 <Esmute> sounds good.
22:11:30 <hub_cap> so fyi, code freeze is this wk but we arent gonna participate in it :)
22:11:30 <vipul> Esmute: you can split them up in multiple reviews if you think it makes sense
22:11:37 <Esmute> i should be sending something to be reviewed tomorrow
22:11:39 <vipul> whaaa?
22:11:41 <hub_cap> might be esier on our eyes
22:11:44 <vipul> what code freeze
22:11:47 <hub_cap> vipul: for all the openstack projects
22:11:48 <Esmute> yes
22:11:52 <SlickNik> code freeze?
22:11:54 <hub_cap> no new code/features
22:11:59 <vipul> oh
22:12:00 <hub_cap> only bugs / existing features
22:12:00 <cp16net> griz
22:12:01 <Esmute> first review will be reservation, quota checking
22:12:02 <juice> tip when? for what?
22:12:05 <SlickNik> ah, for grizzly?
22:12:06 <vipul> 2 months away!
22:12:07 <hub_cap> Esmute: perfect
22:12:09 <grapex> Makes sense since our project lives in a forge.
22:12:18 <Esmute> second review will be api to add/update quota limits
22:12:30 <hub_cap> sounds good to me Esmute
22:12:31 <vipul> waterfall FTW
22:12:36 <hub_cap> lol
22:12:42 <Esmute> in the first review, the quota limit will be obtained from the conf
22:12:44 <juice> we need a third blueprint then for limits
22:12:48 <hub_cap> so was it esp working on rate limits?
22:12:51 <juice> rate limits
22:12:54 <hub_cap> juice:  was that u?
22:12:56 <juice> no that is esp and I
22:12:57 <SlickNik> esp and juice
22:13:10 <SlickNik> teamin' up on it..
22:13:18 <hub_cap> ok cool. hows thats goin yer next. and yes i think a diff BP would be good for rate limits
22:13:23 <juice> dan ported most of the code from nova.  I am working on unit tests.
22:13:24 <hub_cap> they really only meet in a single /limits call
22:13:31 <juice> 7 or the 34 are still failing
22:13:34 <hub_cap> woah juice whos dan?!?! ;)
22:13:38 <kaganos> man! i lose track with all those nicks … what happened to simply using regular human names ??!
22:13:40 <juice> esp
22:13:50 <hub_cap> kaganos: whats a regular human name!?! ;)
22:13:52 <vipul> like kaganos
22:14:05 <kaganos> i felt i had too ...
22:14:08 <kaganos> sorry :(
22:14:09 <hub_cap> thats what /whois is for
22:14:13 <datsun180b> ^^
22:14:29 <hub_cap> ok great progress. looking foward to seeing it impl'd
22:14:40 <vipul> shoudl be this week for both.. that's the goal
22:14:41 <hub_cap> so are yall teaming up to do the /limits call? Esmute/ juice
22:14:49 <hub_cap> since u both have pieces that touch it
22:14:59 <hub_cap> or are u racing to see who has to rebase
22:15:00 <Esmute> not really
22:15:08 <vipul> esp mentioned that there is one call that depended on quotas
22:15:10 <juice> hub_cap: I think the integration is yet to come
22:15:16 <Esmute> i think we are doing this separately
22:15:21 <vipul> basically freindly api to list all limits
22:15:22 <Esmute> ok.. i can talk to him
22:15:28 <juice> there is a bit of over lap but not too much
22:15:33 <Esmute> ok.. i havent done any api yet
22:15:35 <hub_cap> right id say one of yall push first and the other rebase/finish
22:15:46 <Esmute> so i can get together with esp
22:15:51 <vipul> coo
22:16:07 <hub_cap> okey. alternative would be to push a dummy limits call... but if yall will be done this wk i dont wanna go that far
22:16:13 <hub_cap> will that be ok for u djohnstone?
22:16:20 <djohnstone> yes
22:16:39 <juice> hub_cap: we'll be done within a couple of days
22:16:42 <hub_cap> tight
22:16:44 <juice> eta thursday
22:17:00 <Esmute> something simple for api... like /quotas and /quota-usages
22:17:14 <hub_cap> Esmute: ure talkin about the setter api
22:17:21 <hub_cap> the /limits call returns both rate and absolute too
22:17:23 <Esmute> setter and getter
22:17:26 <hub_cap> so users can tell what limits they are
22:17:48 <hub_cap> check http://api.openstack.org/api-ref.html
22:17:48 <vipul> Esmute: you're correct, i think the only thing is /limits needs to pull from your stuff as well
22:17:52 <hub_cap> GET v2/{tenant_id}/limits
22:18:20 <juice> hub_cap: will take a look thanks
22:18:33 <hub_cap> the whole quota-sets stuff is for administrators fyi as per the api
22:18:38 <hub_cap> Enables administrators (depending on policy settings) to see quotas for a tenant, update quotas, and view default quotas.
22:18:41 <Esmute> thats for rate-limits only right, hub_cap?
22:18:47 <hub_cap> Esmute: no
22:18:49 <cp16net> #link http://api.openstack.org/api-ref.html
22:18:51 <Esmute> shouldnt we have one for quota limits?
22:18:52 <SlickNik> no, that's for both esmute.
22:19:03 <hub_cap> Esmute: https://gist.github.com/hub-cap/4773972
22:19:05 <vipul> look at the response json
22:19:13 <hub_cap> thats a snippet of teh response json
22:19:31 <Esmute> ahhh ok
22:19:39 <hub_cap> yup. and then the /quotas will be admin calls
22:19:49 <hub_cap> all the more reason to have a policy defined right vipul :P
22:19:58 <Esmute> any reason why we are combining rate and absolute limits together?
22:20:10 <Esmute> Is it to be in synced with nova>
22:20:12 <hub_cap> Esmute: cuz they are both limits from a user perspective
22:20:14 <vipul> heh yes.. we'll modify when we get there
22:20:29 <hub_cap> do u _want_ to make 2 calls to get your limits?
22:20:32 <hub_cap> i dont :)
22:20:47 <hub_cap> a user cant mod their quotas so all the calls that do quota mod will be administrator driven
22:20:51 <SlickNik> one call for users to get all limits, I guess, regardless of whether absolute or rate-limited.
22:20:56 <Esmute> ok
22:20:58 <hub_cap> SlickNik: yessir
22:21:11 <Esmute> ill sync up with esp and juice about the api call
22:21:17 <hub_cap> perfect
22:21:30 <vipul> hub_cap: so where does repose fit in
22:21:42 <hub_cap> well djohnstone can answer that
22:21:43 <vipul> my understanding is you'll have to implement a couple of API calls that repose can call back into
22:21:50 <vipul> will that go in Reddwarf?
22:21:56 <djohnstone> We will pull the absolute limits out.
22:22:02 <hub_cap> my guess is that they will be those calls /limits
22:22:16 <vipul> what about getting current count, eetc
22:22:16 <cp16net> btw i see the v2 api in nova have rate and absolute together
22:22:29 <djohnstone> then we will return repose Rate Limits and Absolute limits combined
22:22:51 <hub_cap> vipul: those will be the other api calls Esmute is creating in /quotas
22:22:57 <hub_cap> the admin-esque calls
22:23:26 <vipul> ah .. so the current count of resources (# of instaces) will be covered by the /quotas callL?
22:23:26 <hub_cap> is my guess vipul... i havent looked at it much. but we have a team running nova+repose using that api
22:23:35 <vipul> ah ok
22:23:46 <SlickNik> clarification: does repose enforce both absolute and rate-limit or just rate-limits?
22:23:52 <djohnstone> just rate
22:23:54 <vipul> i guess i need to look a bit further.. maybe if you give Repose admin role.. then they may have everything they need
22:24:02 <hub_cap> ahh look @ this vipul
22:24:03 <hub_cap> Used Limits
22:24:05 <Esmute> s
22:24:05 <hub_cap> on the api page
22:24:14 <cp16net> yesh
22:24:14 <hub_cap> its a extension that adds used limits
22:24:16 <vipul> oh it's only rate..t hen it makes sense
22:24:18 <SlickNik> thanks djohnstone, that makes sense then.
22:24:23 <hub_cap> so we might just put that in the /limit call by default
22:24:41 <vipul> ah ok
22:24:43 <hub_cap> absolute is hanigng down at the bottom of "Used Limits" vipul
22:24:47 <cp16net> v2/{tenant_id}/limits
22:24:49 <vipul> yup just found it
22:25:07 <hub_cap> so lets consider putting those directly in the call
22:25:26 <vipul> i don't know why the URI is the same
22:25:34 <cp16net> its v2
22:25:36 <vipul> /limits for both
22:25:37 <vipul> oh
22:25:39 <cp16net> :)
22:25:44 <cp16net> it was improved
22:25:51 <hub_cap> good catch cp16net
22:25:59 <vipul> it's v2 above too though
22:26:01 <cp16net> looks like it was an extension maybe
22:26:01 <hub_cap> it really just adds "totalRAMUsed"
22:26:08 <hub_cap> cp16net: likely
22:26:15 <vipul> yea looks like extension
22:26:17 <hub_cap> its just adding a few fields in the json.
22:26:42 <hub_cap> so if u want to add those Esmute i would <3 u
22:26:44 <cp16net> well its an array of rates
22:26:47 <Esmute> ok...
22:26:47 <cp16net> it looks like
22:27:01 <Esmute> there is too much communication here.. and lots of ideas.. i am kinda lost
22:27:04 <hub_cap> cp16net:  its only adding "remaining": 24,
22:27:15 <hub_cap> so to rate limits, the filed "remaining": XXX is added
22:27:16 <Esmute> can we put all these info in a BP so i can read it and know what to do?
22:27:19 <cp16net> yeah not much different
22:27:22 <vipul> Esmute does not like communication :)
22:27:24 <hub_cap> Esmute: thats  agreat idea
22:27:26 <hub_cap> LOL
22:27:37 <SlickNik> heh
22:27:48 <Esmute> i can create a BP and state what im doing. Then you guys can review it
22:27:49 <hub_cap> juice: so yours will need to add "remaining": XXX, and Esmute, yours will need to add things like totalRAMUsed
22:27:53 <vipul> yea adding to BP would clarify things
22:27:56 <hub_cap> make sense?
22:28:28 <hub_cap> its not a ton different, just adding the actual "used/remaining" into the /limits call
22:28:52 <hub_cap> ill be glad to add to the bp Esmute/juice
22:29:02 <vipul> hub_cap: please do.. just for completeness
22:29:04 <hub_cap> djohnstone: do u have anything to add oppa repose style?
22:29:11 <djohnstone> nope
22:29:15 <grapex> lol
22:29:19 <Esmute> ok. So juice and I will be constructing a response similar to the one in nova
22:29:21 <cp16net> lol
22:29:23 * juice juice thinks he understands
22:29:42 <hub_cap> #action update the 2 limits (absolute/rate) BPs to define the remaining/used fields
22:29:51 <hub_cap> doh... that wont have my name associated with it
22:29:57 <hub_cap> #action hub_cap to do that ^ ^
22:30:01 <hub_cap> :)
22:30:08 <cp16net> lol
22:30:13 <hub_cap> #topic Percona Image Updates
22:30:17 <hub_cap> kaganos: yer up
22:30:21 <kaganos> yep
22:30:23 <hub_cap> how is the guest stuff a-goin
22:30:23 <kaganos> oh boy ...
22:30:26 <hub_cap> lulz
22:30:29 <SlickNik> heh
22:30:32 <kaganos> one issue on top of the other ...
22:30:40 <hub_cap> issue jenga
22:30:52 <kaganos> so, there are several places where the specific mysql package is used which is causing issues.
22:31:07 <kaganos> the last one i caught was before doing the backup to nova volume
22:31:14 <kaganos> so, the backup was not done ...
22:31:22 <hub_cap> for sure... we never thought about > 1 mysql :D but at least you have made it able to use N types now :D
22:31:25 <kaganos> after fixing that we have the following issue:
22:31:54 <kaganos> for some reason, the my.cnf file used, when used with percona, takes too long to come up
22:31:59 <kaganos> the service start that is
22:32:13 <kaganos> so we bump into the service start timeout
22:32:22 <vipul> kaganos: look into buffer_pool or simlar settings?
22:32:22 <kaganos> (of around 14 sec i believe...)
22:32:22 <cp16net> maybe give it some more coffee?
22:32:37 <hub_cap> woah crap 14s for mysql to come up!?
22:32:42 <kaganos> Don was working his @ss on this for over 2 hours with me today ...
22:32:46 <hub_cap> kaganos: are u working on your vm?
22:32:49 <hub_cap> Don!?!? whos don?!?!?
22:32:54 <vipul> dkehn
22:32:54 <vipul> lol
22:32:55 <SlickNik> dkehn
22:32:57 <kaganos> nope, nova node ..
22:32:57 <SlickNik> heh
22:32:58 <kaganos> :)_
22:33:03 <hub_cap> oh crap dude
22:33:05 <hub_cap> thats vt
22:33:12 <cp16net> yeah sounds like it
22:33:14 <hub_cap> not config settings is my guess
22:33:24 <kaganos> so, when this happens, the node is stuck forever ...
22:33:25 <vipul> i think he's running the stock mysql the same way
22:33:35 <hub_cap> okey
22:33:35 <kaganos> the stock mysql comes up faster
22:33:39 <juice> cloud is at least twice as slow with nested vms
22:33:39 <kaganos> now, listen to this:
22:33:47 <hub_cap> juice: 100x slower more like
22:33:52 <kaganos> the reason for percona to come up slowly is
22:33:57 <cp16net> #link http://yunatech.blogspot.com/2013/01/openstack-running-devstack-in-vmware.html
22:34:00 <kaganos> (don's assumption)
22:34:01 <cp16net> that might help ya :)
22:34:11 <vipul> cp16net is quite the blogger
22:34:11 <kaganos> that they added a lot of performance improvements ....
22:34:15 <cp16net> :-P
22:34:18 <kaganos> so now it comes up more slowly!
22:34:22 <kaganos> makes sense, right ?!
22:34:27 <vipul> heh
22:34:39 <kaganos> i'm not using vmware ...
22:34:41 <kaganos> anyway
22:34:41 <grapex> kaganos: Is that like how Java is as fast as native code but always seems slower than Python? :)
22:34:50 <kaganos> probably ...
22:34:52 <kaganos> ;)
22:34:55 <cp16net> hah
22:34:59 <hub_cap> lol better performance == slower startup :)
22:35:07 <kaganos> so, i'll try to use a bigger image and see if that helps
22:35:15 <hub_cap> cool. thx for the update
22:35:17 <cp16net> gotta sacrafice somewhere right?
22:35:17 <kaganos> but! we need to think about something solid here ...
22:35:23 <vipul> kaganos, so you're out of the woods with the not starting up issue?
22:35:33 <kaganos> i think so
22:35:43 <kaganos> btw, a quick question:
22:35:43 <vipul> ok good
22:35:51 <kaganos> when using rd-client instance create
22:35:59 <kaganos> i use "size = 2"
22:36:04 <kaganos> but get a "tiny" node ...
22:36:06 <kaganos> why?
22:36:10 <hub_cap> flavor=X
22:36:12 <vipul> cuz that's just volume size
22:36:13 <grapex> size is the volume size
22:36:13 <hub_cap> size is volume
22:36:13 <kaganos> do i need to set "flavor?
22:36:14 <SlickNik> the size is just the volume size
22:36:19 <hub_cap> lulz i win
22:36:22 <kaganos> oh ....
22:36:24 <kaganos> k
22:36:27 <SlickNik> lolol @ hub_cap
22:36:31 <kaganos> it didn't ask for flavor
22:36:38 <vipul> you can set --flavor
22:36:39 <cp16net> the flavor will deafult to 1
22:36:40 <kaganos> let's see if small would make any difference
22:36:41 <vipul> to override devault
22:36:52 * cp16net cant speel
22:37:03 * vipul can't either
22:37:09 <kaganos> well, it does look like some kind of file system issue. not sure more ram would help, but worth the try
22:37:12 * hub_cap wins for terrible spelling, its in action items
22:37:14 <kaganos> updates will follow ...
22:37:18 <hub_cap> thx kaganos
22:37:23 <kaganos> sure
22:37:24 <hub_cap> ready to move on?
22:37:32 <SlickNik> sounds good.
22:37:33 <cp16net> good work
22:37:36 <hub_cap> #topic Security Groups feature feedback
22:37:38 <grapex> Maybe we should change the CLI to not have a default flavor. May just add confusion.
22:37:44 <SlickNik> nice work, kaganos! Keep going….
22:37:49 <hub_cap> grapex: #agreed grapex
22:37:53 <SlickNik> Also, hope you're feeling better.
22:37:55 <vipul> xs seems small for default, but that's a diff convos
22:38:04 <hub_cap> id say file a bug grapex :)
22:38:08 <hub_cap> so sec grps
22:38:23 <hub_cap> vipul: hows it a-goin?
22:38:27 <grapex> hub_cap: I'll file a blueprint, bug seems harsh. You guys can decide if you want to approve it.
22:38:28 <vipul> SlickNik filed the blueprint
22:38:30 <datsun180b> We can just add require('flavor') to the create_instance function
22:38:36 <SlickNik> #link https://blueprints.launchpad.net/reddwarf/+spec/security-groups
22:38:43 <hub_cap> vipul: ahh SlickNik hows it goin?
22:38:51 <hub_cap> grapex: that makes more sense i think
22:38:55 <SlickNik> #link http://wiki.openstack.org/reddwarf-security-groups
22:39:07 <vipul> nice use of wiki
22:39:14 <SlickNik> floated ideas out to the broader team.
22:39:47 <hub_cap> SlickNik: one Q
22:39:51 <SlickNik> Haven't started the actual implementation yet.
22:39:53 <SlickNik> go for it.
22:40:06 <hub_cap> are we mandating that all instances _have to_ have a security group?
22:40:17 <hub_cap> Overview #2 seems to imply that
22:40:18 <SlickNik> Yeah, that's the plan.
22:40:31 <hub_cap> im not sure i like that idea
22:40:34 <vipul> we could make it a setting like volume_support, but it should be on/off
22:40:44 <hub_cap> vipul: i can deal w/ that
22:40:54 <hub_cap> i dont think everyone will need security groups
22:41:06 <SlickNik> We would make it an extension.
22:41:07 <vipul> right, especially if you're behind Zeus :p
22:41:10 <kaganos> there is always the default, isn't it ??
22:41:15 <hub_cap> lol vipul
22:41:20 <SlickNik> But once it's on, every instance would have it.
22:41:49 <vipul> SlickNik: yes, we should clarify it's on/off not some have others don't
22:41:50 <cp16net> would it create groups even though its not turn on?
22:41:51 <hub_cap> SlickNik: thats true. if the extension is grafted on to the api it could use it
22:41:53 <vipul> that becomes nightmare
22:41:55 <SlickNik> (especially since sec-groups are a nova extension itself.)
22:42:04 <hub_cap> vipul: all or nothing is the way to go
22:42:15 <hub_cap> vipul: and dont u mean nightmare that becomes?
22:42:21 <vipul> lol
22:42:21 <SlickNik> #action SlickNik to clarify that sec-groups are an extension and can be toggled.
22:42:30 <hub_cap> perfect SlickNik
22:42:32 <hub_cap> <3
22:42:35 <vipul> hub_cap
22:42:38 <hub_cap> vipul:
22:42:41 <hub_cap> :P
22:42:44 <SlickNik> cool, sounds good.
22:42:45 <vipul> the way extensions are set up currently
22:42:49 <vipul> it's all or notihng
22:42:58 <vipul> how do we configure some extensions and not others
22:43:11 <hub_cap> u know thats a good question. im not sure u can
22:43:17 <cp16net> conf? or paste?
22:43:17 <hub_cap> im not even sure nova has that functionality
22:43:21 * cp16net shrugs
22:43:29 <vipul> cp16net: nope, haven't seen it before
22:43:35 <SlickNik> that's a bummer.
22:43:50 <hub_cap> and i think they are moving toward using stevedore too for entry points
22:44:00 <hub_cap> that may be configurable
22:44:04 <SlickNik> Might want to have a chat with openstack-dev to see why it's done that way and what they recommend.
22:44:05 <vipul> we ok with that? implement as extension, but have flag to turn off on
22:44:45 <vipul> wth is stevedore
22:44:59 <hub_cap> #link https://github.com/dreamhost/stevedore
22:45:05 <grapex> vipul: Some yatching term I think?
22:45:16 <cp16net> i thought that was some random reference i missed
22:45:17 <grapex> *yachting
22:45:25 <SlickNik> interesting
22:45:32 <vipul> lol good thing i wasn't the only one cp16net
22:45:42 <hub_cap> haha nice
22:45:46 <cp16net> random...
22:45:47 <cp16net> #link http://en.wikipedia.org/wiki/Stevedore
22:45:56 <SlickNik> one who loads and unloads ships?
22:46:14 <SlickNik> random, indeed.
22:46:36 <vipul> ok ready to move on?
22:46:38 <hub_cap> i cant seem to find it in the nova codebase but its used in cinder and i saw some traction on it in oslo somewhere
22:46:39 <hub_cap> ya
22:46:46 <hub_cap> #topic API Spec General Update
22:47:01 <hub_cap> #action hub_cap needs to not be so lame
22:47:03 <SlickNik> sounds good. move on.
22:47:22 <hub_cap> there has been no update to the api spec. we did not get far last time and i think we have a meeting for next wk
22:47:29 <cp16net> #agreed with hub_cap
22:47:31 <cp16net> :-P
22:47:37 <vipul> hub_cap: can we get existing API up on the database-api github
22:47:48 <vipul> we can at least iterate/help out in that area
22:47:56 <SlickNik> #action SlickNik to look at stevedore for entry points to extensions? https://github.com/dreamhost/stevedore
22:48:03 <cp16net> thats a good point vipul
22:48:04 <SlickNik> (sorry wanted to sneak that in there)
22:48:06 <hub_cap> vipul: ya ill ping mike a, i thnk he is waiting on us to review
22:48:35 <vipul> ok, cool.. we've got some internal folks writing jclouds bindings
22:48:42 <hub_cap> im 95% done w/ my cinder work. ill have something by next meeting for sure
22:48:44 <vipul> they would help there in the docs area too
22:48:56 <hub_cap> #action start the markdown for the api
22:49:07 <hub_cap> vipul: nice!! ill make it a prio for end of wk
22:49:35 <hub_cap> moving on then
22:49:50 <hub_cap> #topic client libs and pypi
22:50:01 <hub_cap> SlickNik: grapex discuss :)
22:50:22 <vipul> unfortunately i missed the conversation you guys had in infra .. scrollback lost it too
22:50:41 <grapex> SlickNik mentioned changing some stuff in openstack-ci.
22:50:53 <SlickNik> So talking with clarkb, there's an automated way for us to get CI to handle PyPi packaging for reddwarfclient
22:51:24 <SlickNik> Haven't started working on it yet, but wanted to talk to grapex + others so we can hook into this and not have to do it by hand.
22:51:45 <hub_cap> vipul: thats logged
22:51:56 <hub_cap> #link http://eavesdrop.openstack.org/irclogs/
22:51:57 <vipul> oh where!
22:52:05 <vipul> lifesaver
22:52:05 <hub_cap> wtf infra isint logged??!?!?!??!?!
22:52:07 <grapex> SlickNik: So does it push to PyPi on each successful commit?
22:52:12 <SlickNik> It works of off git tags, where you can tag a particular commit with a version and it builds the pkg and uploads to PyPi
22:52:13 <vipul> spoke too soon :p
22:52:23 <SlickNik> So it doesn't do it on every commit.
22:52:38 <grapex> Any rules concerning the frequency of tags?
22:52:56 <SlickNik> Nope, that would be up to us, was what I gathered from clarkb.
22:53:01 <hub_cap> seems fine to me
22:53:11 <juice> sounds great
22:53:23 <vipul> Yea, let's make it happen, since we use the client in our tests, we'll want to automate this
22:53:44 <cp16net> for sure
22:53:45 <SlickNik> Okay, there's a bit of work to be done with the Jenkins Job builder and scripts, but I think that it's all goodness and we should go ahead with it.
22:53:53 <vipul> what about the tag naming scheme?
22:53:57 <grapex> Me too. So for versions, they mentioned the date was being dropped and the clients just use numbers now. Does the version increment each time a new tag is applied automatically or does it get retained across multiple pushes?
22:54:04 <vipul> #action SlickNik to look into automated release of python-redwarfclient
22:54:11 <hub_cap> horray
22:54:22 <datsun180b> second that hooray
22:54:32 <SlickNik> I need to talk to clarkb about that, I wonder if the numeral scheme (instead of date) is a limitation of the system or not.
22:54:48 <vipul> so i noticed that some of the client use openstack/common/version.py
22:54:49 <grapex> IIn the interim, should we push one more time?
22:54:53 <vipul> we may have to bring that in
22:54:54 <SlickNik> I'll post with more info on #reddwarf once I dig a bit deeper and know more.
22:55:03 <hub_cap> seems like thats still fuzzy and yes grapex lets manually push every time we need to for now
22:55:20 <hub_cap> if we have a feature that depends on something being pushed then hellz yes we push
22:55:22 <grapex> Ok... so speaking of my mistake in bumping the date. Or we ok with keeping that for now?
22:55:26 <vipul> if the version is completely based off tag name.. then i suggest something like 1.0.x
22:55:26 <hub_cap> same version for now is ok
22:55:31 <vipul> where 1.0 = v1.0 api
22:55:33 <grapex> Like can I push again to 2013.2.6?
22:55:43 <hub_cap> oh hmmmmmm
22:55:46 <hub_cap> i hope its not like debian
22:55:56 <hub_cap> 1.0 < 2013.X
22:56:01 <vipul> heh
22:56:10 <hub_cap> lexically :)
22:56:12 <vipul> yea but that's what i've seen the other CLIs
22:56:21 <vipul> 1.0 / 2.6.x... etc
22:56:23 <hub_cap> vipul: im not saying your idea is bad at all
22:56:35 <hub_cap> im just saying we might have a gotcha for existing users (us)
22:56:43 <hub_cap> new version might not auto download for existing vms
22:56:49 <hub_cap> just something to be aware
22:56:53 <vipul> we could delete from pipy?
22:57:01 <vipul> older versions
22:57:03 <hub_cap> im not sure it'd matter if it was already local
22:57:07 <hub_cap> but im speculating
22:57:07 <vipul> hmm
22:57:16 <grapex> The client has only been there since December
22:57:23 <hub_cap> like apt, if its local and installed and > then whats in the repo, version wise, then it wont download
22:57:24 <vipul> maybe we just bite the bullet now
22:57:32 <hub_cap> vipul: i think so
22:57:37 <vipul> our userbase is small.. likely
22:57:46 <cp16net> yeah make an action for checking that out when we push the new vesion
22:57:48 <hub_cap> grapex: name it 1.0.0 if everyone is cool w/ that
22:57:53 <grapex> Ok
22:58:01 <cp16net> and hope it doesnt break :)
22:58:08 <SlickNik> yeah personally, I like being consistent (using the date across both projects). I'd rather not change unless we're forced to by the CI system or some other compelling reason...
22:58:08 <hub_cap> if it does itll just break us
22:58:20 <hub_cap> across both projects?
22:58:38 <SlickNik> I guess server and client. Server is using date, right?
22:58:39 <cp16net> yeah i agree with SlickNik
22:58:42 <vipul> other projects are already different between the actual project being 2013.x and CLI being 2.x.x
22:58:42 <grapex> SlickNik: Should we do an action item to get confirmation from the CI team that version changing is required?
22:58:51 <hub_cap> is server in pypi?
22:59:03 <SlickNik> no, I mean reddwarf API
22:59:03 <vipul> not sure.. but it is on ubuntu's repo
22:59:11 <hub_cap> http://pypi.python.org/pypi?%3Aaction=search&term=python-nova&submit=search
22:59:16 <hub_cap> nova server is not in pypi
22:59:34 <hub_cap> crap im wrong its just "nova"
22:59:42 <vipul> http://wiki.openstack.org/Releases
22:59:47 <hub_cap> and the server/client do not follow the same release pattern
22:59:53 <vipul> right
23:00:00 <hub_cap> http://pypi.python.org/pypi/nova/2013.1
23:00:03 <hub_cap> http://pypi.python.org/pypi/python-novaclient/2.10.0
23:00:11 <vipul> i have no iea how thye come up with 2.10
23:00:14 <hub_cap> so i think its a-ok to move reddwarfclient now
23:00:16 <hub_cap> vipul: i know....
23:00:22 <hub_cap> all of them are so different
23:00:36 <cp16net> i dont think it would matter really then
23:00:43 <clarkb> so the reason the existing clients don't do dates is they don't follow the same release cycles
23:00:54 <clarkb> and the servers don't quite do dates. its year.release
23:01:06 <vipul> so what's the pattern for client version clarkb
23:01:10 <hub_cap> clarkb: is there any methiod to the madness of the major version?
23:01:21 <SlickNik> hi clarkb, thanks for jumping in.
23:01:49 <hub_cap> im thinking we should go version 4.20.X
23:01:53 <hub_cap> :D
23:01:57 <clarkb> the mattern is x.y.z then different clients bump numbers as appropriate for them
23:02:02 <juice> vipul: perhaps they wanted to be more like ubuntu
23:02:08 <clarkb> the versions all independent across clients and are independent of the servers
23:02:21 <vipul> the version number doesn't correlate to api version either?
23:02:26 <hub_cap> i think what we are wondering if how to define where we start from. 0.X, 1.X, 2.X, since they are all diff
23:02:37 <clarkb> vipul: it might but I don't think so as the clients are supposed to remain backward compatible
23:02:47 <juice> there should be some way to correlated server and client compatibility by way of version number no?
23:02:59 <vipul> doens't look like it
23:03:00 <clarkb> juice: you would think so :)
23:03:13 <hub_cap> ok 4.20.X it is then :)
23:03:14 <juice> at least keep the major and minor revision the same and inc the patch
23:03:17 <cp16net> lol
23:03:18 <vipul> lots of documenation :)
23:03:19 <SlickNik> lol
23:03:29 <vipul> and we agree never to change the major and minor
23:03:32 <vipul> lol
23:03:34 <hub_cap> def
23:03:38 <clarkb> I am sure mordred and ttx have all sorts of addition info if you want to get them started
23:03:47 <hub_cap> its such a high number that we can stay on it for a while
23:03:50 <clarkb> versioning is really their thing
23:03:54 <hub_cap> /rimshot
23:03:56 <juice> maj.min.patch.build
23:04:14 <cp16net> hub_cap: i hit it...
23:04:21 <hub_cap> <3
23:04:22 <grapex> clarkb: Do the clients follow the official API version numbers used in the docs for major and minor?
23:04:32 <hub_cap> lets just roll w/ 0.1.X for now, we can always update it to a larger number when we have a better idea
23:04:40 <clarkb> grapex: I don't think so as many clients are still on 0.x version
23:04:57 <clarkb> but that could be due to not having a completely working api v1 set of features yet
23:05:07 <clarkb> hub_cap: ++
23:05:08 <vipul> which is where we are
23:05:16 <vipul> so agree with hubcap.. 0.x.x
23:05:20 <SlickNik> #agreed
23:05:22 <vipul> until we move on to v1.1
23:05:25 <SlickNik> too much time spent on this already :P
23:05:29 <grapex> clarkb: Ok, makes sense - plus the clients might strictly support all of an API spec
23:05:34 <hub_cap> cool
23:05:38 <vipul> versioning is always a long discussion
23:06:28 <SlickNik> I think it's one of those bike-shedding areas. Everyone understands versioning and has an opinion about it… :)
23:07:19 <hub_cap> yup. lets 0.1.x it and move on
23:07:21 <vipul> #info using 0.1.x for reddwarfclient
23:07:26 <hub_cap> tim put 0.1.1 for the next push
23:07:32 <hub_cap> OH GOD WHOS TIM
23:07:34 <SlickNik> lol @ tim
23:07:35 <hub_cap> grapex:  ^ ^
23:07:55 <grapex> hub_cap: Ok... but before we leave the bike shed, how about 0.1.0?  :)
23:08:20 <hub_cap> works for me grapex anyone have issues w/ 0.1.0?
23:08:23 <grapex> And also lets put a hyphen and then a random animal name after each one too
23:08:33 <vipul> make sure they are in alphabetical order
23:08:35 <grapex> ... sorry guys, I just can't help myself!
23:08:46 <grapex> Ok, let's leave it at that with no animals
23:08:48 <hub_cap> 0.1.0-@aardvark
23:09:04 <vipul> ok good
23:09:06 <vipul> move on
23:09:11 <hub_cap> #topic Advertising Reddwarf in the Community
23:09:18 <hub_cap> i think cp16net had some ideas about it
23:09:40 <vipul> just wanted to throw this in.. we had a Openstack Meetup in seattle about 2 weeks ago... topic was Reddwarf
23:09:48 <vipul> i guess that's adversitising :p
23:10:02 <cp16net> I noticed we have not put meeting announcements on the mailiing lists
23:10:14 <cp16net> or twitterverse or other areas
23:10:24 <grapex> cp16net: Great point, we need to get more active on the mailing list.
23:10:31 <vipul> cp16net: yup, we should def be doing more there
23:10:46 <cp16net> yeah and then even follow up with the minutes after the meeting is over
23:10:50 <vipul> even these blueprint discussions we're having, some of those should be pushed in ML
23:10:57 <cp16net> so its not just hp and rack working on this
23:11:06 <hub_cap> #agreed to all of that
23:11:09 <cp16net> we can help recruit some others to come in and get involved.
23:11:41 <cp16net> i'd be willing to get some of this started
23:12:02 <vipul> yep, so let's do this who ever is running the meeting that week is responsible for sending out recap?
23:12:03 <cp16net> glad we all agree
23:12:07 <cp16net> #agreed
23:12:14 <vipul> what about reminder before meeting?
23:12:18 <SlickNik> Is the recap just the minutes?
23:12:25 <vipul> link to the minutes.. mostly
23:12:31 <cp16net> yeah usually i see that on the list
23:12:48 <hub_cap> ill gladly send out a email in teh am on tuesdays
23:12:52 <hub_cap> adn then link the minutes after
23:12:55 <mordred> hub_cap: aroo?
23:12:55 <vipul> ok cool
23:13:19 <hub_cap> mordred: mostly kang but sometimes aroo
23:13:20 <cp16net> nice i just gave you more stuff to do hub_cap :-P
23:13:28 <SlickNik> oh hai, mordred.
23:13:38 <hub_cap> cp16net: no bigs
23:14:09 <vipul> larger blueprints, we should make an effort (whoever wrote the BP) to push it out to mailing list
23:14:35 <hub_cap> +1 vipul
23:14:39 <SlickNik> #agreed, that's a good way to get some involvement
23:15:07 <mordred> hub_cap: versions: all numbers and dots in the tag == final release - any letters in tag == pre-release
23:15:33 <mordred> such as - git tag -s 1.0.0 will do a final relase - git tag -s 1.0.0.a1 will do a pre-release
23:16:01 <cp16net> oh and when versions are pushed updated as well
23:16:21 <grapex> mordred: Does this process work with gerrit? So you tag it and then run "git review"?
23:16:22 <hub_cap> mordred: how do they differ from a artifact standpoint
23:16:29 <hub_cap> do they all get pushed to pypi?
23:17:07 <vipul> mordred: do we also need to pull in oslo/common/versions.py into the client?
23:19:10 <vipul> open it up ?
23:19:43 <mordred> grapex: you just tag and do git push --tags
23:19:54 <mordred> vipul: youshould
23:20:08 <grapex> morded: Does that mean we need access to the stackforge repo?
23:20:09 <mordred> hub_cap: releases go to pypi. pre-releases only get published to tarballs.o.o
23:20:19 <hub_cap> perfect thx mordred
23:20:30 <mordred> grapex: the person who is going to be pushing tags should have tag acls set in gerrit
23:20:48 <grapex> morded: I see.
23:21:11 <clarkb> mordred: no, please don't push all tags
23:21:13 <SlickNik> clarkb/mordred: Where do the tarballs get released to?
23:21:20 <clarkb> inevitably you will push a tag you don't want pushed
23:21:27 <clarkb> only push the tag you intend on pushing
23:21:33 <clarkb> SlickNik: tarballs.openstack.org
23:21:38 <mordred> https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/gerrit/acls/stackforge/python-reddwarfclient.config
23:22:01 <mordred> also - listen to clarkb
23:22:13 <SlickNik> thanks clarkb
23:22:31 <mordred> if you look at: https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/gerrit/acls/openstack/python-keystoneclient.config
23:22:43 <mordred> you'll see the refs/tags/* section
23:22:59 <cp16net> ahh nice
23:23:12 <cp16net> need to update that
23:23:17 <vipul> do we need to push to that repo? or let someone in CI take care of that?
23:23:39 <clarkb> you do it :)
23:23:53 <vipul> #info https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/gerrit/acls/openstack/python-keystoneclient.config sample push ACL
23:24:32 <SlickNik> Sweet, sounds good. clarkb
23:24:54 <vipul> ok i think the only open question is can have pip pull from tarballs?
23:25:14 <vipul> some tests in reddwarf use the client..
23:25:22 <vipul> and we'd have to have it grab latest from there
23:25:41 <grapex> vipul: You can test locally by altering the PYTHON_PATH environment variable.
23:25:41 <SlickNik> Yes, you can
23:25:54 <hub_cap> should we move this to #reddwarf?
23:26:07 <grapex> My bad, it's PYTHONPATH
23:26:14 <vipul> yes, wanna open it up for discussion?
23:26:17 <SlickNik> sounds good.
23:26:27 <hub_cap> ya
23:26:31 <hub_cap> #topic open discussion
23:26:34 <SlickNik> move this to #reddwarf after open discussion.
23:26:44 <hub_cap> not including versioning
23:26:52 <hub_cap> :)
23:27:16 <vipul> ok just wanted to update dkehn, since he's not here: https://review.openstack.org/#/c/21549/
23:27:26 <vipul> close to getting the vm gate merged in
23:27:39 <vipul> #link https://review.openstack.org/#/c/21549/
23:28:15 <SlickNik> Yeah, looking forward to that! :)
23:28:21 <grapex> Nice!
23:28:38 <vipul> that's the only thing i had
23:28:41 <hub_cap> nice
23:28:47 <hub_cap> im good too
23:28:54 <SlickNik> I'm good as well.
23:29:00 <vipul> call it goo
23:29:02 <vipul> good
23:29:16 <SlickNik> to #reddwarf it is then!
23:30:02 <hub_cap> #endmeeting