21:01:39 <ttx> #startmeeting project
21:01:39 <openstack> Meeting started Tue Nov 25 21:01:39 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:41 <nikhil_k|vacay> o/
21:01:43 <openstack> The meeting name has been set to 'project'
21:01:47 <ttx> Our agenda for today:
21:01:51 <jokke_> \o
21:01:55 <ttx> #link http://wiki.openstack.org/Meetings/ProjectMeeting
21:02:13 <ttx> #topic Decision on true cross-project weekly meeting (ttx)
21:02:21 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2014-November/051153.html
21:02:32 <morganfainberg> o/
21:02:39 <ttx> From the feedback on the thread I think we can proceed, at least experiment with the new format
21:02:55 <GheRivero> o/
21:02:56 <ttx> So I'll rename this meeting to "Cross-Project meeting" and update wiki pages accordingly
21:02:57 <jungleboyj> o/
21:03:02 <sdague> +1
21:03:11 <eglynn> one question, how does the chair selection work on the TC?
21:03:14 <eglynn> elected, or just tradition?
21:03:25 <ttx> the TC chair ?
21:03:30 <eglynn> yep
21:03:43 <ttx> The bylaws define that
21:03:45 <mikal> Elected
21:03:55 * eglynn wondering if an assigned chair might be effective than rotating, for an expanded meeting?
21:03:57 <SlickNik> o/
21:03:58 <ttx> Elected, then in theory I need to die, but in practice we revote
21:04:13 <ttx> Oh, this meeting chair is not the TC chair
21:04:29 <ttx> Used the be the release meeting, so was traditionally chaired by Release Management PTL
21:04:37 <eglynn> ttx: yeah, I get that :)
21:04:38 <ttx> so, also me
21:04:39 <mestery> There was discussion of rotating the chair for this meeting, right?
21:04:46 <ttx> but I'm MORE THAN FINE rotating
21:04:46 <morganfainberg> mestery: yes.
21:05:00 <eglynn> mestery: exactly, that's what I was talking about
21:05:03 <ttx> actually, you discovered my evil to go to bed earlier
21:05:10 <ttx> evil plan*
21:05:16 <ttx> now I'm exposed
21:05:16 <morganfainberg> Ahhaha
21:05:22 <eglynn> ttx: ... sorry for the lack of clarity on the context of the original question
21:05:24 <mestery> ttx: lol
21:05:37 <SergeyLukjanov> ttx, I like your evil plan ^)
21:05:58 * SlickNik scribbles down a note to come up with a similar evil plan of his own.
21:06:00 <sdague> meh, I like to keep ttx up, I'd rather keep him chairing for now until we find the right rhythm
21:06:02 <ttx> I think any PTL could sign up. Horizontal team PTLs make slightly better candidates, but I'll take them all
21:06:15 <ttx> sdague: ex-PTLs could also qualify, so beware
21:06:33 <ttx> I'll do the next one since it will be the first one of the new era
21:06:36 * morganfainberg lets someone else fall into that trap.
21:06:40 <ttx> but after that I'll seek volunteers
21:06:44 <sdague> ttx: I'll have to come up with some other reason to disqualify myself
21:06:55 <eglynn> yeah, so my thought was that an expanded meeting would need strong chairing, hence maybe moving to a rotating chair might be a step too far?
21:07:05 <mtreinish> sdague: just say time constant time conflict :)
21:07:11 <asalkeld> eglynn, agree
21:07:19 <nikhil_k> can we have a signup list for scheduling?
21:07:25 <morganfainberg> mtreinish: shh don't give away my secret!
21:07:29 <ttx> eglynn: I don't see all hell breaking loose the way you do. If that happens we can only pick strong chairs.
21:07:38 <ttx> So that the meeting can be announced with enough time in advance, we'll probably close the agenda on the day before
21:07:46 <sdague> so I move that we keep ttx for chair until the end of the year, then reevaluate in 2015 if we want rotation
21:07:49 <ttx> so that people can decide if they want to attend or not
21:08:00 <mestery> sdague: ++, as long as ttx is ok with that
21:08:10 <eglynn> sdague: ++
21:08:16 <ttx> So just edit the meeting wiki page at least one day before if you have topics.
21:08:16 <morganfainberg> sdague: I like that. It's not that many more meetings this year. Obv is txt doesn't complain.
21:08:19 <ttx> boohoohoo
21:08:26 <morganfainberg> If ttx *
21:08:30 <eglynn> ttx: sorry :)
21:08:33 <david-lyle> sounds like he's all in favor
21:08:37 <mestery> rofl
21:08:38 <ttx> I guess I'm fine if we rotate before DST strikes again
21:08:57 <sdague> ttx: yeh, just to get a feel for the new format
21:09:08 <ttx> #action ttx to rename meeting and rotate wiki pages
21:09:18 <ttx> #action ttx to chait until new year, consider rotation afterwards
21:09:22 <ttx> chair*
21:09:42 <ttx> #topic Requirements policy and enforcement in stable branches (sdague)
21:09:58 * ttx hands the chair dflag to sdague
21:10:01 <sdague> ok, I tried to put a sketch of what's going on in the agenda
21:10:29 <sdague> we've got some issues with requirements and stable branches that have never really been satisfying, and are definitely getting more challenging with more projects
21:10:46 <sdague> there is the fact that we get broken on stable by upstream releases a lot
21:11:20 <sdague> there is the fact that oslo projects would actually like to advance and add new features and dependencies
21:11:27 <sdague> same with client libraries
21:11:41 <morganfainberg> sdague: ++
21:11:54 <bknudson> and middleware
21:11:54 <morganfainberg> and/or be able to deprecate things sanely.
21:12:04 <ttx> I can testify that most of stable breakage comes from requirements updates
21:12:04 <sdague> and the current policy of not capping anything, and testing backwards compat, means that we have to add new requirements to stable all the time
21:12:07 <sdague> which is weird
21:12:11 <ttx> for littel gain
21:12:30 <sdague> so... there is policy and there is tech
21:12:37 <sdague> but we should probably tackle policy first
21:12:48 <morganfainberg> It doesn't make sense really to not cap for a "stable" release.
21:12:49 <sdague> policy is that we don't cap any requirements ever
21:12:52 <bknudson> all distros that ship openstack don't update their packages all the time.
21:13:08 <eglynn> sdague: pinning those dependencies on stable to major.x.y wouldn't help?
21:13:14 <sdague> morganfainberg / bknudson right
21:13:18 <sdague> eglynn: that's where I was getting
21:13:19 <eglynn> ... or would be too restrictive?
21:13:37 <sdague> I think we should pin requirements on stable to semver versions
21:13:49 <sdague> so < X.Y
21:13:58 <sdague> assume z can float for most packages
21:14:07 <morganfainberg> sdague: I'm in favor of stable being "stable" even if it means we have crazier releases for client/middleware (extra bug fixes worst case)
21:14:12 <asalkeld> seems reasonable
21:14:18 <sdague> for whatever the last versions were that we tested before release
21:14:18 <morganfainberg> Oslo as well there.
21:14:20 <jokke_> sdague: one minor thing was left open for me in your e-mail, would you like to cap the requirements to stable/ or all?
21:14:28 <sdague> jokke_: just stable
21:14:38 <eglynn> yeah, just stable agreed
21:14:41 <sdague> I think in master letting things float is probably the right thing to do
21:14:56 <morganfainberg> sdague: I like that because it also means eol tag has a stable snapshot to work from.
21:14:59 <bknudson> can we make a point release for an old keystoneclient? where would I check in the change?
21:15:15 <morganfainberg> bknudson: we'd spin up a topic branch.
21:15:21 <sdague> bknudson: you can do anything you like with keystoneclient
21:15:32 <morganfainberg> Like milestone proposed was used.
21:15:35 <sdague> but yeh, keystone team policy decision there on mechanics
21:15:41 <jungleboyj> I think doing some sort of version control on stable is necessary.
21:15:49 <sdague> that would be part of letting Z float
21:16:07 <ttx> that's what we discussed in Paris and there was broad agreement around it
21:16:08 <sdague> to handle critical bug fixes that you definitely want stable releases to take from
21:16:17 <eglynn> so the CI failures in stable are surfacing in the periodic builds, or?
21:16:20 <eglynn> (since the merge activity on these branches is probably very bursty)
21:16:23 <bknudson> like security fixes
21:16:41 <sdague> eglynn: they block tempest and devstack-gate, which are branchless
21:16:46 <sdague> and oslo libs
21:16:49 <morganfainberg> We also then change the support cycle for client releases and oslo and etc
21:16:55 <eglynn> sdague: a-ha, yeah, got it
21:16:58 <sdague> which have compat testing against old branches
21:17:04 <sdague> actually, all the libs now
21:17:05 <morganfainberg> It's a lot of extra work, but I see it as worth it.
21:17:27 <eglynn> morganfainberg: do you mean, stable branches for the clients?
21:17:52 <morganfainberg> eglynn: well we will need to backport fixes to the release versions of those client and oslo libs.
21:18:04 <sdague> morganfainberg: only if they are a big enough issue
21:18:06 <morganfainberg> Security most specifically
21:18:19 <sdague> yeh, I'd say security patches are the only reason to do Z
21:18:35 <jungleboyj> sdague: +1
21:18:37 <morganfainberg> I don't think anything else would qualify. It is still a significant amount of overhead compared to today.
21:18:38 <sdague> ok... so policy seems generally agreed?
21:18:48 <sdague> do we feel we need to do anything else to change the policy
21:18:50 <morganfainberg> sdague: +1 from me
21:18:51 <bknudson> I think it's a good idea
21:18:57 <eglynn> sdague: yep, it seems sane
21:18:59 <david-lyle> +1
21:19:10 <asalkeld> +1
21:19:24 <bknudson> I'd like a little info on how to actually make a fix since I don't know how it's going to work.
21:19:24 <mtreinish> sdague: sounds good to me
21:19:46 <sdague> ttx: ? as RM I'd like a nod at least :)
21:19:59 <morganfainberg> bknudson: I know how I want to handle for keystone. I'll write it up and post to the ML as a proposal for all if we're all good on this.
21:20:01 <sdague> so... I'll move onto the tech front... because this gets a bit interesting
21:20:05 <kragniz> will there be a more detailed spec on this?
21:20:06 <SlickNik> sdague: ++ Sounds like a plan.
21:20:29 <morganfainberg> And we can keep it consistent that way.
21:20:34 <morganfainberg> Or try to.
21:20:40 <ttx> sdague: trying to wrap my head around what you just said about client libs
21:20:43 <sdague> first, we probably need a driver, because I don't think I can be the driver for this given other things on my plate in the near term
21:20:50 <sdague> ttx: which part
21:21:28 <ttx> you would be creating stable branches for oslo libs and client libs ?
21:21:35 <sdague> ttx:  no
21:21:56 <apevec> some oslo libs already have stable branch
21:22:05 <sdague> we would cap stable/juno at oslo.config<=1.4 (making numbers up)
21:22:06 <apevec> messaging iirc
21:22:10 <ttx> ack
21:22:21 <eglynn> apevec: yep oslo.messaging does
21:22:32 <sdague> so if oslo.config wanted to release a 1.3.19 to fix a sec bug, go for it
21:22:35 <morganfainberg> sdague: as a side note I would do <= last release. Cap <
21:22:46 <morganfainberg> Not just < x.y
21:22:48 <sdague> morganfainberg: right, <
21:22:54 <ttx> sdague: and what about client libs ?
21:23:00 <sdague> morganfainberg: so... actually, I specifically don't want to do that
21:23:15 <ttx> same ?
21:23:20 <morganfainberg> Really? So all previous versions are valid?
21:23:23 <sdague> because I think we should assume .Z is compatible unless proven elsewise
21:23:43 <morganfainberg> No no I mean. What you proposed but just pin the lower bound as well
21:23:52 <morganfainberg> To the last releases cap
21:24:00 <sdague> oh, yeh, I don't want to do that
21:24:21 <sdague> because it's going to impact the upgrade story because pip is the suck
21:24:24 <morganfainberg> Hm. That worries me a little but hat can be discussed elsewhere.
21:24:32 <morganfainberg> Continue.
21:24:39 <sdague> ok... so the tech problem
21:24:54 <sdague> oh, ttx yes same for clients
21:25:02 <sdague> we do a semver < x.y pin
21:25:22 <sdague> so... here is the interesting thing about our openstack python clients
21:25:30 <sdague> they are used both for services to talk to each other
21:25:35 <sdague> and for users to talk to services
21:25:57 <eglynn> or even for services to talk to themselves :)
21:26:12 <eglynn> (ceilometer does this, in the alarm-evaluator)
21:26:17 <sdague> sure or that
21:26:24 <sdague> though it's a special case of A
21:26:37 <eglynn> yep
21:26:47 <sdague> but, basically we still care that new releases of python-novaclient can talk to older nova
21:27:18 <ttx> sdague: indeed. will capping prevent that test ?
21:27:27 <sdague> ttx: today, yes
21:27:43 <sdague> however, I think there is a solution by moving to using more venvs in devstack
21:28:10 <sdague> so that all the services in install with a global venv
21:28:23 <sdague> the client libs also install in system
21:28:59 <ttx> sounds promising
21:28:59 <sdague> therefor using the client libs against older services can be tested, but won't drag that code into those services using them against each other
21:29:11 <sdague> there are pieces of this in an ML thread
21:29:15 <sdague> which I can't find
21:29:43 <morganfainberg> I either remember talking about this in Paris or on the ML.
21:29:44 <sdague> http://lists.openstack.org/pipermail/openstack-dev/2014-November/051125.html that's it
21:30:05 <sdague> ok. So basically I think this is what we need:
21:30:17 <sdague> 1) general head nods that this is the right direction
21:30:27 <ttx> yep, it's mostly a reminder, but trying to ask all the questions so that sdague can expose all the answers we already have
21:30:31 <bknudson> keystone runs in apache
21:30:33 <sdague> 2) help finding some folks that want to tackle these stuff
21:30:40 <sdague> I can mentor people on it
21:30:48 <sdague> but I think some fresh blood would be great
21:31:03 <sdague> bknudson: so... we'd need to cover that case
21:31:12 <morganfainberg> I don't know how a venv works for mod_wsgi or if it does.
21:31:15 <sdague> probably just python path set in apache env?
21:31:30 <sdague> noted as a possible gotcha
21:31:32 <morganfainberg> sdague: todo to figure it out. I hope it's that easy
21:31:54 * devananda failed to notice the time, tries to catch up on scrollback
21:32:14 <asalkeld> sdague, wouldn't it be easier to make the venv for the client libs?
21:32:22 <asalkeld> rather that all the services
21:32:33 <sdague> asalkeld: that would do all the completely unexpected things for the user
21:32:48 <sdague> because nova list would use the wrong libs
21:32:49 <ttx> sdague: as a first step, is there more to do than pushing capped requirements to every stable branch  ?
21:33:08 <sdague> ttx: no, I think that's a reasonable first step
21:33:18 <ttx> sdague: then second step is working on fixing client lib testing so that we don't leave a hole in our testing ?
21:33:26 <sdague> ttx: yep, sounds right
21:33:48 <asalkeld> sdague, ok - i thought this was just for a new client lib <-> old services test
21:33:50 <sdague> asalkeld: the reasons for venv on the servers is in the ML post I linked above
21:33:59 <asalkeld> ok, i'll catch up
21:34:03 <sdague> asalkeld: it's also for how devstack functions for people
21:34:09 <ttx> sdague: if nobody volunteers I guess the stable core team could step in
21:34:18 <sdague> ttx: ok, cool.
21:34:22 <ttx> since they are the ones benefitting most directly from the change
21:34:38 <ttx> but agree that it sounds like a good opportunity to train new blood
21:34:45 <morganfainberg> I'm willing to help. But I can't drive all of it. I am also on stable so, moot point?
21:35:00 <sdague> anyway, that was my agenda item
21:35:08 <sdague> I think all the details are out there
21:35:40 <morganfainberg> I am generally a +1 on all of this. Some details Id like to workout offline.
21:35:41 <ttx> ok, I can take the action of finding out people to help there, since I'm already chasing them
21:35:49 <sdague> ttx: +1 thanks
21:36:09 <ttx> #action ttx to find people to work on the stable requirements capping transition
21:36:21 <ttx> last comments on that one ?
21:36:29 <ttx> mtreinish: around?
21:36:31 <mtreinish> yes
21:36:35 <ttx> #topic XML API testing on stable branches (mtreinish)
21:36:40 <ttx> I think you proposed that one
21:36:44 <mtreinish> I did
21:36:48 <ttx> DIE XML DIE
21:36:52 <ttx> oops sorry
21:36:55 <mtreinish> yeah basically :)
21:36:56 <sdague> ttx: +3
21:37:03 <morganfainberg> Kill it burn it with fire^w^w^w...
21:37:16 <mtreinish> so when kilo opened everyone started dropping xml, but to do that they needed to turn off the tempest tests for it
21:37:48 <mtreinish> I was having everyone do this in a way which made xml testing optional but default off so we could keep it running on stable branches
21:37:49 <devananda> ttx: ++
21:37:54 <mtreinish> where we had pre-existing xml coverage
21:38:05 <mtreinish> but this is turning out to be very difficult to implement
21:38:07 <ttx> I think dropping it in testing is much less of a conflictual decision that dropping it from projects. Also will make XML suffer while it dies, so +1
21:38:21 <mtreinish> and the code maintainence for the xml paths is actually pretty large
21:38:28 <devananda> I believe pecan/wsme has support for disabling XML support within consuming projects now
21:38:40 <sdague> devananda: this is about the test paths
21:38:48 <devananda> sdague: ah. nvm then :)
21:38:52 <mtreinish> so basically I just want consensus that we drop the xml tests everywhere
21:38:59 <dimsum__> +1
21:39:02 <mtreinish> even on stable branches, where we were running the tests before
21:39:08 <morganfainberg> ++
21:39:12 <thingee> +1
21:39:15 <mestery> ++
21:39:18 <sdague> and the patches are even ready to go - https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:rmxml,n,z
21:39:27 <jokke_> +1 lets take the hit when something breaks
21:39:37 <asalkeld> +1
21:39:39 * mtreinish is mad sdague beat me to those patches...
21:39:50 <sdague> mtreinish: you get to +A them
21:39:53 <ttx> everyone wants their name on that one
21:40:07 <sdague> well, go and +1 things now then
21:40:12 <mtreinish> sdague: you just want the top LOC stat for another cycle :)
21:40:17 <morganfainberg> Haha
21:40:25 <ttx> "largest contributor"
21:40:50 <sdague> I have moved all the nova unit tests around already this cycle, so until that patch is deleted from stackalytics, I probably already am
21:41:22 <dimsum__> haha
21:41:32 <apevec> nice: 	-lxml>=2.3
21:41:47 <sdague> apevec: yeh, that's a good bonus at the end as well
21:41:50 <ttx> ok, so it looks like this is pretty consensual
21:41:50 <morganfainberg> apevec: won't completely die.
21:42:00 <mtreinish> ok, well I guess that's the consensus I needed, I'll go ahead and start pushing through the changes then
21:42:02 <morganfainberg> We use lxml for SAML stuff still.
21:42:15 <sdague> morganfainberg: but you are going to fix that... right?
21:42:19 <morganfainberg> Working on fixing that.
21:42:20 <ttx> morganfainberg: you keystone folks just like this XML stuff don't you
21:42:25 <mtreinish> yeah it'll still get pulled in as a transitive dep until we drop the cli tests
21:42:29 <morganfainberg> Yeah. Xpath stuff.
21:42:56 <morganfainberg> ttx: I squashed using xacml for policy. No exta xml we don't need.
21:43:17 <ttx> heh
21:43:20 <morganfainberg> But I could reconsider if you like us to ;)
21:43:26 <ttx> OK, final words on that one ?
21:43:46 <ttx> #agreed please yes
21:44:03 <sdague> I would just say that people should register +1s on those patches just to have a good record of it as well
21:44:15 <morganfainberg> sdague: plan to post meeting.
21:44:31 <ttx> #topic Open discussion
21:44:39 <ttx> #info Release management had 1:1 syncs with liaisons today, summary/logs at:
21:44:45 <ttx> #link http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-11-25-09.00.html
21:45:19 <ttx> other announcements ? random pings to threads or reviews of general interests ?
21:45:28 <apevec> #info stable/juno release Dec 4, 2014 - freeze Nov 27, collecting release blockers/exceptions in https://etherpad.openstack.org/p/StableJuno
21:45:54 <ttx> apevec: you'll be the stable release manager for that one, right ?
21:45:54 <apevec> ttx, I guess bot will not take it from me?
21:45:59 <apevec> ttx, yes
21:46:02 <ttx> it will
21:46:41 <ttx> Some topics for next week meeting are already posted
21:46:46 <ttx> Convergence on specs process (johnthetubaguy)
21:46:58 <ttx> Future incompatible rework of client libraries (notmyname, morganfainberg)
21:47:42 <ttx> jeblair: any announcement from infraland ?
21:48:08 <sdague> also I've been starting a bunch of ML threads about test configurations I think we can prune from our system without losing anything significant - please keep an eye on those if you are interested in the subject
21:48:55 <ttx> Anything else, anyone ?
21:49:17 <thingee> ttx: last I heard in #openstack-infra, jeblair was going into some hole.
21:49:33 <jokke_> just letting anyone know who has interest, I'm the new guy looking after Glance Stable
21:49:59 <jokke_> So anything I might need to know is happily taken while I try to catch up
21:50:01 <sdague> jokke_: welcome aboard
21:50:34 <notmyname> I'm happy about the cleanup of tests in the CI
21:50:39 <notmyname> thanks sdague
21:50:58 <sdague> notmyname: no prob, thanks for the feedback to make sure we were doing this right
21:52:36 <ttx> alright.. final words...
21:52:52 <eglynn> Happy Thanksgiving y'all :)
21:53:33 <sdague> \o/
21:53:56 <jungleboyj> Happy THanksgiving!
21:54:25 <nikhil_k> Happy Thanksgiving!
21:54:45 <ttx> #endmeeting