21:04:46 <ttx> #startmeeting project
21:04:46 <markwash> greetings
21:04:47 <openstack> Meeting started Tue Nov 19 21:04:46 2013 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:04:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:04:50 <openstack> The meeting name has been set to 'project'
21:04:51 <russellb> o/
21:04:55 <jd__> o/
21:04:56 <stevebaker> \o
21:05:01 <mordred> ttx: I've got weird time needs - can we do the library thing up top?
21:05:18 <ttx> mordred: how top ? top top ?
21:05:20 <ttx> #link http://wiki.openstack.org/Meetings/ProjectMeeting
21:05:32 <mordred> whenever - I'm probably just only online for another 15-20 minutes
21:05:43 <ttx> mordred: ok, #2 for takeoff
21:05:48 <ttx> #topic New meeting format
21:06:02 <ttx> At the design summit we discussed a new format for this project / release status meeting
21:06:12 <ttx> The idea is to avoid spending the whole meeting doing per-project status updates, and make the meeting more focused on cross-project communication
21:06:19 <ttx> Which may well make it shorter and more relevant to everyone
21:06:30 <ttx> Feel free to add discussion topics on the wiki page if you want anything discussed here, ideally before EOD Monday
21:06:41 <ttx> For example, sdague/QA could add a topic to raise top gate offenders
21:06:52 <ttx> We might also just skip the meeting if we don't have anything cross-project to discuss
21:07:08 * mordred imagines zero days when that will be the case
21:07:11 <ttx> Does that sound good ?
21:07:15 <sdague> +1
21:07:16 <stevebaker> +1
21:07:17 <mordred> ++
21:07:20 <dhellmann> +1
21:07:20 <jgriffith> +1
21:07:20 <markmcclain> +1
21:07:22 <david-lyle> +1
21:07:24 <dolphm> +1
21:07:24 <annegentle> +1
21:07:28 <hub_cap> hey ttx
21:07:33 <russellb> #vote yes
21:07:38 <hub_cap> +1
21:07:41 <annegentle> I like this idea a lot and want to register that affectation here.
21:07:55 <markwash> +1
21:07:57 <ttx> awesome. handling the project 1-to-1s updates today was a bit crazy, but we'll see if I survive it
21:08:00 <jeblair> annegentle: i add my +1 to your +1
21:08:13 <jd__> +1
21:08:18 <annegentle> ttx: you can DO it!
21:08:20 <dolphm> ttx: that is going to become your tuesday
21:08:21 <hub_cap> ++11 jeblair?
21:08:30 <annegentle> hub_cap: concationation ftw
21:08:31 <ttx> dolphm:  indeed
21:08:37 <markwash> where did we end up on a separate room for those meetings?
21:08:49 <jeblair> ttx: how do you do it, btw?  what's the process?
21:09:06 <ttx> markwash: I figured #openstack-dev could be abused, so that everyone hears our chat
21:09:16 <dhellmann> markwash: #openstack-dev wasn't very noisy for mine, but it was early in the day in the US
21:09:22 <markwash> ttx: its nice until people show up to talk about other stuff
21:09:24 <ttx> pre-arranged 15-min slots over the Tuesday. 10 of them
21:09:36 <dolphm> #openstack-dev worked for me, but it was an otherwise quiet time slot
21:09:52 <ttx> dolphm: we'll move elsewhere if it ends up not bing workable there
21:09:55 <markwash> it happened like twice in mine, not a huge deal but hurts my brain and seems unnecessary
21:10:02 <russellb> i had people see me talking and interjecting or messaging asking for things like blueprint reviews or code reviews
21:10:03 <russellb> it was awesome
21:10:11 <ttx> yay
21:10:14 <lifeless> +1 on skipping de meeting :)
21:10:17 * dhellmann wishes he was as popular as russellb
21:10:23 <russellb> dhellmann: you don't, i promise
21:10:26 <dhellmann> haha
21:10:29 <markwash> not sure if awesome, or. . .
21:10:33 <markwash> :-)
21:10:37 <ttx> OK, quick topic for markwash/mordred/ttx question about client lib branches
21:10:44 * jd__ waits for someone to throw a blueprint to review at russellb
21:10:44 <ttx> #topic Client lib branches (markwash)
21:10:57 <ttx> markwash: so you had a question, before mordred leaves
21:10:57 <markwash> so, its about time to make some backwards incompatible changes in python-glanceclient
21:11:01 <markwash> and release it as 1.0
21:11:22 <markwash> but there are lots of those, and its hard to pick a time in master to just say "okay now we don't release until we have every backwards-breaking change we want"
21:11:34 <markwash> so it would be cool to use branches in gerrit to deal with that
21:11:39 <mordred> well...
21:11:42 <ttx> so.. my understanding was that doing backward-incompat changes in a client library was a really bad idea, due to the way we encourage people to use those
21:11:43 <mordred> I have two sets of thoughts
21:11:47 <stevebaker> markwash: can you make old and new parallel-installable?
21:12:05 <mordred> one is that we do have the capabilities of doing branches and making releases with a major rev increase
21:12:10 <lifeless> markwash: why do you need to make backward incompat changes?
21:12:13 <mordred> however, what ttx said is my main concern
21:12:29 <mordred> which is that backwards incompat changes in client libraries is GIANTLY disruptive to people
21:12:36 <ttx> UX!
21:12:36 <lifeless> markwash: there will always be backwards incompat changes desired.
21:12:51 <lifeless> markwash: can we do it gracefully over (say) a 1 year deprecation period
21:12:53 <notmyname> isn't the whole point of semantic versioning to be able to easily communicate when there are such changes?
21:13:05 <lifeless> notmyname: it is, but it doesn't make doing it free :)
21:13:19 <mordred> it is. we should definitely rev the major version if we make such a change
21:13:23 <notmyname> no, absolutely. it shouldn't be encouraged, but it's a good tool to have
21:13:28 <mordred> the thing is - we have multiple different consumers
21:13:32 <markwash> ttx, how are we trying to encourage people to use those?
21:13:34 <notmyname> and not something to be feared
21:13:36 <markwash> I'm a little lost
21:13:37 <mordred> one of them are our end users (of which openstack-infra is)
21:13:47 <jeblair> markwash: specifically, this is about backwards-incompat changes to the _python_ api provided by python-glanceclient, right?  (not anything to do with the wire protocol)?
21:13:54 <markwash> jeblair: right
21:14:08 <ttx> notmyname, markwash: mordred sold me to the client library versioning system by telling me we would never have more than one branch to support (no stable branch for client stuff)
21:14:17 <david-lyle> so the http part of the client maintains compatibility?
21:14:49 <markwash> well, I'm not saying I necessarily need to have two active branches at the same time. . just I need a place to gather changes and then eventually pull the trigger on glanceclient 1.0
21:14:56 <dolphm> keystoneclient is moving towards a separate execution path with features that would otherwise be backwards-incompatible and 1.0-ish
21:15:06 <stevebaker> there is also the cli interface to consider
21:15:06 <ttx> notmyname, markwash: I fear that we'd create a reason for people to NOT use the latest version, hence the need to have stable branches to say, backport security fixes
21:15:18 <dolphm> and we're going to properly deprecate and support the current execution path for a couple of releases of the services (i.e. 1 year)
21:15:24 <mordred> I do not think that this is the same as my opposition to stable/grizzly type branches
21:15:32 <mordred> saying "this is the grizzly client library" is just stupid
21:15:38 <mordred> and makes no sense
21:16:00 <mordred> having a stable/0.0 branch after having released a 1.0 for security fixes isn't silly from a dev perspective
21:16:11 <ttx> markwash: you can use a feature branch to develop elsewhere than in master, if that's what you mean
21:16:27 <mordred> the thing I'm more concerned with is the idea that we need user-facing incompat changes
21:16:48 <markwash> so I'm pretty strict about those changes not landing, for example I had to revert a change to the default page size
21:16:58 <markwash> you can see why I'd like to move changes like that into a major release
21:17:00 <jeblair> mordred: agreed, i believe that is what we discussed possibly needing to do in this situation (i'm not sure we'd call it stable/0.0, or something else, but that idea))
21:17:00 <mordred> especially as it relates to pinning in our server projects
21:17:20 <mordred> and, specifically...
21:17:24 <mordred> what it means for grating
21:17:26 <mordred> gating
21:17:30 <mordred> on stable/* releases in devstack
21:17:43 <lifeless> markwash: I'm confused why these changes are tied to 1.0
21:17:57 <notmyname> mordred: wouldn't that be a feature of the requirements for a server project?
21:17:57 <jeblair> mordred: i assume stable/* releases would need to pin to <1.0 ?
21:18:00 <mordred> lifeless: it's a major version bump
21:18:13 <mordred> jeblair: right. but then how do we gate stable/*
21:18:15 <lifeless> mordred: I got that much :)
21:18:21 <mordred> jeblair: and how do we test cahnges to stable/0.0 ?
21:18:32 <jeblair> mordred: indeed, we would try to pull stable/grizzly, fail, and fall back on master.
21:18:36 <ttx> I think tat opens a whoel can of worms. Might be workable, but we won't solve it in meeting
21:18:37 <mordred> jeblair: because master *client will no longer be able to participate in the gate combo
21:18:48 <lifeless> but in my head we should not be breaking up to date clients with a major version bump
21:18:56 <mordred> jeblair: but once a 1.0 is cut that's not compat, and we have a version pin in stable/grizzly that's <1.0
21:19:04 <mordred> we've got an issue with our automation
21:19:07 <lifeless> we should get the new functionality it. Deprecate the old. Wait. Then bump the major version and remove teh deprecated things.
21:19:13 <mordred> I think we need to sort out the exact impacts
21:19:19 <mordred> and then come back with some suggestions
21:19:20 <notmyname> mordred: it's like you need a good dependency solver ;-)
21:19:26 <mordred> notmyname: it's more complex than that
21:19:28 <lifeless> if the 'Wait' is as long or longer than our support period for stable branches...
21:19:29 <jgriffith> lifeless: +1
21:19:31 <lifeless> we'll have no issue at all.
21:19:32 <markwash> lifeless: that's what I've done I think. . .
21:19:32 <ttx> lifeless: yes, I'd prefer slow deprecation too
21:19:38 <jgriffith> lifeless: re the deprecation cycle
21:19:43 <mordred> notmyname: it actually has nothing to do with pip versions
21:19:52 <mordred> it has to do with how we combine branch versions in the gate
21:19:53 <dolphm> markwash: can you support a new way to instantiate the client to allow consumers to indicate which behavior of the client they expect? (and support both old and new)
21:19:57 <lifeless> so there shouldn't be any need to change gate stuff, no?
21:19:58 <notmyname> mordred: actually it could if a particular project isn't using 1.0 yet
21:20:07 <lifeless> markwash: cool
21:20:17 <jeblair> mordred: the last time we talked about this, i don't believe server projects _used_ client libs.  now they do, and it has complicated our proposed solution.
21:20:19 <dolphm> markwash: that way the gate still works and you allow for people to opt-in to a user experience
21:20:43 <markwash> lifeless: well, there are things that have been deprecated for a long time (like the legacy glance client) and also things that are just minor but I'm strict about them (i.e. default page sizes for listing images)
21:21:03 <ttx> mordred, markwash: should we continue this on ML ? I don'ty want to spend the whole meeting on it, especially as we are still trying to grasp what that would cascade-trigger
21:21:07 <lifeless> markwash: so the acid test for me is 'is someone using current glance client APIs going to still work with 1.0'
21:21:15 <lifeless> markwash: if the answer is 'yes', then it's graceful.
21:21:20 <lifeless> markwash: if the answer is 'no', then it's disruptive
21:21:46 <markwash> ttx: I would love it if someone would try to summarize briefly what on earth was said :-)
21:22:03 <ttx> markwash: i'm pretty sure mordred can do that
21:22:06 <dolphm> lifeless: 'forever' or 'for a reasonable period of time' ?
21:22:13 <markwash> like "no never make backwards compatible changes"
21:22:18 * mordred has to run...
21:22:21 <markwash> or "gate doesn't work with branches"
21:22:24 <markwash> or something :-)
21:22:24 <lifeless> dolphm: at the time the discussion for releasing a major version bump is happening
21:22:29 <ttx> mordred: how about you summarize the problem on a ML thread and continue discussion there ?
21:22:47 <jeblair> lifeless: i agree that a deprecation cycle longer than our support cycle eliminates many problems.  :)
21:22:51 <markwash> s/compatible/incompatible/ in case that wasn't clear
21:22:53 <lifeless> dolphm: major version bumps are where compat is broken, and IMO it's fine to break compat - gracefully. Which is where the deprecation + grace period comes in.
21:23:05 <dolphm> lifeless: ++
21:23:12 <dolphm> lifeless: that's the approach keystoneclient is taking
21:23:13 <lifeless> and I think this is a /feature/ not a gate limitation.
21:23:18 <lifeless> It's better for our users.
21:23:22 <lifeless> It's better for deployers.
21:23:31 <ttx> #action mordred to summarize problem and push discussion on ML
21:23:37 <ttx> let's move on, please
21:23:37 <lifeless> It's better for distributors.
21:23:51 <ttx> since we lost mordred he got assigned the action
21:24:06 <ttx> #topic Finalizing icehouse release schedule
21:24:16 <ttx> The proposed schedule, as discussed at the design summit, is here:
21:24:21 <ttx> https://wiki.openstack.org/wiki/Icehouse_Release_Schedule
21:24:27 <ttx> Two things I wanted to insist on:
21:24:37 <ttx> icehouse-1 is placed on December 5, which means features completed by December 3
21:24:50 <russellb> 2 weeks, eep
21:24:52 <ttx> That's only two weeks... so icehouse-1 can mostly be used to tag work that landed really early on (and even pre-summit) in icehouse
21:25:08 <ttx> which I think is fine, now that I think more of it
21:25:14 <dolphm> one of which is thanksgiving week in the US
21:25:25 <russellb> dolphm: good point, productivity-- for us here
21:25:30 <ttx> the other thing I'd like to have some agreement on is the recommended "off" week.
21:25:42 <ttx> FTR this would be a week where we'd actually encourage people to take time off OpenStack development / review, hopefully resulting in a "light" week to catch up
21:25:44 <jd__> yep, icehouse-1 seems so close and short that almost nothing will target it
21:25:54 <dolphm> which means if it's not done this week, it won't stand much of a chance seeing iteration
21:26:22 <ttx> (jd__: but pushing it back one week would just result in more questions asking what to target to it)
21:26:49 <ttx> (so using it to clean up the slate before starting real work is fine by me)
21:26:51 <ttx> On the ML thread there was a slight preference for the middle week, which is definitely less scary if we have to handle post-release fires
21:27:09 <ttx> any string objection to that one ?
21:27:12 <ttx> or strong ?
21:27:12 <annegentle> ttx: I'd be slightly leaning towards the middle week
21:27:28 <annegentle> ttx: but again I think week after summit may make more sense overall
21:27:30 <ttx> annegentle: I'll let you know where I go for vacation
21:27:34 <annegentle> ttx: heh
21:28:02 <russellb> 2 weeks off then
21:28:07 <hub_cap> ++
21:28:31 <ttx> ok, middle week it is then
21:28:42 <ttx> and schedule considered approved
21:28:58 <russellb> \o/
21:29:07 <ttx> unless someone objects and discovered a man was burning on Apr 16 or something
21:29:28 <ttx> #topic Icehouse roadmapping
21:29:43 <ttx> I talked to you all earlier today, the goal being to have a clear roadmap for icehouse-1 today
21:29:56 <ttx> the proximity of it paradoxically makes it easier to do
21:30:11 <ttx> since anything unsure can safely be bumped to i-2
21:30:35 <ttx> The goal is to cover the missing stuff and i-2/i-3 targeting in the following weeks
21:30:46 <ttx> I'll switch http://status.openstack.org/release/ to icehouse ASAP tomorrow
21:30:47 <lifeless> ttx: you didn't talk to me :P
21:31:18 <ttx> lifeless: that's because you're not part of the integrated release
21:31:25 <ttx> (yet)
21:31:49 <ttx> Most projects have pretty complete i-1 plans by now
21:32:24 <ttx> markmcclain: neutron still needs some love
21:32:29 <ttx> https://launchpad.net/neutron/+milestone/icehouse-1
21:32:31 <lifeless> ttx: I was teasing. I know :)
21:33:08 <ttx> same for heat
21:33:13 <ttx> https://launchpad.net/heat/+milestone/icehouse-1
21:33:27 <ttx> (should set priorities to those undefined ones)
21:33:28 <markmcclain> ttx: it's still on my list for today
21:33:42 <ttx> and cinder
21:33:44 * stevebaker is going through heat now
21:33:47 <ttx> https://launchpad.net/cinder/+milestone/icehouse-1
21:33:57 <ttx> most of the others (including nova !) are in pretty good shape
21:34:04 <jgriffith> ttx: working on it
21:34:13 <jgriffith> ttx: will be set later today
21:34:23 <russellb> i think we have nova in better shape for i1 at least
21:34:45 <ttx> so, for next week... Would be great to have most blueprints filed, targeted and prioritized so that we can start having a good picture of what will likely be in icehouse
21:34:57 <ttx> might take more than a week though
21:35:38 <ttx> questions on the roadmapping ?
21:36:18 <ttx> I guess not
21:36:23 <ttx> #topic Blocked blueprints (a.k.a. "Red Flag District")
21:36:35 <russellb> ha.
21:36:37 <ttx> so this will be a recurrent topic
21:36:47 <ttx> We'll use "Blocked" status to flag blueprints that are blocked on cross-project dependencies and need to be discussed in meeting
21:37:02 <ttx> like https://blueprints.launchpad.net/keystone/+spec/user-locale-api
21:37:11 <ttx> dolphm: wanted to raise this one ?
21:37:26 <dolphm> yep -- we had this leftover from havana development
21:37:34 <dhellmann> there's some work going on in oslo related to this, too
21:37:46 <dolphm> Accept-Language header support was disabled late in the cycle across all projects
21:38:10 <dhellmann> https://blueprints.launchpad.net/oslo/+spec/i18n-messages
21:38:54 <dolphm> i left the bp open for icehouse, but it's effectively blocked by the above ^
21:39:21 <dolphm> and then re-enabling in gettext init
21:40:16 <dhellmann> a changeset went up earlier today for oslo
21:40:31 <dolphm> https://review.openstack.org/#/c/56093/ ?
21:40:33 <dhellmann> I need to review it, but based on the description I got in a separate email I may have some issues with the implementation.
21:40:36 <dhellmann> yeah
21:40:51 <ttx> dhellmann: i18n-messages is targeted to i-2
21:41:14 <dhellmann> we're still having the philosophical discussion about whether a translatable message, with its state, *is* a unicode object or *has* a unicode object
21:41:16 <ttx> dolphm: do you need it completed earlier ?
21:41:22 <dolphm> ttx: no
21:41:37 <dhellmann> ttx: yes, because I wasn't sure I was going to be able to get consensus on an implementation before then
21:41:43 <dhellmann> or at least by i-1, I should say
21:41:43 <dolphm> alright, if we're in the philosophy debate phase, i'll bump to i2 for sure :)
21:41:54 <dhellmann> dolphm: I welcome your input on that :-)
21:42:11 <dolphm> dhellmann: i'll send bknudson your way :)
21:42:17 <dhellmann> dolphm: please!
21:42:30 <ttx> any other cross-project concern anyone wants to raise ?
21:42:46 <ttx> fyi I'm working on making rootwrap a standalone package in i-1 (rather than oslo-incubator copy)
21:42:52 <ttx> so I'll probably make neutron/cinder/nova switch to using that during i-2 timeframe
21:43:44 <dolphm> ttx: does grenade count?
21:44:01 <ttx> dolphm: I would say yes
21:44:03 <dolphm> i tried to get dtroyer's attention during the keystone meeting, but no go
21:44:25 <dolphm> we ran into an upgrade issue in master, we THINK caused by attempting to go from grizzly -> master
21:44:26 <ttx> grenade is part of QA so sdague should be able to give you advice
21:44:32 <dolphm> there's a patchset in review that should resolve
21:44:43 <dolphm> our bug- https://bugs.launchpad.net/grenade/+bug/1252057
21:44:46 <uvirtbot> Launchpad bug 1252057 in grenade "keystoneclient requirements update fails grenade because using stable/grizzly" [Undecided,New]
21:45:13 <dolphm> dprince's patch - https://review.openstack.org/#/c/57066/
21:45:22 <dolphm> to openstack-infra/devstack-gate ^
21:45:28 <sdague> yeh, maurosr is working on a patch to flip us to havana as the stable branch, there were a few kinks in this system as it will be the first time running multiple grenade configs
21:46:18 <dolphm> sdague: ah cool
21:46:46 <dolphm> that's all from me then :)
21:46:48 <ttx> any other red flag / concern ?
21:47:27 <ttx> #topic Incubated projects
21:47:41 <ttx> So for this cycle we currently have Ironic, Marconi and Savanna in incubation.
21:48:05 <ttx> Do we have people from those projects around ?
21:48:08 <SergeyLukjanov> o/
21:48:18 <ttx> Hey SergeyLukjanov, must be late where you are
21:48:40 <ttx> SergeyLukjanov: When do you plan to align internal savanna releases to the common milestones ?
21:48:57 <SergeyLukjanov> ttx, starting from the i1
21:49:08 <ttx> SergeyLukjanov: oh, great
21:49:59 <ttx> SergeyLukjanov: what about you tag this one, and I'll take over and start doing it by icehouse-2 ?
21:50:02 <SergeyLukjanov> we're cleaning up LP to have issues/bps mapped to corresponing milestones
21:50:22 <SergeyLukjanov> ttx, great, ok for me
21:50:51 <ttx> SergeyLukjanov: fwiw the icehouse-1 tag is actually "2014.1.b1"
21:51:06 <SergeyLukjanov> ttx, got it
21:51:34 <devananda> o/
21:51:37 <ttx> SergeyLukjanov: if you have questions, just let me know
21:51:56 <ttx> devananda: is Ironic getting closer to shippable state ?
21:52:08 <SergeyLukjanov> ttx, sure, thx
21:52:23 <devananda> ttx: yep. I should be doing a client release soon, too
21:52:47 <devananda> ttx: we're still working on the nova driver and some bits for the image deployment glue, but all other things seem good
21:52:52 <ttx> devananda: When do you plan ro be able to align internal ironic releases to the common milestones ?
21:52:56 <ttx> icehouse-2 ?
21:53:11 <devananda> ttx: yes, i-2.
21:53:22 <ttx> sounds good to me
21:54:09 <ttx> kgriffiths is not around, anyhone speaking for Marconi ?
21:54:20 <ttx> what's wrong with my fingers today
21:55:07 <ttx> #topic Open discussion
21:55:35 <ttx> Will close the Horizon PTL election in 4 minutes, so here is your last chance to vote if you're an Horizon ATC
21:55:59 <SergeyLukjanov> ttx, btw 0200 AM in my tz :)
21:56:44 <ttx> SergeyLukjanov: wow, you're farther east than I thought
21:56:45 <devananda> ttx: do you have scripts to create milestones for incubated projects? Ironic doesn't have i2/i3 yet
21:57:13 <ttx> devananda: I have scripts, but if it's just to create two milestones you better do it by hand
21:57:18 <devananda> ttx: ack
21:57:42 <ttx> devananda: for the curious, script at https://github.com/ttx/openstack-releasing/blob/master/create_milestones.py
21:58:14 <ttx> devananda: but in this case just go to https://launchpad.net/ironic/icehouse and create them
21:58:32 <ttx> ("create milestone")
21:58:35 <SergeyLukjanov> I'm using some of this scripts for moving bugs and checking tarballs, it's really useful
21:58:39 <SergeyLukjanov> thx for ttx
21:59:05 <ttx> I shall move them under openstack/ somewhere as part of the relmgt program
21:59:21 <ttx> closing horizon PTl election in 10 seconds
21:59:51 <ttx> david-lyle: looks like you win
21:59:58 <ttx> #link http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_cd16dd051e519ef2
22:00:05 <lsmola> david-lyle, congratulations
22:00:20 <ttx> and that closes our meeting, thanks everyone
22:00:25 <mrunge> david-lyle, congrats!
22:00:25 <ttx> #endmeeting