21:01:56 <ttx> #startmeeting
21:01:57 <openstack> Meeting started Tue Dec  7 21:01:56 2010 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:02:02 <vishy> o/
21:02:05 <ttx> Welcome to our weekly OpenStack team meeting...
21:02:17 <ttx> Today's agenda is at: http://wiki.openstack.org/Meetings
21:02:29 <ttx> Nobody added any topics, should be a quick one.
21:02:40 <ttx> #topic Actions from previous meeting
21:02:49 <ttx> * dendrobates to merge (or delegate merging of) the MLs, keep the archives
21:03:02 <ttx> I saw the email about the simplification of the development MLs
21:03:17 <ttx> Apparently the 8 remaining mailing-lists at http://wiki.openstack.org/MailingLists are still up, though.
21:03:32 <ttx> spectorclan: do you plan to remove them ? or merge them into a single "partner" list ?
21:03:46 <ttx> For the record, all combined, those 8 mailing-lists had 3 messages posted to them so far.
21:03:56 <ttx> Mostly "welcome to the list" messages.
21:05:01 <ttx> #action ttx to clarify with spectorclan / dendrobates the future of the "other" MLs
21:05:10 <alekibango> merging is not needed imho
21:05:19 <spectorclan> ttx: sorry, on wrong list
21:05:22 <alekibango> if some of those lists will be low traffic, good for them
21:05:34 <ttx> <spectorclan>  ttx: the plan is to keep all the other lists up and running for now
21:05:36 <spectorclan> ttx: I still plan to keep them alive for now even though most are not in use yet
21:05:48 <ttx> spectorclan: ok, we can discuss that off-meeting
21:05:51 <spectorclan> the operators list will be the user community support list
21:06:13 <ttx> * jaypipes and mtaylor to help Tushar set up his i18n efforts
21:06:22 <soren> I thought we all aggreed on that last week?
21:06:27 <soren> Err.
21:06:30 <soren> Not the i18n thing.
21:06:34 <soren> The consolidation thing.
21:06:49 <soren> Of the mailing lists.
21:06:49 <ttx> soren: for some definition of "all"
21:07:05 <soren> Enough for it to matter, I thought.
21:07:29 <ttx> I'll clarify with the owners, let's move on
21:07:50 <ttx> jaypipes and mtaylor are not around
21:08:07 <ttx> nor Tushar.
21:08:17 <ttx> I'll report it to next week
21:08:28 <ttx> #action jaypipes and mtaylor to help Tushar set up his i18n efforts
21:08:35 <ttx> #topic Current release stage: Implementation
21:08:45 <ttx> We are one month away from the BranchMergeProposalFreeze (Jan 6).
21:09:04 <ttx> Given that the end of month is likely to be disturbed by holiday celebrations, we should get as much as we can done this week and the next.
21:09:20 <ttx> For core team(s), do you think there is value in having some common calendar where we can enter our planned vacation days ?
21:09:37 <ttx> That could help people to know who will or won't be around... That would be opt-in obviously.
21:10:31 <ttx> opinions ?
21:10:34 <soren> I wouldn't mind that at all.
21:10:43 <eday> I wouldn't really use it, but don't mind :)
21:10:47 <johnpur> sounds good to me.
21:11:02 <termie> perhaps a better question would be to ask who would use it
21:11:52 <soren> I would put my info in it, and I would look up other people's availability.
21:11:52 <ttx> sandywalsh suggested it. he said that could help people proposing branches to know which reviewers they can expect to work during the christmas break
21:12:19 <creiht> or we can just be reasonable, and expect nothing to get done, and be happy if something does :)
21:13:11 <ttx> #action ttx to investigate calendar options
21:13:28 <ttx> ok, moving on, too much enthusiasm :)
21:13:38 <ttx> #topic Release status
21:13:48 <ttx> #info Swift: https://blueprints.launchpad.net/swift/1.2
21:13:48 <soren> ttx: There's something I think we need to clarify with regards to the blueprint process.
21:14:00 <ttx> soren: fire
21:14:09 <soren> I had a bit of chat earlier today with someone not currently involved with the project who wanted to work on something, but the blueprint for it was "awaiting approval". They thought that meant they weren't allowed to work on it and that proposals for it to be merged would be rejected.
21:14:21 <soren> ...and that's not entirely accurate, but I can totally see why they think that.
21:14:44 <ttx> hmm, I can see why too
21:15:22 <soren> Good patches (before the deadline) are always welcome, but I'm not sure how to convey this in a way that also explains why people really should write design documents first and discuss them.
21:15:37 <soren> Something to think about.
21:15:44 <ttx> "Pending approval" is not a permanent state anyway
21:15:56 <ttx> it should definitely get accepted or back to drafting
21:16:00 <ttx> that said...
21:16:15 <ttx> Blueprints have two sets of status. One for Design and one for Implementation
21:16:49 <ttx> You can have a branch ready 'implementation in "beta available" and still not have your design approved
21:17:43 <ttx> soren: but I see your point, I'll try to insist on that in doc
21:17:55 <ttx> Back to release status:
21:17:58 <ttx> Swift is looking good, with client-side-chunking branch getting reviewed now
21:18:07 <ttx> #info Glance: https://blueprints.launchpad.net/glance/bexar
21:18:31 <ttx> Glance is also looking good. The clients stuff apparently landed (wanted a confirmation from jaypipes that the spec was complete now), and teller-api is almost complete
21:18:43 <ttx> #info Nova: https://blueprints.launchpad.net/nova/bexar
21:19:00 <ttx> Nova is a bit more complex, like I mentioned in a recent email I'm trying to come up with a list of stuff that we can reasonably announce will be in Bexar.
21:19:12 <ttx> By next week I'll have talked to most of you and the list should be much more usable.
21:19:27 <ttx> Questions ?
21:19:51 <johnpur> 1 essential bp that is not started
21:20:05 <ttx> johnpur: xs-snapshots ?
21:20:09 <johnpur> yes
21:20:26 <pvo> it has been looked at but not started. I know our guys were looking at it.
21:20:33 <pvo> I owe ttx an owner by friday
21:20:42 <soren> I don't think assigned stuff to a team is generally a good idea.
21:20:42 <johnpur> ok
21:20:52 <pvo> not to a team, but to a single person.
21:20:55 <ttx> I think the core xenserver dev env is now set up, so xs-snapshots is next
21:20:59 <soren> It's assigned to Ozone.
21:21:01 <soren> Who's he? :)
21:21:03 <johnpur> soren: i agree
21:21:06 <pvo> right, because no one has owned it yet.
21:21:16 <soren> Right,that's my point.
21:21:24 <soren> It shouldn't be assigned.
21:21:24 <pvo> as I said above, I'm going to have it assigned to a person by friday
21:21:30 <alekibango> if blueprint is not accepted it looks like its feature not wanted...   unaccepted blueprints should be talked about with authors... imho
21:21:34 <pvo> soren: but I see what you mean
21:21:35 <ttx> pvo will assign someone I can pester all the time, by the end of the week.
21:21:44 <soren> It was more of a general observation really, just triggered by seeing it here.
21:22:02 <soren> Assigned to a team == not really assigned to anyone
21:22:09 <soren> In my reading, at least.
21:22:16 <ttx> soren: in my reading too.
21:22:21 <alekibango> so they will have chance to redraft it soon enough, or to know what is wrong, why it is not accepted
21:22:35 <ttx> soren: but BP don't have tags, so sometimes assigning to a random group help you get a list
21:22:38 <pvo> soren: I saw it was Ozone was responsible, but not assigned to a person yet.
21:23:19 <ttx> #topic Open discussion
21:23:30 <ttx> anything else anyone ?
21:23:35 <johnpur> has someone picked up responsibility for the OpenStack API?
21:23:38 <eday> reviews!! (for nova)
21:23:48 <soren> ttx: Good point.
21:24:06 <johnpur> i know we are waiting on RAX updates (to the RS API 1.0->1.1)
21:24:12 <eday> we had 24 outstanding branches this morning, that's way too many
21:24:26 <eday> so, if you have a branch in there, bug people to review it for you :)
21:24:39 <alekibango> i am just working on 25th
21:24:40 <alekibango> :)
21:24:41 <johnpur> if we are to get this into Bexar (with an appropriate namespace) we will need to jump on this when ready
21:24:58 <ttx> johnpur: I'm not exactly sure which spec supports this
21:25:10 <johnpur> i will follow-up
21:25:25 <ttx> johnpur: or if it's split between the xs- specs
21:26:10 <johnpur> we need to have a clean had-off from RAX, and then all innovation in the API will be on the OpenStack side
21:26:29 <alekibango> will  live migration land into bexar?
21:26:53 <masumotok> now we
21:26:57 <ttx> johnpur: I've already trouble with the number of specs in the list, I've not started to chase the ones that may be missing from the list, yet
21:27:30 <johnpur> ttx: i understand
21:27:45 <masumotok> about live migration, we are struggling to get over individual cla thing.
21:28:10 <ttx> alekibango: live-migration has a bit of a complex dep on network-service, which I/dendrobates need to clarify
21:28:12 <masumotok> that's why branch is not updated.
21:28:13 <johnpur> masumotok: what are you strugling with?
21:28:31 <masumotok> CLA
21:28:43 <alekibango> ttx: if some help is needed with that, ask me to help you
21:28:49 <masumotok> Licence agreement
21:28:53 <ttx> masumotok: struggling with the process, or the legal content ?
21:29:03 <masumotok> legal content
21:29:11 <alekibango> i signed CLA, but i do not see the number anywhere
21:29:23 <masumotok> you know, in my company, it takes a bit for paper work
21:29:28 <creiht> I signed the CLA a long time ago, and not sure how to get my number
21:29:39 <alekibango> btw this cla is not valid in czech republic. it needs to be paper :)
21:29:45 <ttx> alekibango: the number is at the bottom of the document, in the mail you receive from echosign
21:29:50 <alekibango> do you want to exchange  snailmails?
21:29:51 <alekibango> :)
21:29:52 <soren> alekibango: Print it out. :)
21:29:59 <alekibango> really?
21:30:14 <ttx> masumotok: anything we can do do ease the process for you ?
21:30:21 <ttx> s/do do/do to/
21:30:28 <masumotok> it's just my company's problem
21:30:34 <soren> alekibango: If it just needs to be on paper, feel free to print it out. :)
21:30:37 <ttx> masumotok: ok
21:31:40 <ttx> masumotok: your live migration spec is marked as depending on the network-service one. Do you really depend on that work ? Or is the code you're working on based on the current Nova code ?
21:31:56 <masumotok> Now we are checking
21:32:04 <masumotok> we developed based on rev 439
21:32:17 <masumotok> and on that revision, there are no
21:32:20 <masumotok> dependencies
21:32:23 <ttx> ok, so that's independant.
21:32:33 <masumotok> do you recooment
21:32:37 <masumotok> sorry
21:32:49 <masumotok> do you recommend some branch that I have to check?
21:32:57 <alekibango> ttx: i might split my blueprint into 2 easier ones -- one which will be only about CPU - for bexar, and another for later work... would  that be good idea?   https://blueprints.launchpad.net/nova/+spec/resource-partitioning
21:33:04 <ttx> masumotok: no. I prefer independent works, easier to merge and not block on others
21:33:12 <alekibango> ttx: but that can wait after meeting
21:33:25 <ttx> alekibango: I'll talk to you this week about it
21:33:31 <alekibango> k
21:34:01 <ttx> masumotok: I'll also talk to you soon about this spec, to see if we should target it for bexar.
21:34:13 <masumotok> ttx:OK
21:34:21 <ttx> ok, let's wrap up, any last minute question ?
21:34:50 <ttx> Next meeting, next week, same time same batcave.
21:35:28 <ttx> When does the US decide it's no longer summer ?
21:36:21 <eday> ttx as far as DST, or season change?
21:36:26 <dragondm> you mean dst end?
21:36:34 <ttx> dst end -- already done ?
21:36:39 <dragondm> dst ended late november
21:36:41 <eday> yeah, coule weeks ago
21:36:49 <eday> couple
21:36:55 <soren> ttx: dst end is just one week off from Europe.
21:37:06 <soren> ttx: dst start is 3 or 4 weeks off.
21:37:14 <eday> you know, ust to be difficult
21:37:17 <ttx> ah ok, I missed the usual disruption period
21:37:40 <ttx> #endmeeting