20:02:04 <ttx> #startmeeting tc
20:02:05 <openstack> Meeting started Tue Nov 13 20:02:04 2012 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:07 <openstack> The meeting name has been set to 'tc'
20:02:36 <ttx> On our plate today:
20:02:40 <ttx> #link http://wiki.openstack.org/Governance/TechnicalCommittee
20:03:07 <ttx> jaypipes, heckj, notmyname, bcwaldon, jgriffith, vishy: join us if you can
20:03:10 <bcwaldon> o/
20:03:12 <notmyname> o/
20:03:17 <jgriffith> o/
20:03:21 <ttx> #topic Motion: 3rd-party APIs
20:03:28 <ttx> #link http://lists.openstack.org/pipermail/openstack-tc/2012-November/000088.html
20:03:35 <annegentle_> o/
20:03:43 <ttx> This was debated at length on the ML, but not so much after the actual motion text was posted
20:03:54 <ttx> Any more questions/discussion needed on that before we vote ?
20:03:57 <annegentle_> "does yet have" should be "does not yet have"?
20:04:03 <markmc> probably
20:04:13 * markmc has the habit of saying the exact opposite of what he meant :)
20:04:25 <notmyname> markmc: then we must be in agreement ;-)
20:04:25 <markmc> yeah, "does not yet"
20:04:37 <annegentle_> markmc: ok
20:05:12 <ttx> "The previous aspirational statement that the PPB made in May 2012 about 3rd party APIs being implemented external to core stands. However, where a given project does not yet have expose a "stable, complete, performant interface" for 3rd party APIs to build on, that  project may choose to accept proposed new APIs in the interim if it sees fit."
20:05:36 <ttx> any other question before vote ?
20:05:43 <danwent> "does not yet have expose a" ?
20:05:54 <markmc> heh
20:06:10 <markmc> "The previous aspirational statement that the PPB made in May 2012 about 3rd party APIs being implemented external to core stands. However, where a given project does not yet expose a "stable, complete, performant interface" for 3rd party APIs to build on, that  project may choose to accept proposed new APIs in the interim if it sees fit."
20:06:11 <ttx> danwent: those crazy Irishmen can't spell
20:06:18 <markmc> I can spell just fine
20:06:30 <markmc> just add/miss random words here or there
20:06:37 <russellb> it's that complicated forming of words into sentences thing...
20:06:40 <danwent> well, i figured errors in the statement would make people think we didn't even read it :P
20:06:43 <annegentle_> Sorry, I'm trying to get it. Any scenarios this enables or disables? Does it enable Google's APIs? Does it preclude AWS?
20:07:01 <annegentle_> is it sufficiently vague to let PTLs do what they want? (Is that the idea?)
20:07:22 <ttx> annegentle_: I don't think that statement enables or diables. It brings back full control on the matter to each PTL
20:07:39 <annegentle_> ttx: ok, then I do get it :)
20:07:46 <markmc> annegentle_, the specific ask is "should the Nova PTL be allowed add GCE support to Nova while we don't have a stale API for having GCE support external"
20:07:48 <ttx> but still give a general "good" direction
20:07:55 <markmc> s/stale/stable/
20:08:17 <ttx> any other question?
20:08:44 <ttx> Ready to vote ?
20:09:25 <ttx> #startvote Approve 3rd-party APIs motion? yes, no, abstain
20:09:26 <openstack> Begin voting on: Approve 3rd-party APIs motion? Valid vote options are yes, no, abstain.
20:09:27 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:09:33 <markmc> #vote yes
20:09:35 <notmyname> #vote no
20:09:40 <russellb> #vote yes
20:09:50 <vishy> #vote yes
20:09:52 <danwent> #vote yes
20:09:53 <mordred> #vote yes
20:09:54 <ttx> #vote yes
20:09:54 <jgriffith> #vote yes
20:10:11 <ttx> "30" more seconds
20:10:13 <gabrielhurley> #vote abstain
20:10:14 <annegentle_> #vote yes
20:10:38 <bcwaldon> #vote yes
20:11:09 <ttx> #endvote
20:11:10 <openstack> Voted on "Approve 3rd-party APIs motion?" Results are
20:11:11 <openstack> yes (9): markmc, bcwaldon, ttx, vishy, russellb, jgriffith, mordred, annegentle_, danwent
20:11:12 <openstack> abstain (1): gabrielhurley
20:11:13 <openstack> no (1): notmyname
20:11:23 <ttx> #info Motion approved
20:11:28 <ttx> #topic Ongoing discussion: Incubator process update
20:11:41 <ttx> We have a thread going on openstack-dev... the idea being to come up with a view that has majority support from the TC to be defended in a joint committee with the BoD
20:11:48 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2012-November/thread.html#2387
20:11:58 <ttx> Looks like positions are crystallizing around two views so far, which is quite good
20:12:08 <ttx> View 1 is about separating the "core" and "common release" concepts...
20:12:11 * mordred is in favor of crystalization
20:12:18 <ttx> ...considering incubation as the path towards common release, leaving the labels like 'core' to be applied for trademarks choice by the BoD
20:12:24 <ttx> This was best expressed by markmc in:
20:12:29 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2012-November/002470.html
20:12:40 <ttx> Here, one aspect to consider is that the Foundation bylaws actually define what an openstack project is (in section 4.1b): core + library + gating + supporting
20:12:56 <ttx> Same article also defines "core" as "the software modules which are part of an integrated release and for which an OpenStack trademark may be used"
20:13:10 <ttx> Note that the "and" in this definition leaves some room for us to have projects part of an integrated release which would not be "core".
20:13:25 <ttx> Section 4.13b says the TC can decide for anything which is not a core project, but that the BoD approves TC recommendations for anything core.
20:13:39 <ttx> The trick being that sections 4.1 and 4.13 is quite difficult (though not impossible) to change, as it's protected by section 9.2d
20:13:43 <markmc> ttx, bylaws can be changed, sounds like the kind of thing that we should be open to changing
20:14:01 <ttx> Thoughts?
20:14:05 <gabrielhurley> I have a question about the proposal that includes the "common release" projects (or any proposal that decreases the number of core projects significantly): how does that affect TC membership?
20:14:17 <ttx> markmc: sure, it's just one of the sections that require a lot of approvals to be changed
20:14:28 <markmc> ttx, oh, is it? darn - I'd lost track
20:15:00 <markmc> gabrielhurley, I think we'd eventually have to get back to the idea of all TC seats being elected
20:15:38 <ttx> gabrielhurley: the "common release" projects could be considered like other "official projects": contributions to them would allow you to vote for directly-elected TC members
20:16:15 <ttx> then we can decide to stop special-casing "core" projects since we wuldn't care that much about them
20:16:35 <ttx> which then goes to what markmc just said
20:16:46 <ttx> View 2 is to still define Core, as pure IaaS. Best expressed by notmyname @
20:16:51 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2012-November/002455.html
20:17:05 <ttx> I had a few questions about it, maybe others have too
20:17:11 <ttx> notmyname: is it, in your mind, completely incompatible with view 1 ?
20:17:29 <zaneb> so, it seems like modulo some libraries and stuff, "Core" == "in OpenStack" under the current definition
20:18:05 <mordred> it seems liek notmyname's definition would/could include dnsaas and lbaas but not horizon or dbaas
20:18:11 <mordred> like
20:18:13 <mordred> damn spelling
20:18:13 <zaneb> would we be having the same debate if the categories were "services +  library + gating + supporting"
20:18:15 <zaneb> ?
20:18:15 <ttx> zaneb: there are official projects, which we control... and a number of them were marked "core"
20:18:51 <ttx> the only trick is that the bylaws mention the project categories, which makes it a bit difficult to change
20:19:00 * markmc thinks the project should be inclusive, that projects are attracted to joining us under our project umbrella is a good thing
20:19:09 <mordred> markmc: ++
20:19:11 <ttx> we could cheat by adding whatever we want as "supporting" projects though :)
20:19:19 <russellb> markmc: +1
20:19:20 <zaneb> my point is that we're more hung up on the definition of the word than the definition of the category
20:19:48 <markmc> zaneb, View 1 is basically to stop fussing about the definition of Core
20:19:57 <ttx> I think the disscussion about core and incubation will make a bylaws change necessary anyway
20:20:04 <markmc> zaneb, and leave it purely be a trademark policy thing, which we leave up to the Foundation
20:20:11 <mordred> so - there's a definition from the OIN about Linux which I really like:
20:20:26 <ttx> notmyname: around?
20:20:31 <notmyname> markmc: I think that we should be restrictive because more projects will end up diluting what openstack is and distract from a focus on them
20:20:32 <mordred> #link http://paste.openstack.org/show/25820/
20:20:33 <notmyname> ttx: ya
20:20:42 <ttx> <ttx> notmyname: is it, in your mind, completely incompatible with view 1 ?
20:20:47 <ttx> (view 2)
20:20:56 <notmyname> ttx: ya, I'm trying to grok that into a short statement
20:21:07 <ttx> ok, take your time :)
20:21:10 <markmc> notmyname, new projects and contributors IMHO don't dilute, they enhance
20:21:31 <zaneb> markmc: +1
20:21:38 <mordred> specifically, I like the (reworded): "has been or is likely to be leveraged across multiple OpenStack platforms"
20:21:45 <annegentle_> markmc: generally I agree more projects are great, but the shared resources then become more taxed.
20:21:49 <notmyname> ttx: I think that both view one and view two share similar goals, but the specifics (especially around scope) make the two views incompatible
20:22:14 <russellb> hopefully we can grow the contributions to shared resources just as the set of projects grows
20:22:18 <mordred> annegentle_: well, the shared resources physically are fine - the shared resources in terms of Docs and CI - people need to understand that they need to start participating and sharing the load there
20:22:24 <mordred> but that goes for our core projects as it is now
20:22:25 <ttx> notmyname: so your definition of "core" is only valid if core == common release ?
20:22:28 * markmc stops typing what russellb just typed
20:22:37 <mordred> as almost none of the big-time people contribute squat to the CI infrastructure as it is
20:22:53 <mordred> so I don't really think that adding new projects is going to be any worse from that perspective than it is now
20:22:55 <annegentle_> mordred: russellb: yes I share that hope but then that expectation must be built into the bylaws
20:23:17 <notmyname> ttx: that's a tautology since it's what's in the bylaws. core should be a limited set of projects that enhance the focus of openstack. I think that means we should focus on IaaS
20:23:25 <mordred> annegentle_: I think it could be in the TC guidelines for new projects inclusion - hey, you guys particupating in supporting systems at all?
20:23:25 <markmc> annegentle_, bylaws can't really be used to force people to contribute to specific areas, I think
20:23:37 <jgriffith> notmyname: +1
20:23:44 <russellb> yeah, rules around that worry me a bit
20:23:54 <mordred> ++
20:23:56 <russellb> should be a cultural thing, part of what makes a project be "playing nice" in openstack
20:23:58 <mordred> yes
20:24:05 <annegentle_> markmc: that's true. Just stating my position about expansion vs. conservation.
20:24:10 <mordred> and I think it's something we need to get out there now anyway
20:24:18 <mordred> even for our current projects
20:24:23 <markmc> mordred, yep
20:24:30 <russellb> definitely legitimate growing pains, but i don't think we should let that hinder growth
20:24:34 <mordred> russellb: ++
20:24:41 <ttx> Hmm, what's the way forward ? Continue discussion on the ML ? Formalize both views as motions and vote for or gainst them at next meeting ?
20:24:50 <notmyname> except that it seems what you're proposing (new projects and more people help us all) is counter to your other goals of "all the projects should work together". all the core devs helping out on all the projects means that the core devs become more "shared resources" and that means more projects dilutes the community
20:25:05 <mordred> I disagree
20:25:09 <mordred> I think we're talking about different thigns
20:25:11 <annegentle_> I wonder if we're really addressing what the board needs addressed? http://lists.openstack.org/pipermail/openstack-tc/2012-November/000072.html
20:25:15 <jgriffith> russellb: "playing nice" seems to be a bit subjective and open up quite a bit of interpretation, result is ANY project is core if they "play nice"
20:25:19 <mordred> I'm not talking about core devs working on all the projects
20:25:29 <mordred> I was talking about dilution of shared resources - specifically doc and CI teams
20:25:41 <russellb> jgriffith: sure ... but we're charged with making that judgement call when evaluating projects
20:25:46 <mordred> and I mainly htink that the project as a whole has not valued adding resources to doc and CI as it grows
20:25:52 <mordred> in favor of adding more devs to hack on features
20:25:56 <notmyname> mordred: your team was just talking about core devs needing to research and file bugs on different projects when those bugs prevent gating on a patch
20:25:58 <markmc> jgriffith, playing nice is a requirement, but not sufficient on its own
20:26:06 <jgriffith> markmc: that's kinda my point
20:26:07 <ttx> annegentle_: view 1 is addressing the board needs imho. View 2 is a bit stepping on their toes
20:26:09 <mordred> notmyname: yes. that's a specific issue
20:26:33 <mordred> I'm talking about rackspace and nebula and at&t and NTT and HP ponying up people to work on docs and CI
20:26:45 <mordred> instead of having those people working on internal versions of the same
20:26:48 <markmc> ttx, I'd love us to have consensus, but it seems like we need some sort of vote
20:26:55 <notmyname> mordred: which doesn't have anything to do with "core", right? (although it is a critical need)
20:26:59 <russellb> that's a good point, mordred, we do need to do a better job of that.
20:27:00 <mordred> notmyname: it does not
20:27:06 <jgriffith> ttx: Perhaps we vote on if we should even define core or not?
20:27:11 <mordred> notmyname: it only is a response to "more projects dilute shared resources"
20:27:13 <markmc> ttx, problem with voting on something is that it needs to be a broad direction, not specifics - plenty to discuss with the board that could change the details
20:27:14 <jgriffith> ttx: Seems we're all over the map here right now
20:27:16 <mordred> the shared resources should be scalable
20:27:19 <gabrielhurley1> or in a different view, making contributions to docs and CI a part of the bar for incubation/core...
20:27:20 <mordred> if we're doing it right
20:27:27 <mordred> and if we're not doing it right, we're screwed anyway
20:27:28 <markmc> ttx, maybe vote on direction, but need to come back and vote on final specifics after the discussion?
20:27:34 <annegentle_> gabrielhurley1: yes that was what I had hoped would be part of the Core definition
20:27:39 <jgriffith> markmc: +1
20:27:57 <ttx> markmc: that sounds good. Are we going to be ready to vote on direction anytime soon, though ?
20:28:11 <vishy> are we clear on whether core == included in openstack?
20:28:12 <mordred> notmyname: so in short, I think "diluting shared resources" shouldn't be a criteria for expansive or restrictive core view
20:28:18 <markmc> ttx, come up with a "direction motion" over the next week on the list, vote next week?
20:28:18 <vishy> do we need a vote on that point?
20:28:24 <mordred> markmc: ++
20:29:06 <markmc> vishy, more like we don't care about the definition of core, what we really care about is "included in openstack"
20:29:07 <ttx> vishy: "core" means "the software modules which are part of an integrated release and for which an OpenStack trademark may be used"
20:29:12 <notmyname> mordred: that seems impractical. of course it matters. the shared resources are what define openstack. otherwise we're just some cool tech projects
20:29:31 <jaypipes> hey, sorry y'all.. just now back from a dentist appt.
20:29:38 * mordred punches jaypipes
20:29:40 <ttx> vishy: theer are multiple ways to interpret that "and"
20:29:41 <jaypipes> :(
20:29:53 * jaypipes grabs tendon
20:29:54 <mordred> notmyname: sure they are - but they're also scalable
20:30:08 <mordred> I think we can add some more projects without the shared resources falling over
20:30:18 <mordred> unless there is a bottleneck on, say, only having one annegentle_
20:30:35 <ttx> may I suggest that we voice our opposition to the two predominant views on the ML thread asap
20:30:42 <annegentle_> mordred: I'd never prevent expansion -- I just want scope. I'd like a non-incubated, non-core project to win with a better process.
20:30:43 <mordred> ttx: ++
20:30:47 <ttx> so that they can be formalized in time for next meeting
20:30:56 <ttx> and we can start the discussion on the long overdue other topics
20:31:02 <mordred> annegentle_: I think I agree with you - but I'm not sure what you mean
20:31:11 <markmc> ttx, shall I take a stab at drafting another typo-ridden motion?
20:31:12 <mordred> markmc: YES!
20:31:28 <annegentle_> ttx: based on Alan Clark's email, why isn't the motion just to nominate a few people to participate in the revisiting of Incubation?
20:31:34 <markmc> we can bounce back and forth variations on the motion
20:31:34 <ttx> markmc: I hereby name you "Main dyslexic motion writer"
20:31:43 <markmc> that'll get us closer to something to vote on
20:32:00 <russellb> annegentle_: well i think we need a unified opinion that those people will represent to the board
20:32:01 <ttx> annegentle_: we discussed that last week. Nobody can represent the TC since the TC has no official opinion on that yet
20:32:08 <annegentle_> ah okay.
20:32:24 * mordred will just pretend to be the voice of the TC at the next board meeting
20:32:25 * annegentle_ thinks back to how easy it was to ask Ryan Lane to be a user advocate
20:32:26 <ttx> it's a bit hard to pick people if everyone has a different opinion
20:32:42 <markmc> annegentle_, it doesn't help the strength of the TC if we go into a discussion with the board with multiple disjoint positions
20:32:48 <mordred> markmc: ++
20:33:10 <ttx> #action everyone to voice their opposition to the two predominant views on the ML thread asap
20:33:34 <mordred> ttx: will you kill me if I mail out a door-number-3 proposal?
20:33:45 <ttx> mordred: no, it's perfectly alright
20:33:52 <mordred> ttx: k. just making sure.
20:33:56 * mordred doesn't like angering ttx
20:34:03 <russellb> is door #3 the mystery box?
20:34:05 <ttx> I was wondering if those two views were capturing all views
20:34:09 <russellb> who can resist the mystery box?
20:34:19 <ttx> since it looked like most people were satisfied abandoning their own view for view 1.
20:34:41 <ttx> ok, let's move on. Nothing like an IRC meeting to reignite a dead thread
20:34:46 <mordred> ttx: view 1 is pretty good ... but I just spent a lot of time on a plane, which gave me time to go crazys
20:34:54 * mordred sets ttx  on fire
20:34:58 <ttx> #topic Preliminary discussion: Distro support policy
20:35:02 <ttx> mtaylor: ok go
20:35:12 <mordred> great. SO
20:35:20 <mordred> in direct oppostion to what I just said to notmyname ...
20:35:28 <ttx> (we'll be back to incubator process upadte at the end of meetign if there is time left)
20:35:33 <mordred> I don't think we, as a project, can support all versions of all pythons on all distros
20:35:48 <russellb> what does "support" mean
20:35:53 <russellb> active CI testing?
20:35:56 <mordred> yes
20:36:01 <mordred> and or policy
20:36:03 <mordred> such as -
20:36:11 <markmc> so, this is mostly a discussion of where to focus CI resources?
20:36:16 <mordred> no
20:36:18 <russellb> and *not* that not supporting it means we rip out all compat code ...
20:36:22 <mordred> although that enters in to it
20:36:31 <mordred> but, specifically, there are two things:
20:36:36 <mordred> a) 2.6 vs. 2.7
20:36:47 <mordred> we can't really start supporting python3 until we drop support for 2.6
20:36:56 <mordred> I'm not saying we _should_ start supporting 3
20:36:59 <mordred> just saying, it's a choice
20:37:02 <markmc> right, so moving forward makes supporting an older version impossible?
20:37:07 <mordred> right
20:37:12 <mordred> BUT
20:37:21 <markmc> we're sure that 2.6 support precludes starting to support 3.x?
20:37:35 <mordred> it is possible at this point to write code that is compat with 2.7 and 3.3 at the same time
20:37:48 <mordred> (string handling is the thing that kills you with 2.6 and/or 3.x<3.3
20:38:03 <mordred> it's just not possible to write code which will satisty both at the same time
20:38:06 <russellb> so, what dependencies are blocking us from python3?  that might make this a big no-op anyway?
20:38:21 <mordred> well - fun story - python3 is going to be the default python in the next ubuntu LTS
20:38:22 <soren> eventlet, for one.
20:38:46 <lifeless> markmc: python 2.6 is syntax incompatible with 3 (or vice verca:) - you can use 2to3 though
20:38:52 <russellb> we are *very* tied to eventlet right now, and if that doesn't support python3 and isn't going to in the near future ...
20:38:52 <mordred> so it's possible that our decision is to continue supporting 2.6 for now
20:38:58 <lifeless> mordred: ^ 2to3
20:39:02 <bcwaldon> mordred: how would we justify the requirement for python 2.4 in xenserver plugin code?
20:39:11 <mordred> lifeless: right. without using 2to3
20:39:22 <mordred> bcwaldon: I believe the xenserver plugin is a special case at the moment
20:39:28 <lifeless> using 2to3 is a bit time consuming
20:39:34 <bcwaldon> kk, just wanted to make sure everyone knew about that
20:39:41 <mordred> we don't even come CLOSE to doing 2.4 for the other projects :)
20:39:43 <mordred> bcwaldon: good point
20:39:56 <mordred> before we get too tied in this part, lemme bring up part b
20:40:03 <mordred> which is distro target support
20:40:13 <mordred> in the past, we have targeted "latest ubuntu" as our dev platform target
20:40:20 <russellb> and again, is this about CI focus?  or?
20:40:38 <mordred> it's partially about dependent library versions that we as a project assert to support
20:40:49 <mordred> CI can and will support whatever the project states that it supports
20:40:54 <markmc> mordred, what I understood roughly our distro support matrix to be
20:40:59 <lifeless> pip install everywhere, problem solved.
20:41:02 * lifeless runs
20:41:02 <mordred> lifeless: it's not
20:41:09 <markmc> most recent Ubuntu LTS and RHEL
20:41:19 <mordred> markmc: RHEL is not part of the projects matrix
20:41:22 <markmc> latest and previous version of Ubuntu and Fedora
20:41:24 <mordred> although it could be if we decided to make it
20:41:32 <mordred> and fedora is also not part of that matrix
20:41:38 <markmc> mordred, well, it'd be a reason to continue supporting python 2.6
20:41:42 <russellb> so where's the matrix, heh
20:41:46 <markmc> mordred, or not moving to e.g. a newer version of libvirt
20:41:50 <mordred> that's the main question here - what is the matrix
20:42:01 <mordred> like, what is it actually, rather than what does CI happen to run
20:42:06 <ttx> Can you see the matrix ?
20:42:15 <markmc> how can you say what the matrix is and say there isn't a defined matrix?
20:42:21 <markmc> in the same few sentences? :)
20:42:31 <mordred> markmc: what I'm saying is, WAY BACK WHEN, it was "latest ubuntu"[
20:42:36 <annegentle_> mordred: The answer is out there, Neo, and it's looking for you, and it will find you if you want it to.
20:42:36 <mordred> to my knowledge, it has never changed from that
20:42:47 <mordred> although we've talked about wanting it to
20:42:48 <notmyname> mordred: what I see in production deploys is "supported LTS releases" and CentOS
20:42:52 <markmc> mordred, ok, I understood that the "loosely defined matrix" had evolved into what I said before
20:43:12 <mordred> notmyname: totally. there are MANY ways to skin this cat
20:43:25 <mordred> basically, I do not want to be defining this ad-hoc by the set of things I run in CI
20:43:30 <markmc> mordred, if it wasn't written down, it was a "rough consensus" - I had assumed the consensus had moved on
20:44:03 <mordred> because notmyname brings up a great point - there are people running lucid in production still with openstack
20:44:10 <mordred> do we care, as a body?
20:44:18 <markmc> what's lucid? most recent LTS?
20:44:21 <mordred> nope
20:44:23 <russellb> so what value do we gain in "officially" supporting a distro, and not just leaving it as having distros officially support openstack?
20:44:24 <mordred> it's the previous one
20:44:25 <ttx> markmc: 10.04
20:44:32 <mordred> none of the projects other than swift can even come close to running on it
20:44:39 <markmc> mordred, ok, but the most recent one was very recently released ?
20:44:40 <ttx> markmc: best ever. i did it.
20:44:45 <mordred> markmc: yes
20:44:52 <mordred> that's why I'm bringing this up, actually
20:44:57 <markmc> mordred, there's probably a transition point where you support two LTSs, but not for long I guess
20:45:02 <mordred> we have now hit the point where CI would normally upgrade the build slaves to quantal
20:45:06 <torgomatic> however, there are big swift clusters running on Lucid, so that should be considered
20:45:16 <mordred> but this is the first time we've had a supportable ubuntu LTS during openstack dev
20:45:19 <notmyname> markmc: actually, LTSs have 5 years of support, so the window is quite large
20:45:25 <mordred> notmyname: ++
20:45:45 * russellb is curious about the answer to his question
20:45:56 <notmyname> markmc: in fact, it will be possible for a lucid deployment to entirely skip precise and move to the next one and not be out of support
20:45:58 <markmc> notmyname, RHEL has 10+ years, but I don't think it makes sense to support latest OpenStack on 10 year old RHEL
20:46:03 <mordred> russellb: I think it's a question of what devs can be expected to care about in their patches
20:46:21 <mordred> russellb: that's what I mean by "support"
20:46:26 <russellb> ok.
20:46:32 <notmyname> russellb: not to raise another issue, but that is a great question because openstack doesn't actually provide packages for a distro
20:46:44 <mordred> if someone submits code, and notmyname says "that breaks on lucid" ... should people care
20:46:54 <mordred> (I mean, I care about everything notmyname says, but you know)
20:47:26 <mordred> there is a point where supporting old releases is in conflict with using new libraries
20:47:34 <russellb> i just don't want to start a distro flame war with people asking why XYZ isn't on our matrix
20:47:38 <markmc> well, as an comparable example - I think it makes sense to stop caring about RHEL6 maybe 6 months after RHEL7 comes out
20:47:39 <mordred> indeed
20:47:43 <markmc> even if that screws RH a bit
20:47:55 <mordred> which is one of the reasons that 'latest ubuntu' has been the de facto answer so far
20:48:35 <mordred> I'd be 'happy' to support latest LTS, latest RHEL, latest fedora and latest ubuntu in the CI systems - although I would need some help from redhat to get working redhat slaves up and going
20:48:50 <ttx> mordred: that sounds like a good set
20:48:58 <mordred> but I'm not about to start adding complexity if we don't actually want it or just ad hoc
20:49:09 <mordred> because even if I added that I still wouldn't be supporting lucid for swift
20:49:12 <bcwaldon> mordred: what value do we get from running on all those platforms?
20:49:22 <mordred> (although we've discussed adding lucid slaves just for swift because notmyname is cool)
20:49:27 <markmc> I'm not sure thinking about CI is really getting to the root here
20:49:27 <russellb> we know much sooner if we break something on platform X
20:49:34 <markmc> maybe it's really about dependency management
20:49:36 <mordred> markmc: I agree
20:49:38 <bcwaldon> but why do we care about that?
20:49:48 <bcwaldon> we care about having a platform that works for our testing
20:49:49 <markmc> e.g. a patch to require a newer version of libvirt might kill support for some distros
20:49:55 <mordred> bcwaldon: that's the question - _DO_ we care?
20:49:58 <bcwaldon> not that everybody has done their homework before something lands
20:50:04 <markmc> we should have policy on which distros we support so we can make such a decision sanely
20:50:09 <mordred> bcwaldon: or do we want to have a dev target and let the distros sort out distro support
20:50:25 <mordred> (sorry, I might have been phrasing this poorly)
20:50:29 <bcwaldon> mordred: I think thats much more sane
20:50:48 <bcwaldon> mordred: there are a ton of windows people that we would be cutting out if we dont run on their platform
20:51:34 <ttx> bcwaldon: I'd say running on multiple platforms (> 1) helps us determine if a given issue is in our code or in the platform code
20:52:11 <markmc> there are some decisions we might make about dependencies that would totally eliminate the ability of people to run OpenStack on a set of distros
20:52:11 <ttx> but maybe we want mulyiple platform only to not be called partial in the choice of the "reference platform"
20:52:12 <markmc> python version, libvirt version, etc.
20:52:15 <bcwaldon> ttx: but it also introduces the need to pre-package things before being able to build out deployments and it introduces a bigger set of distro-specific bugs
20:52:17 <notmyname> I know of swift clusters running on bsd and illumos. I'd hesitate to drop "official" support for lucid, but I'm more opposed to simply saying "latest X". I think mordred's list is a good starting point for compromise
20:52:35 <russellb> and i think it's to the benefit of openstack, for greater proliferation to have as broad of distro support as possible, so finding issues that hurt that as soon as possible is a good thing.
20:52:43 <bcwaldon> I don't see enough value in more than two distros
20:52:57 <notmyname> bcwaldon: more than X distros? (why 2)
20:53:06 <bcwaldon> notmyname: to thierry's point
20:53:06 <lifeless> so, the big deployers, AFAIK, are all keen on running tip
20:53:16 <notmyname> bcwaldon: ah, sorry
20:53:20 <mordred> well, the multi-distro thing ties back to the 2.6 vs. 2.7 thing ... for instance, precise (latest LTS) and quantal (latest ubuntu) do not have python 2.6
20:53:25 <lifeless> perhaps that should be factor in assessing what the project has interest in supporting
20:53:38 <russellb> RHEL 6 does (and thus CentOS 6)
20:53:44 <mordred> lifeless: but rackspace are running tip of swift on lucid
20:53:56 <lifeless> mordred: what are they running tip of nova on ?
20:54:03 <bcwaldon> I think I'm missing one key piece of info here - are we looking to gate on all of these platforms, or just run post-merge testing?
20:54:12 <mordred> lifeless: dunno.
20:54:18 <lifeless> bcwaldon: 'accept bugs on' I think is the statement
20:54:21 <markmc> it's a tradeoff thing too - I'd probably welcome dropping 2.6 support, if we were actually getting 3.x support in the short term
20:54:24 <mordred> lifeless: ++
20:54:28 <lifeless> bcwaldon: at what point do you say 'that is not a bug'
20:54:39 <markmc> but dropping 2.6 support and crossing our fingers that it will help 3.x support happen sometime, not so much value
20:54:42 <bcwaldon> lifeless: I'm not following you
20:54:43 <russellb> markmc: right but that doesn't seem to be anywhere on the horizon, we're blocked on dependencies
20:54:44 <lifeless> bcwaldon: e.g. syntax incompatible with python 3.3? Thats a bug. Incompatible with 2.4? Thats not a bug.
20:54:50 <ttx> mordred: to summarize: I think adding a lot more platforms doesn't really help. it's not more fair because there will always be distros out
20:55:10 <ttx> mordred: so better choose a reasonable/manageable set. Could be one or 2 or 4.
20:55:13 <bcwaldon> lifeless: I'm talking about distros not providing packages or something, not python issues
20:55:24 <russellb> well there's CI, and there's what do we care about.  can we reject a patch because it breaks platform X.
20:55:40 <bcwaldon> russellb: yes, thats what I'm interested in getting answered
20:55:41 <notmyname> russellb: absolutely. production is what matters
20:55:50 <mordred> that's the thing - we can make automatoin decisions with CI _after_ we know what it is that we have chosen to care about
20:55:55 <bcwaldon> notmyname: 'production' is subjective, though
20:55:56 <lifeless> bcwaldon: same basic thing though is my point. Distro has a too-old python-eventlet -> not a bug, if the version is lower than some N
20:55:57 <mordred> bcwaldon: I don't think it's just about distro packages
20:56:06 <mordred> we run mostly from pip anyway (other than libvirt)
20:56:08 <redbo> Swift will keep working on 2.6, but that doesn't mean it has to be CIed.  IMO.
20:56:11 <bcwaldon> mordred: true, that was just an example
20:56:14 <lifeless> missing entirely is equivalent to too-old :)
20:56:16 <notmyname> redbo: +1
20:56:17 <mordred> I think it's mainly libvirt + libxml + python-version
20:56:26 <ttx> redbo: +1
20:56:29 <mordred> redbo: +1
20:56:39 <ttx> mordred: running out of time.
20:56:40 <notmyname> bcwaldon: if someone from RAX proposes a patch to swift that breaks softlayers bsd deploy or X's CentOS deploy, it probably shouldn't be merged
20:56:42 <redbo> if it's a pain, I mean
20:56:50 <mordred> ok - if we leave 2.6 support for swift out of it
20:56:51 <ttx> mordred: way forward ?
20:56:58 <mordred> does anyone ELSE care about 2.6?
20:56:58 <bcwaldon> notmyname: how can we know that during the gate, though?
20:57:07 <bcwaldon> mordred: no
20:57:08 <markmc> lifeless, too old eventlet isn't as big a deal as too old python, though - but hard to define the line there
20:57:11 <bcwaldon> mordred: bburn it
20:57:12 <russellb> mordred: well, yes, if we want it to run on RHEL 6 / CentOS 6
20:57:19 <mordred> russellb: does EPEL have 2.7?
20:57:37 <russellb> don't know
20:57:38 <mordred> because something tells me pure RHEL isn't going to work with openstack anyway, right?
20:57:47 <russellb> sure it does
20:57:52 <mordred> it does? I stand corrected
20:58:01 <mordred> ok. then the RHEL/2.6 is still on the table
20:58:09 <notmyname> bcwaldon: heh, so maybe we should have a list of stuff we'll support and test against ;-)
20:58:10 <lifeless> mordred: sure, and I agree. My point was that you can talk about this not as a CI problem, but as 'when would you close a reported bug Invalid'
20:58:13 <mordred> if we want to support RHEL, then we need ot support 2.6
20:58:14 <russellb> yeah, there is an official red hat openstack repo for RHEL now ...
20:58:19 <mordred> lifeless: I agree
20:58:20 <russellb> yes
20:58:31 <ttx> mordred: I'd suggest you start a thread on openstack-dev with a made-up set of supported platforms and let the backslash naturally fall on you.
20:58:39 <mordred> ttx: ok. I will do that
20:58:44 <mordred> and we'll come back to it next week
20:58:53 <mordred> with perhaps more clarity
20:58:56 <ttx> #action mordred to start ML thread on distro/python support
20:59:05 <lifeless> mordred: bah, s/mordred/markmc in my last comment
20:59:05 <mordred> but I think folks here grok the issue at hand a bit, yeah?
20:59:22 <ttx> mordred: I still think kicking off the discussion in thos chaotic way helps seeing where the battle lines actually are
20:59:29 <mordred> ttx: ++
20:59:32 <bcwaldon> BURN PYTHON 2.6!
20:59:36 <heckj> heh
20:59:36 <markmc> lifeless, yep, that's another way - I prefer thinking of it in terms of dependency management, though
20:59:38 <ttx> so it's useful to have that "preliminaru discussion"
20:59:41 * mordred agrees with bcwaldon, just for the record
20:59:44 <bcwaldon> prepare for battle!
20:59:45 <ttx> before we even start the thread.
21:00:09 <lifeless> markmc: sure; though to me dependency management is an end product, not a driving force.
21:00:13 <mordred> markmc: any chance RH have an idea of when a RHEL with 2.7 is coming out?
21:00:20 <comstud> bcwaldon: phasers on stun
21:00:20 <ttx> Ok, time is up, thanks everyone! Sharpen your ML flamers, looks like they will serve all week.
21:00:27 <russellb> mordred: that would be RHEL 7
21:00:32 <russellb> which could be late 2013 ...
21:00:34 <koolhead17> ttx, :P
21:00:34 <ttx> #endmeeting