21:02:29 <ttx> #startmeeting
21:02:30 <openstack> Meeting started Tue Aug  2 21:02:29 2011 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:02:42 <ttx> Welcome to our weekly OpenStack team meeting...
21:02:51 <ttx> Today's agenda is at:
21:02:56 <ttx> #link http://wiki.openstack.org/Meetings/TeamMeeting
21:03:10 <notmyname> when do we add incubated projects to the agenda?
21:03:29 <jaypipes> notmyname: sorry, that was my action item I think when ttx was away.
21:03:30 <vishy> i'm here
21:03:57 <ttx> notmyname: ah. We can have an incubated news topic, after Nova
21:03:58 <jaypipes> ttx: my apologies.  dropped the ball on that one. I was supposed to make sure dash and keystone were updating on this meeting.
21:04:01 <ttx> willdo
21:04:11 <ttx> #topic Postmortem feedback for 1.4.2/diablo-3 release
21:04:24 <ttx> Last week we released Swift 1.4.2 and the diablo-3 milestone for Glance/Nova
21:04:38 <ttx> It went well, though we had a bit of delay for diablo-3 to try to sneak some Glance bugfixes
21:04:51 <ttx> Anything that went wrong from your perspective and that we need to fix ?
21:05:17 <jaypipes> ttx: https://blueprints.launchpad.net/openstack-ci/+spec/glance-upgrade
21:05:29 <jaypipes> ttx: we need to work on that one for next milestone release...
21:05:45 <ttx> sounds like a good idea
21:05:56 <ttx> jaypipes: we also need a bzr-tarball-delta job
21:06:09 <ttx> that would have caught the absence of glance-scrubber early
21:06:12 <jaypipes> yup.
21:06:36 <ttx> we have a CI bug for that. mtaylor: do you prefer a Blueprint ?
21:06:48 <ttx> anything else ?
21:07:14 <mtaylor> ttx: bug is fine
21:07:18 <ttx> #topic Swift status
21:07:23 <ttx> notmyname: o/
21:07:32 <ttx> Do you have a timeframe for 1.4.3 already ?
21:07:34 <notmyname> 1.4.2 is done
21:07:42 <notmyname> I was looking at 1.4.3 today
21:07:45 <mtaylor> Vek: sorry, reading scrollback - in the new world order, you will get an email
21:07:50 <ttx> diablo-4 is scheduled on August 25, in case you want to align :)
21:08:15 <notmyname> I think we will have time for only one more release before diablo (the version that will be in diablo) and still have time for docs, etc
21:08:36 <notmyname> I was thinking sometime around the first week of september, but I haven't settled on anything yet
21:08:45 <ttx> yes, makes sense
21:08:48 <notmyname> 8-25 is a good date to know. I'll keep it in mind
21:08:55 <ttx> notmyname: Any features already planned for that version ?
21:09:47 <notmyname> nothing big. whatever we can get done. we've finished everything that was promised for diablo, so I expect 1.4.3 to simply be bug fixes and perhaps a few small things. we're investigating time-limited files, for example
21:10:09 <ttx> would be a cool feature, indeed
21:10:14 <notmyname> indeed
21:10:24 <ttx> notmyname: Other announcements/comments ?
21:10:37 <notmyname> ya
21:11:18 <notmyname> I hope that scaling down swift deploys can be done in essex (deploy on <5 servers). we need community input there
21:11:53 <ttx> you need input before the design summit ?
21:11:59 <notmyname> it's something that's needed, but not something current devs have a lot of insight to since we have existing, large clusters
21:12:01 <notmyname> no
21:12:15 <notmyname> nothing needed before the design summit
21:12:39 <ttx> Raise your hand if you have questions on Swift...
21:12:47 <notmyname> also, I guess PTL elections are coming soon, so get your commits in if you want to vote
21:12:56 <heckj> 0/
21:12:56 <jaypipes> notmyname: I might have some input for you on that with FreeCloud... I'll ley you know.
21:13:11 <ttx> notmyname: I committed version changes, does that count ? :)
21:13:18 <heckj> What's the status of keystone authN integration with Swift?
21:13:18 <jaypipes> lol
21:13:23 <notmyname> ttx: I think you're already there :-)
21:13:28 <ttx> cool!
21:13:35 <notmyname> heckj: great question! ask the keystone people :-)
21:13:45 <Vek> heckj: there's a middleware checked in to keystone; that's about all I know.
21:13:58 <heckj> notmyname: swift is already to go once Keystone finishes something?
21:14:08 <notmyname> heckj: as far as we know
21:14:24 <heckj> notmyname: cool, thanks
21:14:32 <ttx> +#topic Glance status
21:14:37 <ttx> ow
21:14:41 <ttx> #topic Glance status
21:14:41 <jaypipes> https://launchpad.net/glance/+milestone/diablo-4
21:14:53 <ttx> Looks good to me...
21:14:55 <jaypipes> We're kickin' ass on D4.
21:15:12 <ttx> jaypipes: keystone integration blocks another diablo-4 spec, how far is it ?
21:15:37 <jaypipes> thx to the Brians, Vek, s1rp, jkoelker, and johan
21:15:55 <jaypipes> ttx: Vek needs to complete a functional test with auth spun up.
21:16:02 * Vek threw a glance_auth_token.py middleware into keystone
21:16:22 <ttx> jaypipes: Announcements, comments ?
21:16:38 <jaypipes> ttx: we need to have a common way of starting Keystone servers, daemonized when there could be other keystone servers runing on the box...
21:16:52 <jaypipes> ttx: basically, what glance-control gives us in Glance (and swift-init in Swift)
21:17:27 <jaypipes> ttx: no announcements. currenlty a few outstanding packaging things mtaylor is working on. we're looking good to hit D4.
21:17:35 <ttx> ok
21:17:41 <ttx> Raise your hand if you have a question on Glance.
21:17:43 <jaypipes> ttx: oh, and moving to Gerrit/GH on Thursday morning. That little thing. :)
21:17:53 <ttx> bah! almost nothing.
21:18:03 <jaypipes> heh
21:18:09 <mtaylor> piece of cake
21:18:37 <ttx> #topic Nova status
21:18:44 <ttx> vishy: yo!
21:18:48 <vishy> heyo!
21:18:52 <ttx> Looking at https://launchpad.net/nova/+milestone/diablo-4
21:19:04 <ttx> Still a bit work in progress, with some specs being added
21:19:19 <ttx> like the networking integration stuff that is being split into more trackable bits
21:19:50 <ttx> vishy: I hope that we can get it into order by the end of the week ?
21:20:06 <danwent> ttx: just broke up the blueprints today
21:20:12 <vishy> yes
21:20:20 <ttx> vishy, soren: I had one question already, about EC2 Id compatibility
21:20:21 <danwent> should be able to merge prop at least one of them in the next few days
21:20:23 <vishy> blueprints should be prioritized properly in the next couple of days
21:20:34 <ttx> vishy, soren: do we have a clear plan forward there ?
21:20:48 <ttx> vishy, soren: it's marked essential, so I'm getting nervous
21:21:28 <ttx> because from where I stand it's still very much under discussion.
21:21:37 <vishy> I'm actually comfortable shipping without changes and saying that ec2_api is only supported in one zone configs
21:21:57 <soren> Me too.
21:21:57 <ttx> vishy: ok, so we can at least downgrade to "High"
21:22:08 <soren> It's not "essential" for sure.
21:22:13 <ttx> soren: ok, so we can at least downgrade to "Medium" :)
21:22:34 * ttx sets to "High" to drop some pressure
21:22:41 <vishy> soren: iirc you were opposed to the idea of a mapping layer at the top for ec2_ids
21:22:54 <vishy> soren: although I still think it is the easiest way forward
21:23:38 <ttx> danwent: saw that, thanks.
21:24:03 <soren> vishy: I think that's a dreadful idea, yes.
21:24:35 <jaypipes> well, at least you don't feel that strongly, soren. :)
21:24:42 <comstud> haha
21:24:48 <vishy> could also use someone for this blueprint: https://blueprints.launchpad.net/nova/+spec/aws-api-validation
21:24:49 <comstud> I'm not sure I've seen a better idea.
21:24:57 <soren> vishy: ...but hardly anyone seems to care about the EC2 API, so there seems to be little chance of going any other route.
21:25:20 <ttx> soren: what would be an alternate solution ?
21:25:47 <tr3buchet> jaypipes: nice one ;)
21:25:48 <vishy> ttx: we discussed it in great detail in the ml thread.
21:25:49 <soren> ttx: Using an ID generation mechanism that doesn't require one of our API's to have its own mapping system.
21:26:13 <ttx> soren: which involves chaging the rest of Nova again. gotcha
21:26:20 <soren> ttx: I don't think I'm int he sort of mood where I can give an objective run-down of the options.
21:27:16 <ttx> soren: wel, you can't be asked to implement a solution you find dreadful, so at the very least, that would need to be reassigned
21:27:25 <jaypipes> soren, vishy: is this something that can be resolved in the next few days?
21:28:10 <comstud> soren: I agree with that train of thought, it just feels rather limiting given how ec2 instance ids are used.
21:28:27 <soren> ttx: It does seem natural that the person who actually seems to care about the EC2 API actually makes sure it works.
21:28:53 <ttx> soren: fair enough
21:28:55 <jaypipes> soren: there's more than you that care about the EC2 API, trust me. Lots of NTT folks do as well.
21:29:01 <soren> jaypipes: I doubt it. I've given up pursuing happiness on that particular endeavour.
21:29:18 <jaypipes> soren: ok then. let's shelve this for offline.
21:29:32 <ttx> ok -- In all cases, the diablo-4 plan should result in a lot of branches landing.
21:29:45 <ttx> We need to propose early and review early, and merge what can be merged asap
21:30:12 <ttx> For example, comments on the last part of boot-from-volume have apparently been adressed:
21:30:17 <ttx> https://code.launchpad.net/~yamahata/nova/boot-from-volume-2/+merge/68496
21:30:28 <ttx> blamar, devcamcar, other nova-core: please rereview it and get it off the table if it's ready.
21:30:37 <ttx> vishy: more comments ?
21:31:05 <vishy> just main focus on early reviews would be great, since we're trying to get a lot of stuff in
21:31:27 <ttx> Questions for Nova PTL ?
21:31:56 <ttx> #topic Post-D4 branch handling for Nova and Glance
21:32:12 <ttx> jaypipes, vishy: I want to discuss how to handle the post-d4, feature-frozen pre-diablo-release timeframe
21:32:23 <ttx> Like I already told you in May, I think we have two options:
21:32:37 <ttx> "Long" one: No more Diablo features after August 22, which is when the diablo-4 milestone branch needs to be created
21:32:52 <ttx> We use the last milestone branch as the 2011.3 release branch. Trunk development switches to Essex.
21:33:07 <ttx> Unrestricted bugfixes land in release branch and get ported to trunk, until we switch to targeted bugfixes
21:33:22 <ttx> (after that only specific fixes land in release branch and get ported to trunk, others go directly/only to trunk).
21:33:36 <ttx> "Short" one: Features should have landed by diablo-4, but 2011.3 release branch is only cut on September 8th
21:33:48 <ttx> so what lands in Diablo remains in pure nova-core control for two more weeks
21:34:02 <ttx> After that date only targeted bugfixes are accepted, and trunk development switches to Essex
21:34:19 <ttx> Advantages of long one: diablo-4 contains all features and serves as beta. Trunk is always open(though switched to Essex early)
21:34:34 <ttx> Drawbacks of long one: August 22 is early. 4 long weeks of tracking and proposing bugfixes to two parallel branches
21:34:49 <ttx> Advantages of short one: More team focus on bugfixes. "Only" two weeks of parallel branches
21:34:55 <jaypipes> ttx: I would prefer the shorter one for Glance.
21:35:04 <ttx> Drawback of short one: Features are not very welcome in trunk for 2 weeks (soft feature freeze)
21:35:16 <ttx> jaypipes: i also kinda prefer the short option
21:35:23 <jaypipes> vishy: ?
21:35:36 <vishy> short
21:35:42 <ttx> but it runs a bit counter to the "always open trunk" philosophy we decided at the design summit
21:35:58 <ttx> If you both are comfortable with a soft feature freeze, then I'm ok too
21:35:59 <vishy> true
21:36:10 <jaypipes> ttx: sure, but this is only once every 6 months...
21:36:18 <ttx> and only two weeks.
21:36:20 <jaypipes> ttx: and the goal here is integration with other projects and bug fixing...
21:36:34 <jaypipes> and testing
21:36:36 <vishy> i've noticed that merging in fixes is a little painful because people don't often make them off of the release branch
21:37:01 <vishy> so you have to rebase the changes and repropose them against the release branch, which also creates divergent history
21:37:06 <jaypipes> yep.
21:37:32 <jaypipes> vishy: and the long option would only make that process longer...
21:37:43 <vishy> right
21:37:59 <vishy> so not merging features into trunk for two weeks seems ok
21:37:59 <ttx> OK, let's go with "short" and try to see how to we can simplify dual-proposal process
21:38:18 <vishy> its not as if they can't still propose them for review to get eyes on them
21:38:34 <ttx> vishy: right, at least postpone merging them for a couple weeks, until Essex opens.
21:38:42 <jaypipes> ya
21:38:54 <ttx> #topic Incubated projects news
21:39:13 <jaypipes> devcamcar: anything on dash you want to bring up?
21:39:15 <zykes-> is quantum incubated yet ?
21:39:22 <jaypipes> zykes-: nope.
21:39:29 <jaypipes> zykes-: keystone and dashboard right now.
21:39:32 <zykes-> ah
21:39:37 * jaypipes searches for zns..
21:39:39 <ttx> zykes-: not proposed yet.
21:40:02 <danwent> zykes: you can stay in the room for the quantum discussion at the top of the hour
21:40:31 <zykes-> danwent: ?
21:40:35 <zykes-> ah
21:40:56 <ttx> ok, sounds like nobody is there from incubated projects
21:41:03 * jaypipes asked dolphm to join us for a status update on keystone.
21:41:05 <Vek> jaypipes is trying to get one
21:41:21 <jaypipes> dolphm: welcome!
21:41:22 <ttx> I'll make sure they get the news that they have a meeting topic now :) This was added a bit late.
21:41:27 <dolphm> jaypipes: thank you
21:41:49 <jaypipes> dolphm: wondering if you want to update the community on keystone? anything you want to say about progress made, etc?
21:42:36 <dolphm> hmmm... i don't have too much to say...
21:42:56 <jaypipes> dolphm: ok, no worries if you don't. just wanted to give you all an opportunity.
21:43:15 <jaypipes> dolphm: is there anything that the community can assist you with? anything you want to bring up regarding Gerrit?
21:43:21 <dolphm> i'm glad to be on gerrit / jenkins - that's pretty much the story of my week
21:43:25 <ttx> dolphm: Does Keystone rock ?
21:43:38 <dolphm> ttx: yes, by default
21:43:40 <ttx> ok, that's the spirit !
21:43:42 <jaypipes> lol :)
21:43:51 <jaypipes> ok, enough harrassing dolphm
21:44:00 <Vek> it's a specially shaped rock, in fact.
21:44:07 <jaypipes> heh
21:44:08 <ttx> #topic Open discussion
21:44:13 <primeministerp1> hey all
21:44:14 * ttx opens the bar
21:44:18 <creiht> and one rock to bind them....
21:44:22 <primeministerp1> brief note on hyper-v wins
21:44:37 <ttx> primeministerp1: I like wins.
21:44:38 <comstud> ttx: i have a nova scalability issue i'd like to point out
21:44:50 <ttx> primeministerp1: go first
21:44:53 <primeministerp1> we'll be discussing the hyperv/openstack cloud in the interop lab at novell's brainshare in october
21:44:55 <Vek> for "sucks" report: trying to merge code that depends on features that have been added to something else.
21:45:14 <jaypipes> primeministerp1: ++ w00t.
21:45:17 <primeministerp1> hopefully we'll also be discussing it during the upcoming openstack conf as well
21:45:26 <ttx> primeministerp1: where/when is that exactly ?
21:45:30 <primeministerp1> so the novell one
21:45:37 <primeministerp1> is in Salt Lake City
21:45:46 <primeministerp1> the week after the openstack conf in boston
21:46:04 <primeministerp1> ideally we present the same material in both
21:46:33 <primeministerp1> so not really sure what the venu will be like, but it's a good opportunity to spread the word
21:46:50 <ttx> primeministerp1: is that a brainstorming discussion, or a full-fledged presentation ?
21:47:02 <primeministerp1> full fledged presentation
21:47:08 <ttx> ok, so more for the conference
21:47:12 <primeministerp1> yes
21:47:24 <primeministerp1> so I figure we can talk about the brief history
21:47:26 <ttx> primeministerp1: the CTP should go out any time now
21:47:27 <primeministerp1> what we did
21:47:28 <primeministerp1> etc
21:47:49 <ttx> comstud: ok, bad news now
21:48:01 <primeministerp1> ttx: great i'm planning on emailing spectorclan tomorrow about it
21:48:04 <comstud> ok.. we have a bug: lp797770
21:48:17 <vishy> Vek: agreed, this is why I've been loathe to break out projects willy nilly
21:48:18 <comstud> socket closed errrors on high load
21:48:21 <ttx> bug 797770
21:48:22 <uvirtbot> Launchpad bug 797770 in nova "'Socket closed' during API stress test" [High,Confirmed] https://launchpad.net/bugs/797770
21:48:46 <ttx> comstud: bug which I'd like to see fixed before release, yes
21:48:55 <comstud> was talking with eday... we've determined that the mysql engine sqlalchemy is using by default uses the mysql C library
21:49:05 <comstud> so it's using libc socket calls...
21:49:08 <comstud> eventlet cannot wrap these.
21:49:17 <comstud> this means that any calls to mysql block until completed
21:49:33 <Vek> *cough*
21:49:40 <ttx> *cough*
21:49:46 <comstud> right
21:49:56 <comstud> so eventlet can't switch greenthreads and do other things while mysql queries are in progress
21:50:04 <ttx> comstud: your "by default" seems to imply there is a solution
21:50:04 <zykes-> ttx: is there any like "events.openstack.org" ?
21:50:08 <comstud> there _is_ a 'pymysql' engine option for sqlalchemy...
21:50:16 <comstud> it's a purely python module... but I'm not sure of it's stability
21:50:25 <ttx> zykes-: hrm... maybe
21:50:27 <creiht> comstud: you could put the db operations in a thread pool
21:50:38 <comstud> creiht: Or that was my other suggestion :)
21:50:39 <creiht> just another option
21:50:49 <comstud> assuming the C code will unlock the GIL
21:50:55 <comstud> which I'm sure it probably does
21:50:56 <Tv_> i've heard others use the thread pool trick
21:51:05 <creiht> we do that for the sqlite dp operations in swift
21:51:09 <creiht> db
21:51:23 <Tv_> i mean specifically to get around the gevent/eventlet issue
21:51:35 <comstud> In any case.. it's possible using 'mysql+pymysql://' for the engine will get around the current issue... but I've been unable to verify it so far.
21:51:47 <comstud> I just wanted to make ppl aware of this
21:51:57 <Vek> what's keeping you from verifying it?
21:52:16 <comstud> Vek: time... ant tried, but got some weird exception
21:52:22 <ttx> comstud: thanks for the heads-up
21:52:24 <comstud> I plan to look at it in the next couple of days
21:52:26 <Vek> 'k
21:52:34 <ttx> and for looking at that sort of bugs
21:52:38 <comstud> if this doesn't solve it, it's possible we may want to think about threads.
21:53:05 <ttx> zykes-: maybe http://openstack.org/community/events/
21:53:14 <creiht> comstud: http://eventlet.net/doc/modules/db_pool.html
21:53:15 <zykes-> 0ok
21:53:37 <creiht> abstracts some of that away, but not sure what would need to be done to make it work with sqla
21:53:49 <ttx> anything else before we close ?
21:53:57 <comstud> creiht: will take a look
21:54:27 <annegentle> I appreciate the Keystone guys keeping their doc updated in openstack-manuals!
21:54:48 <dolphm> annegentle: have we been doing that?!
21:54:52 <annegentle> :)
21:54:55 <Vek> haha :)
21:55:03 <creiht> lol
21:55:20 <ttx> on that good note...
21:55:25 <ttx> #endmeeting