21:01:50 <ttx> #startmeeting
21:01:51 <openstack> Meeting started Tue Oct 25 21:01:50 2011 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:02:04 <ttx> Welcome everyone to the weekly general meeting... Today's agenda is at:
21:02:08 <ttx> #link http://wiki.openstack.org/Meetings/TeamMeeting
21:02:18 <ttx> #info Please use #info #link #idea #action for a richer summary...
21:02:28 <ttx> #topic Actions from previous meeting
21:02:35 <ttx> * ttx to set up some survey monkey for summit feedback
21:02:48 <ttx> AFAICT the survey (common with Conference) should be launched today or tomorrow.
21:02:55 <ttx> it's out of my hands now
21:03:08 <ttx> All the other actions were DONE and we'll talk about them in each project status.
21:03:16 <ttx> zns: around ?
21:03:26 <zns> yep
21:03:30 <ttx> #topic Keystone status
21:03:34 <ttx> zns: Looking at:
21:03:35 <zns> Keystone status update:
21:03:36 <zns> - Many blueprints updated and targeted (more to come) - this was an action item from last week.
21:03:36 <zns> - Working on upleveling our commit quality. Getting good feedback (thanks anotherjesse). More blueprints, specs, and bugs are being authored on and will be targeted to the appropriate milestones.
21:03:36 <zns> - Documentation work for E0 making good progress.
21:03:36 <zns> - Implementation of Diablo API calls that were not implemented is going slower than expected, but making progress.
21:03:36 <zns> - We have updates in e0 that we'd like to back port to Diablo (especially bug fixes). But there are also schema changes which I think only belong in Essex, so we need to figure out how we can back port the fixes without the schema changes. Working on that.
21:03:36 <zns> - Big question on the table is are we trying to go to fast? We are going to focus on getting the implementation done and stabilizing, so that might delay how much we can deliver by E3 (our early freeze). Stability and continuity (i.e. migration scripts) come first given customers are using Diablo.
21:04:06 <ttx> so you decided to do a E0 ?
21:04:33 <zns> I'd like to get whatever bug fixes we have shipped for E0. No need for customers to live with bugs.
21:04:35 <zns> yes.
21:04:47 <jaypipes> zns: are you tracking a stable/diablo branch?
21:04:49 <ttx> I heard that essex trunk already contains backwards-incompatible changes wrt diablo
21:05:02 <ttx> so E0 can't be used as a bugfix release...
21:05:02 <zns> https://bugs.launchpad.net/keystone/+bugs?field.tag=diablo-backport
21:05:18 <ttx> zns: if taht's the case, you should rather tag something on the stable/diablo branch
21:05:24 <ttx> no ?
21:05:34 <jaypipes> zns: ok, good. have any been applied to a stable/diablo branch yet? (not sure they could be, considering the rate of change in Essex trunk)
21:06:17 <zns> ttx: I don't know - what do you think? Better to backport to 2011.3 or have people try to find out what is the latest stable release (is it E0, E1, ex…?). I thought having the last stable release be THE release was a decision in Boston…
21:06:51 <zns> … looking for your advice on this. We can do either...
21:07:09 <ttx> depends on what you want to do a milestone or release for...
21:07:23 <zns> Essex trunk BTW works with all core projects. But it has a schema change, which is the main issue...
21:07:36 <ttx> do you want to do a diablo+, i.e. only bugfixes over what you released as diablo ?
21:07:51 <devcamcar> zns: we do need stable diablo branch asap. I'm fielding a ton of bug reports on my side related to keystone. quite a bit of overhead for us...
21:07:54 <zns> My take is that we should only backport fixes. No API changes or schema updates/migrations.
21:08:11 <anotherjesse> I field this but https://bugs.launchpad.net/keystone/+bug/854425 is in the backports
21:08:13 <uvirtbot> Launchpad bug 854425 in keystone "schema normalization (token vs users/tenants)" [Low,Fix committed]
21:08:18 <anotherjesse> and is a schema change without migrations
21:08:31 <zns> devcamcar: what would help you best; an E0 release with schema changes or backport to Diablo without schema changes?
21:08:33 <devcamcar> zns: also for the schema changes I didnt see migrations
21:08:43 <devcamcar> what jesse said
21:08:57 <zns> I don't think we can do migrations for every milestone. That's a lot of work.
21:09:08 <anotherjesse> zns: disagree
21:09:10 <devcamcar> zns: backport without schema changes
21:09:13 <zns> Hence my thought we backport to Diablo and leave the schema changes in Essex.
21:09:14 <anotherjesse> migrations is how you do scheam change
21:09:15 <zykes-> ttx: just as a note i use keystone (latest from trunk) and i'm grately satisfied...
21:09:40 <devcamcar> zns: you should have migrations for every change, not every milestone
21:09:40 <_0x44> How are you changing the schema without a migration?
21:09:43 <ttx> zns: so you're after stable/diablo work and a tag there
21:09:47 <jaypipes> zykes-: yes, but unfortunately, if you do that with diablo packages of nova or glance, everything blows up.
21:09:47 <zns> zykes-: thanks. Did you migrate from Diablo?
21:09:49 <ttx> not after a E0
21:09:53 <anotherjesse> https://github.com/openstack/nova/tree/master/nova/db/sqlalchemy/migrate_repo
21:09:57 <anotherjesse> pretty easy to do migratinos
21:10:05 <zns> ttx: yes
21:10:09 <mtaylor> I would think in this case that the migration isn't as much of a practical issue because noone out there is probably running the diablo keystone because of the issues
21:10:13 <zykes-> jaypipes: uhm, i got nova + swift diablo and glance
21:10:15 <zykes-> works dandy
21:10:20 <mtaylor> so in GENERAL, things not having migrations is probably a good policy
21:10:26 <jaypipes> zykes-: nova and glance DIABLO packages...
21:10:28 <mtaylor> in this case, there is likely nothing large to migrate FROM
21:10:34 <ttx> ok, people calm down
21:11:00 <ttx> so the keystone folks need to work on stable/diablo, backport what can be, and tag/ cut a tarball from that
21:11:16 <zns> So should we do releases every milestone (with migrations if the schema changes)? anotherjesses: you run many production deployments. Thoughts?
21:11:17 <ttx> since it's diablo work, it's not a formal Essex milestone
21:11:34 <zykes-> jaypipes: yeah, i use the griddynamics packages for what was the core projects in the diablo release but keystone didn't work so i use it from trunk there
21:12:16 <ttx> discussion on specifics of what is relevant for each branch and not can go off-meeting
21:12:31 <anotherjesse> zns: my view is migrations should always be explicit
21:12:38 <anotherjesse> in released software or even if you are just running a service
21:12:57 <ttx> zns: I had a few questions about specs that may or may not be in your Essex plans:
21:13:05 <ttx> https://blueprints.launchpad.net/keystone/+spec/pluggable-protocols (marked deferred) ?
21:13:05 <zns> _0x44: changing the definitions in the model. That generates the schema in sqlalchemy.
21:13:06 <_0x44> anotherjesse: +N, where N is the number of potential schema changes
21:13:19 <_0x44> zns: ಠ_ಠ
21:13:24 <anotherjesse> python model introspection and creating a new sqlite database any time you touch keystone-manage is not a good idea
21:13:45 <ttx> https://blueprints.launchpad.net/keystone/+spec/2-way-ssl (targeted to essex-1 but not with series=Essex yet) ?
21:13:52 <ttx> https://blueprints.launchpad.net/keystone/+spec/service-endpoint-location (targeted to essex-2 but not with series=Essex yet) ?
21:14:05 <ttx> anotherjesse: looks like we could have an ML thread around that
21:14:12 <zns> ttx: OK. We'll fix those.
21:14:15 <ttx> I don't want to spend the hour on this
21:14:32 <ttx> zns: thx
21:14:52 <ttx> zns: So your plan for essex-1 is https://launchpad.net/keystone/+milestone/essex-1
21:14:55 <zns> anotherjesse, _0x44: shall we go off thread? Would love to get your thoughts on how to handle this better/in line with other projects.
21:15:02 <ttx> zns: Is that correct and on track (with 2 weeks left) ?
21:15:29 <devcamcar> zns: I'm happy to help as well
21:15:35 <ttx> About migrations / the best is to copy how other projects are doing it
21:15:51 <zns> ttx: yes. There are also additional changes we have not put in as separate BPs yet. Part of what we need to catch up on. They are calls in the Core API that were not yet implemented.
21:16:14 <ttx> zns: OK, I'll be in touch with you this week
21:16:19 <zns> devcamcar: thanks. I'll start a mailing list thread.
21:16:25 <ttx> I'd like to have finalized essex-1 plans by Thursday
21:16:38 <ttx> zns: Anything else ?
21:16:56 <zns> OK. No, nothing else.
21:16:58 <zns> Tx
21:17:22 <ttx> So in summary, two discussions are to be had around keystone -- migrations, and working on a diablo+ tag in the stable/diablo branch
21:17:32 <ttx> is that a fair summary ?
21:17:41 <devcamcar> lgtm
21:17:59 <ttx> when do you need that diablo+ tag ? last week ?
21:18:02 <zns> ttx: yes
21:18:17 <ttx> #agreed two discussions are to be had around keystone -- migrations, and working on a diablo+ tag in the stable/diablo branch
21:18:20 <zykes-> seems yogi is already working on backports? alot of mails raining in
21:19:06 <zns> zykes-: yes, he's working on it.
21:19:06 <ttx> ok, moving on to next project, then
21:19:14 <ttx> unless someone has a question ?
21:19:31 <ttx> #topic Swift status
21:19:37 <ttx> notmyname: o/
21:19:43 <notmyname> hi
21:19:46 <ttx> notmyname: Any hint on when you'll want to release 1.4.4 ?
21:19:54 <notmyname> when https://launchpad.net/swift/+milestone/1.4.4 is done
21:20:15 <ttx> ok, that's a complete plan ?
21:20:27 <ttx> (so far ?)
21:20:40 <notmyname> I'd like to see most of https://review.openstack.org/#q,status:open+project:openstack/swift,n,z done for 1.4.4
21:20:51 <notmyname> the milestone in LP covers most of that
21:21:24 <ttx> ack
21:21:30 <ttx> notmyname: Anything else ?
21:21:44 <notmyname> I don't think so.
21:21:48 <ttx> Questions on Swift ?
21:22:31 <ttx> #topic Glance status
21:22:32 <jaypipes> https://launchpad.net/glance/+milestone/essex-1
21:23:15 <ttx> jaypipes: had a few questions about https://blueprints.launchpad.net/glance/essex
21:23:21 <ttx> About protected-properties: what is it blocking on ?
21:23:49 <jaypipes> it's actually not going to be done at all. The 2.0 API proposal makes them irrelevant.
21:24:09 <ttx> ok, will mark superseded and remove from plan
21:24:25 <ttx> #action ttx to mark protected-properties superseded and remove from essex
21:24:26 <jaypipes> ttx: already done.
21:24:29 <ttx> rha$
21:24:36 <ttx> About changes-since-filter: it's marked "Needs Code Review" but I couldn't find a corresponding review.
21:24:48 <jaypipes> bcwaldon: ?
21:25:07 <ttx> I was wondering if it wasn't just merged already and should be added to essex-1
21:25:19 <bcwaldon> bah, sorry, I'm here
21:25:31 <jaypipes> ttx: no, there was a branch bcwaldon did for that, but not sure what happened with it
21:25:34 <bcwaldon> changes-since-filter is implemented
21:25:44 <bcwaldon> sorry for not updating the BP
21:26:05 <bcwaldon> that was done in diablo
21:26:26 <ttx> bcwaldon: you mean it's a hidden diablo feature ?
21:26:37 <jaypipes> ok, done.
21:26:44 <bcwaldon> ttx: it's in the 1.1 spec, so it would have been a bug if it weren't done
21:26:53 <ttx> bcwaldon: heh
21:26:55 <jaypipes> ttx: it was added to nova first, then glance afterwards made it actually efficient IIRC.
21:26:55 <ttx> jaypipes: Any other thing on your mind ?
21:26:58 <bcwaldon> ttx: just didn't make it into Glance release notes, I guess
21:27:24 <bcwaldon> jaypipes: it was *accepted* as a param in nova first, just didn't affect the result
21:27:25 <jaypipes> ttx: trying to get the 2.0 Images API proposal out to the ML soon.
21:27:33 <jaypipes> ttx: for an RFC period of about 3-4 weeks
21:27:49 <ttx> jaypipes: does one of your BP cover that ? Or is it still tbd ?
21:28:08 <jaypipes> ttx: after I get the API proposal out, I will create BPs for each subsequent change in the API that needs implemented...
21:28:33 <jaypipes> ttx: gotta get the proposal done first then I promise I will update the BPs to better represent the work.
21:28:40 <ttx> jaypipes: ok. Already have a milestone target for that ? essex-2/3 ?
21:28:45 <jaypipes> e2
21:28:54 <ttx> looks like a busy milestone :)
21:29:00 <jaypipes> yup.
21:29:19 <ttx> anyone: Questions on Glance ?
21:29:49 <ttx> #topic Nova status
21:29:56 <ttx> vishy: yo
21:30:07 <vishy> hy
21:30:09 <ttx> #link https://blueprints.launchpad.net/nova/essex
21:30:09 <vishy> * hi
21:30:16 <ttx> lot of activity today, still work in progress ?
21:30:20 <vishy> so I've been targetting like mad
21:30:24 <ttx> or seeing the end of the tunnel ?
21:30:29 <vishy> I'm very close to having everything in essex
21:30:31 <ttx> (the white light)
21:30:48 <vishy> prioritization and milestone targetting haven't happened in detail yet
21:30:55 <vishy> I did a first pass on the obvious ones
21:31:11 <ttx> vishy: as far as targeting goes, would be good to nail essex-1 first
21:31:12 <vishy> I'm going to send a message out to all the lists asking for help from the leads in targetting and cleanup
21:31:32 <vishy> I think there are a few duplicates still.  There were a lot of very crufty blueprints
21:31:36 <ttx> also would be good to convert those team assignments into real people :)
21:31:53 <ttx> the kind I can ping to death on IRC
21:32:10 <ttx> in doubt, I'll pig the team lead :P
21:32:30 <vishy> right
21:32:32 <ttx> vishy: how complete is https://launchpad.net/nova/+milestone/essex-1
21:32:43 <ttx> vishy: Is it complete or do you have more in mind ?
21:32:50 <vishy> probably pretty close actually
21:32:54 <vishy> just because it is coming up soon
21:33:01 <ttx> right, two weeks left
21:33:06 <ttx> So pci-passthrough and osapi-console-log need to be completed over the next two weeks
21:33:15 <vishy> both of those are in review now
21:33:19 <vishy> so i think they are ok
21:33:50 <vishy> if anything else gets added, it will likely be stuff that is already under review that i didn't notice
21:34:00 <ttx> oh, cool. btw, please use bp/* branch topics in Gerrit, so that we get magic links at http://wiki.openstack.org/releasestatus/
21:34:41 <ttx> that helps me in trying to update BP status for you
21:34:44 <vishy> all stuff that hasn't been started i expect to be targetted e2 or later
21:34:57 <vishy> ttx: yes I guess they didn't know how to do that
21:35:20 <ttx> Working on more auto-BP-updating from commit messages with jeblair
21:35:45 <ttx> vishy: Anything else ?
21:36:05 <vishy> ttx: I think that is it
21:36:27 <ttx> vishy: think you can have essex-1 plan in order by Thursday ? Looks almost ok to me
21:36:39 <ttx> (the rest of essex can wait a bit)
21:37:18 <ttx> Questions on Nova ?
21:37:35 <vishy> ttx: sure
21:37:52 <ttx> #topic Horizon status
21:37:57 <ttx> yay Horizon.
21:38:02 <ttx> devcamcar: o/
21:38:04 <devcamcar> hi!
21:38:11 <ttx> devcamcar: You got a nice and complete plan at https://blueprints.launchpad.net/horizon/essex
21:38:11 <devcamcar> https://launchpad.net/horizon/+milestone/essex-1
21:38:25 <devcamcar> and a name!
21:38:25 <ttx> It's so complete it's a bit scary :) A few remarks:
21:38:34 <ttx> We need to keep "Essential" blueprints to a bare minimum.
21:38:46 <devcamcar> understood, I will tweak
21:38:49 <ttx> They are supposed to delay the release if not completed. So I'm being even more a PITA about them, and having 7 of them is just too much.
21:38:56 <ttx> So I'd try to reprioritize a bit lower and keep the "Essential" ones a minimum, if possible.
21:39:02 <devcamcar> that's fair
21:39:08 <ttx> For any "Essential" you keep (if any), I'd like an assignee to be set. That would be the person I'll be a pain to :)
21:39:20 <ttx> Essential: must do / High: will do / Medium: wants to do / Low: may do
21:39:37 <ttx> thanks :)
21:39:47 <devcamcar> my other update is that we are really close to having migrated to all of the official tools
21:40:02 <devcamcar> gerrit transition should happen this week
21:40:23 <devcamcar> and then we will be back into Jenkins, which is a relief for me :)
21:40:43 <ttx> next week I'll look into the release tooling, making sure we have what we need (basically Ci set up to produce tarballs)
21:40:43 <devcamcar> oh and yea, we named it Horizon
21:40:52 <devcamcar> great
21:40:54 <ttx> devcamcar: A few remarks on https://launchpad.net/horizon/+milestone/essex-1
21:41:02 <ttx> You should set assignees to all the blueprints and bugs targeted.
21:41:08 <ttx> At this point, if they are not assigned, they just won't get done in time :)
21:41:18 <devcamcar> Wilcox
21:41:20 <ttx> devcamcar: Are all the blueprints you have there on track ?
21:41:27 <ttx> I was wondering about improve-dev-documentation (slow progress ?) and javascript-unit-tests (not started ?)
21:41:29 <devcamcar> thanks autocomplete
21:41:47 <devcamcar> js unit tests will get done next week
21:41:56 <devcamcar> dev documentation has been ongoing
21:42:04 <devcamcar> i think evry
21:42:13 <devcamcar> I think everything is tracking well right now
21:42:17 <ttx> ok, great
21:42:20 <ttx> devcamcar: Anything else ?
21:42:26 <devcamcar> nope
21:42:32 <ttx> Questions on Horizon ?
21:42:45 <ttx> "no question on the horizon"...
21:42:54 <anotherjesse> devcamcar: event horizon = ?
21:42:56 <devcamcar> haw
21:43:19 <devcamcar> anotherjesse: oh god, I didn't even make that connection
21:43:39 <anotherjesse> backbone.js powered websocket + yagi
21:43:44 <anotherjesse> dashboard 5.3
21:44:11 <devcamcar> anotherjesse: patches welcome
21:44:15 <ttx> #topic Incubated projects and other Team reports
21:44:22 <ttx> danwent: how is Quantum doing these days ?
21:44:39 <danwent> good.  slowing getting the dev wheels turning again after the summit
21:44:53 <danwent> #link here is a wiki page with a rough plan for essex overall: http://wiki.openstack.org/QuantumEssexRoadmap
21:44:56 <ttx> yes, it always takes a bit of time to recover
21:45:20 <danwent> #info essex-1 milestone blueprints are filling in a bit slowly: https://launchpad.net/quantum/+milestone/essex-1
21:45:47 <danwent> We have a couple reviews in for the Quantum network manager in nova, would be great to get help from network savvy nova core devs
21:46:08 <ttx> vishy: you don't really have a network subteam, do you ?
21:46:22 <vishy> yes
21:46:24 <anotherjesse> aren't we all on vishy's subteams?
21:46:24 <danwent> actually, i think they just created one with trey
21:46:24 <vishy> we just created one
21:46:27 <vishy> !
21:46:33 <ttx> hah
21:46:38 <ttx> I'm so yesterday
21:46:52 <danwent> I'll work with trey on those reviews
21:46:59 <danwent> nothing much else to report, unless there are questions.
21:47:07 <ttx> Other team leads with a status report ?
21:47:16 <ttx> doc/CI/QA ?
21:47:30 <ttx> stable release ?
21:47:49 <annegentle> nothing today, next Docs Team Meeting in November (14th) and watch for the time change Nov 6th.
21:48:12 <anotherjesse> don't know if devstack is going to join CI or QA or … but we are hoping to get diablo "done" so we can move to essex … at which point we will start doing gerrit & lp instead of github issues/pull requests
21:48:16 <ttx> yes we are entering DST fuzzy zone. Double check UTC time for all meetings
21:49:11 <ttx> Europe goes off DST on Oct 30
21:49:24 <ttx> topic Open discussion
21:49:30 <ttx> #topic Open discussion
21:49:35 <ttx> Anything, anyone ?
21:49:55 <wwkeyboard> What about the Melange/Nova merge thing?
21:49:55 <danwent> there are a couple pull requests at: https://github.com/rackspace/python-novaclient
21:49:57 <wwkeyboard> is that still on?
21:50:06 <danwent> would be great if someone on that team could take a look.
21:50:18 <danwent> or tell me a better place to push patches
21:50:23 <ttx> vishy: did you rule on the Melange in/exclusion ?
21:50:41 <vishy> ttx: no i didn't
21:50:48 <vishy> i was trying to find out the status of that today
21:50:55 <anotherjesse> is troytoman around?
21:50:59 <annegentle> hey I did want to remind nova core reviewers to also keep an eye on compute-api - Nati has some changes that need review.
21:51:06 <troytoman> o/
21:51:13 <wwkeyboard> There is a merge request for the merge
21:51:23 <ttx> vishy: feel free to abuse the open discussion for that.
21:51:44 <troytoman> vishy: what was the melange question?
21:51:45 <wwkeyboard> https://review.openstack.org/#change,646
21:52:05 <vishy> troytoman: where are we at with melange
21:52:12 <vishy> troytoman: are we still trying to merge?
21:52:36 <pvo> danwent: will get someone on the pull req
21:52:41 <troytoman> vishy: yes. after talking with jaypipes we cut the merge prop into 3 phases to make it easier to review
21:52:57 <troytoman> the first one has been approved by jay but we need more to get it merged
21:53:03 <troytoman> then we can do the additional pieces
21:53:21 <vishy> troytoman: ok if we are going that route
21:53:38 <vishy> I will get the new nova-network team to take responsibility for getting it going
21:53:51 <troytoman> OK
21:54:51 <vishy> btw as an fyi
21:55:28 <vishy> I'm marking all of the "good idea" blueprents as Undefined / New / Deferred
21:56:00 <vishy> so that is where to find the backlog
21:56:14 <troytoman> alright
21:56:31 <ttx> vishy: ++
21:56:55 <ttx> vishy: so Melange will still be in Nova itself ?
21:57:02 <vishy> yes sounds that way
21:57:14 <ttx> vishy: should be your call, not someone else's :)
21:57:22 <troytoman> vishy: since we haven't merged it, we don't have to do it that way
21:57:40 <troytoman> but based on initial input and the latest convo with jay that was the plan
21:57:52 <vishy> we have to do one or the other
21:58:07 <troytoman> if we want to do something else, i just want to know so we can have a clean path forward
22:00:09 <vishy> troy, lets discuss this offline
22:00:22 <ttx> vishy: if you don't feel strongly one wy or the other, raise an ML thread -- there is always someone feeling strongly about something somewhere :)
22:00:32 <ttx> ok, let's close this...
22:00:37 <Vek> no kidding :)
22:00:40 <vishy> ttx: we have just been discussing it for far too long
22:00:53 <vishy> an ml thread will just go around and around again
22:00:53 <ttx> vishy: yes, you even lost me :)
22:01:17 <ttx> ok, just decide then
22:01:21 <ttx> #endmeeting