21:01:37 <ttx> #startmeeting project
21:01:38 <openstack> Meeting started Tue Oct 14 21:01:37 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:42 <nikhil_k> o/
21:01:43 <openstack> The meeting name has been set to 'project'
21:01:48 <ttx> Our agenda for today:
21:01:53 <SlickNik> o/
21:01:54 <ttx> #link http://wiki.openstack.org/Meetings/ProjectMeeting
21:02:01 <ttx> should be quick
21:02:05 <ttx> 2 days to final release
21:02:16 <ttx> #topic News from the 1:1 sync points
21:02:22 <mestery> o/
21:02:23 <ttx> Here is the log:
21:02:28 <ttx> #link http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-10-14-08.02.html
21:02:35 <ttx> We have RC3 windows currently opened for Cinder and Trove
21:02:40 <david-lyle> o/
21:02:45 <ttx> both to be closed early tomorrow morning
21:02:53 <ttx> Still considering a RC3 for Glance and Horizon
21:03:06 <ttx> For Glance, the bugfixes are not in master yet
21:04:03 <ttx> If you're glance-core, please consider helping and review https://review.openstack.org/#/c/128369/
21:04:24 <ttx> If it's not merged today we'll probably keep RC2 and promote that to final
21:04:47 <ttx> On the Horizon side, we have a potential annoying bug
21:04:53 <ttx> https://bugs.launchpad.net/horizon/+bug/1379761
21:04:55 <uvirtbot> Launchpad bug 1379761 in horizon "Asset compression does not happen unless debug mode is enabled" [Critical,Confirmed]
21:05:17 <ttx> not really confirmed yet, and we don't have a fix either
21:05:29 <mikal> Hi
21:05:41 <ttx> we have a few more hours to get it under control
21:06:17 <ttx> if we can't get it fixed in master by the end of the day, we're exposing ourselves to a pretty emabarassing release note
21:06:49 <ttx> well, not necessarily fixed in master, but at least a fix proposed and reviewed
21:07:21 <ttx> Questions on release status ?
21:08:37 <ttx> #topic Other program news
21:08:43 <ttx> Any other program with a quick announcement ?
21:08:54 <ttx> Remember we have a TC election in progress -- please encourage all your team members to vote !
21:09:25 <dhellmann> we still have a few vacancies in the cross-project liaisons tables: https://wiki.openstack.org/wiki/CrossProjectLiaisons
21:09:58 * SergeyLukjanov here, totally destructed by jetlag
21:10:40 <ttx> #topic The scope of common requirements
21:10:48 <ttx> I wanted to quickly discuss the scope of common requirements
21:10:58 <ttx> We regularly have requests from non-integrated projects pushing their dependencies to openstack/requirements
21:11:10 <ttx> I wanted to make sure I understand what the policy was on that and what it is today
21:11:22 <ttx> So that we can document it and give a fair answer to those reviews
21:11:36 <ttx> dhellmann: could you summarize what you know ?
21:11:52 <dhellmann> we used to use the global requirements list ot manage the pypi cache visible to the CI systems
21:12:12 <dhellmann> we are now using a full pypi mirror, so test jobs can install any package available on pypi without it being listed in the global requirements
21:12:25 * mordred agrees with that
21:12:31 <ttx> now it's only used in the requirements check job ?
21:12:39 <dhellmann> so, my understanding is, we are trying to move the global requirements list to be actual requirements for building, packaging, testing, and running the integrated release projects
21:12:57 <ttx> integrated + incubated ?
21:13:24 <mordred> honestly - I think this is the same grey area as when to add horizon support for a project
21:13:25 <dhellmann> ttx: the projects that sync with the global requirements list are tested to ensure they are not adding new requirements and don't have incompatible requirements based on the global list
21:13:34 <dhellmann> mordred: yeah
21:13:37 <zaneb> mordred: agree
21:13:38 <ttx> mordred: ok
21:13:55 <dhellmann> I'd be happy if we just said "requirements sync means you live with the requirements, integrated projects must, everyone else may"
21:14:02 <mordred> yah
21:14:07 <dhellmann> because that keeps it fairly simple
21:14:15 <mordred> although the question is who gets to propose a new req
21:14:19 <dhellmann> however, the question is who gets to suggest adding new req -- right
21:14:19 <ttx> I suspect we inherited a lot of non-integrated requirements from the dfays where it was the only way to get something on the pip mirror -- did we ever clean the list ?
21:14:27 <dhellmann> ttx: yes, I'm sure we did
21:14:36 <dhellmann> it should be fairly easy to figure out which those requirements are
21:14:39 <mordred> it might be worth doing a pass
21:14:42 <mordred> yah
21:14:54 * mordred thinks an incubated project should be able to propose a new req
21:15:05 <dhellmann> yeah, that makes sense
21:15:08 <ttx> so we should accept requirements for integrated projects and probably for incubated projects as well
21:15:09 <mordred> and that it shoudl undergo the same sorts of scrutiny as we'd apply to other reqs
21:15:22 <devananda> mordred: ++
21:15:34 <dhellmann> I'm happy to be fairly lenient on which projects, if we can tighten up the list so we don't have 5 json parsers and rst->html converters and what not
21:15:47 <dhellmann> so I'd rather us be strict on the requirements rather than the proposers
21:15:53 <devananda> one grey area for me has been optional requirements (eg, hardware-enablement libraries for optional 3rd party drivers)
21:16:10 <dhellmann> that's another good question
21:16:10 <devananda> not sure if anyone else is interested in discussing that right now, though :)
21:16:20 <ttx> fwiw we were supposed to work on requirements convergence, i.e. advising projects to converge where possible
21:16:25 <dhellmann> devananda: well, I did -1 a couple of patches related to that yesterday
21:16:27 <david-lyle> mordred considering a contrib directory for Horizon that aren't linked into the project be default for incubated projects, etc, this directory could have it's own requirements
21:16:33 <ttx> that was something we discussed in ATL, but never came to do
21:16:53 <devananda> dhellmann: AIUI, allowing those into global req's is the way we inform packagers that we care aboutthose things being available
21:16:53 <david-lyle> s/be default/by default/
21:16:53 <eglynn> is there a problem if a non-integrated project say on stackforge specifies a requirement already in the global-requirements, but with an incompatible version range?
21:17:05 <eglynn> (sorry if that's a dumb question)
21:17:21 <clarkb> eglynn: only if that stackforge project intends on being installed along side an openstack cloud
21:17:26 <dhellmann> devananda: yeah, I was looking at them as not actually required, but that's a good point
21:17:43 <eglynn> clarkb: yeah, that was the case I'd in mind
21:17:50 <clarkb> eglynn: at least from a CI perspective that is the only locations for a conflict because devstack installs globally
21:18:41 <devananda> dhellmann: there are several examples already in there of optional hardware-enablement requirements, specifically for cinder and ironic
21:18:45 <nikhil_k> is there a reason for global installation vs. promoting virtuan envs?
21:18:59 <dhellmann> clarkb, eglynn : Solum is a good example of that. They had a requirement they wanted to add, but that we rejected because they aren't integrated.
21:19:10 <dhellmann> nikhil_k: system packages from the distros
21:19:18 <ttx> nikhil_k: dependency convergence is useful for distros
21:19:20 <dhellmann> devananda: ok, cool, I'll reverse my votes on those
21:19:46 <dhellmann> devananda: I was considering what I understood to be new rules for new changes, but it sounds like I was being too strict
21:19:46 <eglynn> dhellmann: the adding of brand new requirements is less of a concern I think that incompatible versioning of existing ones
21:20:01 <devananda> dhellmann: hm, one sec. i'm looking again as it seems some were remoevd in juno
21:20:01 <eglynn> ... *than incompatible
21:20:05 <nikhil_k> makes sense
21:20:08 <dhellmann> eglynn: well, if we're using this list to signal what "openstack requires" and something in the list isn't required, we're sending mixed signals
21:20:27 <ttx> dhellmann: reverse which vote ?
21:20:45 <dhellmann> ttx: on those patches for adding the hardware libs, but I'm waiting for devananda's analysis
21:21:02 <ttx> ack
21:21:12 <dhellmann> fwiw, we have a similar issue with oslo.messaging and libraries for talking to message brokers, and nova's driver libraries seem like another case of "optional but needed in some configurations"
21:21:14 <devananda> hmm. so the one I had in mind is gone: http://git.openstack.org/cgit/openstack/requirements/commit/?id=5c0fce08b8b59490f2f77d524ad06d0d18aef7b8
21:21:53 <mikal> Oh good poitn
21:22:01 <mikal> So for example we didn't add ironic client to requirements
21:22:02 <zaneb> dhellmann: seems like there are two uses - keeping versions inline and providing a list of requirements. One list is probably not able to do both jobs
21:22:08 <devananda> dhellmann: yah, now I see only one, python-seamicroclient for Ironic. we can remove that too now, actually
21:22:09 <mikal> We instead have this conditional import thing
21:22:35 <clarkb> zaneb: it is actually one list per branch
21:22:54 <zaneb> dhellmann: for latter we should probably encourage pulling from individual projects requirements
21:22:58 <dhellmann> zaneb: you might be right, maybe we need an optional-uses.txt as well
21:23:02 <devananda> dhellmann: so I think we should answer whether we *should* list these dependencies somewhere, so packagers know what to pull in
21:23:12 <dhellmann> devananda: I agree
21:23:17 <clarkb> dhellmann: devananda: I would argue they go in the gloabl reqs list
21:23:24 <clarkb> its a global list
21:23:25 <devananda> dhellmann: the challenge is that these libs are not listed in individual project reequirements anywhere
21:23:30 <ttx> clarkb: ++
21:23:30 <clarkb> so why are we deglobalizing it?
21:23:36 <dhellmann> I'm not sure I am comfortable coming to a conclusion on any of this without sdague's input, since he was driving a lot of the new requirements repo review guidelines
21:23:44 <devananda> clarkb: ++
21:24:09 <dhellmann> devananda: they should end up in functional test suites somewhere, right?
21:24:39 <devananda> dhellmann: maybe? upstream can't actually exercise them against the intended hardware
21:24:44 <devananda> that's up to third-party tests
21:25:11 <dhellmann> devananda: that's true for some of the cases, yes
21:26:37 <devananda> dhellmann: let's chat with sdague at the summit about it more.
21:26:41 <devananda> doesn't seem like we'll solve it right now
21:26:47 <dhellmann> devananda: yeah
21:27:08 <dhellmann> ttx: do you think we have the issues identified well enough for a cross-project session on this?
21:27:55 <ttx> dhellmann: not sure -- maybe something for the infra/qa/rm meetup though
21:28:07 <dhellmann> that works, too
21:28:16 <ttx> I think that's the people who care about it anyway
21:28:27 * ttx adds to etherpad
21:28:28 <dhellmann> I suspect some of the project folks will be interested, too
21:28:53 <dolphm> maybe I missed something, but if devstack supports non-integrated projects, and non-integrated projects are allowed to have conflicting requirements, isn't it devstack that will feel that pain?
21:29:55 <ttx> dhellmann: lots of stuff on the cross-project workshop etherpad already
21:29:56 <dhellmann> I think the support in devstack is going to be through hooks, isn't it? rather than directly putting the project install code in devstack
21:30:15 <dhellmann> dolphm: with the result being that anyone using devstack to deploy the non-integrated project that has conflicting requirements will feel the pain
21:30:28 <dhellmann> ttx: yeah, that's going to be a tough list to pare down
21:30:39 <dolphm> oh that works out then, as long as the maintenance burden is in the right place
21:30:54 <ttx> ok, anything else on that subject ?
21:31:05 <dolphm> When is this change occurring?
21:31:09 <ttx> every time I open that Pandora box I'm more confused after the discussion than before
21:31:25 <ttx> but then I can blame the late hour
21:31:28 * dhellmann wonders when ttx will learn to stop looking into boxes
21:33:27 <ttx> #topic Open discussion
21:33:33 <ttx> Questions on summit ?
21:33:38 <ttx> Anything else, anyone ?
21:34:54 <dhellmann> when do we need to set the schedule for the summit sessions?
21:35:07 * dhellmann apologies if this was announce on the ML, he has been offline most of the day
21:35:12 <mestery> And when do we get access to the tool to fill in our slots with actual sessions?
21:36:56 <ttx> The deadline for the schedule is one week before summit starts
21:37:02 <ttx> the sooner the better though
21:37:22 <mestery> Also, I sent this email about resolving a meeting conflict: http://lists.openstack.org/pipermail/openstack-dev/2014-October/048305.html
21:37:24 <ttx> I'll send (tomorrow hopefully) an email explaining how we'll push the schedule
21:37:32 <dhellmann> ttx: so 27th?
21:37:33 <mestery> I've not heard back, can I assume the PHP SDK meeting is no more?
21:37:57 <ttx> I basically have some ODSREG instance set up where you should be able to edit the "tbd" sessions and push them on your slots and push to sched
21:37:59 <mestery> ttx: Thanks for the summit schedule stuff.
21:38:11 <ttx> (ODSREG being the software that did sumit.o.o before)
21:38:26 <dolphm> mestery: who was the chair? are they still around?
21:38:32 * mestery checks
21:38:33 <ttx> mestery: yeah, maybe just remove the meeting from the meetings page
21:38:46 <mestery> ttx: That was my thought as well, it's been months since hte last meeting
21:38:46 <ttx> and ping me for the ical update
21:39:07 <mestery> dolphm: Chair is mfer.
21:39:16 <ttx> dhellmann: yeah, 24th/27th sounds about right
21:39:21 <dhellmann> ttx: ok
21:40:25 <ttx> no other question or topic to discuss ?
21:41:22 <ttx> well, let's call it a day then. All the RCs I haven't mentioned in the meeting are assumed final and good to promot eon my Thursday morning. So please yell if you think otherwise
21:41:45 <ttx> #endmeeting