21:01:37 #startmeeting project 21:01:38 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:42 o/ 21:01:43 The meeting name has been set to 'project' 21:01:48 Our agenda for today: 21:01:53 o/ 21:01:54 #link http://wiki.openstack.org/Meetings/ProjectMeeting 21:02:01 should be quick 21:02:05 2 days to final release 21:02:16 #topic News from the 1:1 sync points 21:02:22 o/ 21:02:23 Here is the log: 21:02:28 #link http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-10-14-08.02.html 21:02:35 We have RC3 windows currently opened for Cinder and Trove 21:02:40 o/ 21:02:45 both to be closed early tomorrow morning 21:02:53 Still considering a RC3 for Glance and Horizon 21:03:06 For Glance, the bugfixes are not in master yet 21:04:03 If you're glance-core, please consider helping and review https://review.openstack.org/#/c/128369/ 21:04:24 If it's not merged today we'll probably keep RC2 and promote that to final 21:04:47 On the Horizon side, we have a potential annoying bug 21:04:53 https://bugs.launchpad.net/horizon/+bug/1379761 21:04:55 Launchpad bug 1379761 in horizon "Asset compression does not happen unless debug mode is enabled" [Critical,Confirmed] 21:05:17 not really confirmed yet, and we don't have a fix either 21:05:29 Hi 21:05:41 we have a few more hours to get it under control 21:06:17 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 well, not necessarily fixed in master, but at least a fix proposed and reviewed 21:07:21 Questions on release status ? 21:08:37 #topic Other program news 21:08:43 Any other program with a quick announcement ? 21:08:54 Remember we have a TC election in progress -- please encourage all your team members to vote ! 21:09:25 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 #topic The scope of common requirements 21:10:48 I wanted to quickly discuss the scope of common requirements 21:10:58 We regularly have requests from non-integrated projects pushing their dependencies to openstack/requirements 21:11:10 I wanted to make sure I understand what the policy was on that and what it is today 21:11:22 So that we can document it and give a fair answer to those reviews 21:11:36 dhellmann: could you summarize what you know ? 21:11:52 we used to use the global requirements list ot manage the pypi cache visible to the CI systems 21:12:12 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 now it's only used in the requirements check job ? 21:12:39 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 integrated + incubated ? 21:13:24 honestly - I think this is the same grey area as when to add horizon support for a project 21:13:25 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 mordred: yeah 21:13:37 mordred: agree 21:13:38 mordred: ok 21:13:55 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 yah 21:14:07 because that keeps it fairly simple 21:14:15 although the question is who gets to propose a new req 21:14:19 however, the question is who gets to suggest adding new req -- right 21:14:19 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 ttx: yes, I'm sure we did 21:14:36 it should be fairly easy to figure out which those requirements are 21:14:39 it might be worth doing a pass 21:14:42 yah 21:14:54 * mordred thinks an incubated project should be able to propose a new req 21:15:05 yeah, that makes sense 21:15:08 so we should accept requirements for integrated projects and probably for incubated projects as well 21:15:09 and that it shoudl undergo the same sorts of scrutiny as we'd apply to other reqs 21:15:22 mordred: ++ 21:15:34 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 so I'd rather us be strict on the requirements rather than the proposers 21:15:53 one grey area for me has been optional requirements (eg, hardware-enablement libraries for optional 3rd party drivers) 21:16:10 that's another good question 21:16:10 not sure if anyone else is interested in discussing that right now, though :) 21:16:20 fwiw we were supposed to work on requirements convergence, i.e. advising projects to converge where possible 21:16:25 devananda: well, I did -1 a couple of patches related to that yesterday 21:16:27 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 that was something we discussed in ATL, but never came to do 21:16:53 dhellmann: AIUI, allowing those into global req's is the way we inform packagers that we care aboutthose things being available 21:16:53 s/be default/by default/ 21:16:53 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 (sorry if that's a dumb question) 21:17:21 eglynn: only if that stackforge project intends on being installed along side an openstack cloud 21:17:26 devananda: yeah, I was looking at them as not actually required, but that's a good point 21:17:43 clarkb: yeah, that was the case I'd in mind 21:17:50 eglynn: at least from a CI perspective that is the only locations for a conflict because devstack installs globally 21:18:41 dhellmann: there are several examples already in there of optional hardware-enablement requirements, specifically for cinder and ironic 21:18:45 is there a reason for global installation vs. promoting virtuan envs? 21:18:59 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 nikhil_k: system packages from the distros 21:19:18 nikhil_k: dependency convergence is useful for distros 21:19:20 devananda: ok, cool, I'll reverse my votes on those 21:19:46 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 dhellmann: the adding of brand new requirements is less of a concern I think that incompatible versioning of existing ones 21:20:01 dhellmann: hm, one sec. i'm looking again as it seems some were remoevd in juno 21:20:01 ... *than incompatible 21:20:05 makes sense 21:20:08 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 dhellmann: reverse which vote ? 21:20:45 ttx: on those patches for adding the hardware libs, but I'm waiting for devananda's analysis 21:21:02 ack 21:21:12 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 hmm. so the one I had in mind is gone: http://git.openstack.org/cgit/openstack/requirements/commit/?id=5c0fce08b8b59490f2f77d524ad06d0d18aef7b8 21:21:53 Oh good poitn 21:22:01 So for example we didn't add ironic client to requirements 21:22:02 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 dhellmann: yah, now I see only one, python-seamicroclient for Ironic. we can remove that too now, actually 21:22:09 We instead have this conditional import thing 21:22:35 zaneb: it is actually one list per branch 21:22:54 dhellmann: for latter we should probably encourage pulling from individual projects requirements 21:22:58 zaneb: you might be right, maybe we need an optional-uses.txt as well 21:23:02 dhellmann: so I think we should answer whether we *should* list these dependencies somewhere, so packagers know what to pull in 21:23:12 devananda: I agree 21:23:17 dhellmann: devananda: I would argue they go in the gloabl reqs list 21:23:24 its a global list 21:23:25 dhellmann: the challenge is that these libs are not listed in individual project reequirements anywhere 21:23:30 clarkb: ++ 21:23:30 so why are we deglobalizing it? 21:23:36 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 clarkb: ++ 21:24:09 devananda: they should end up in functional test suites somewhere, right? 21:24:39 dhellmann: maybe? upstream can't actually exercise them against the intended hardware 21:24:44 that's up to third-party tests 21:25:11 devananda: that's true for some of the cases, yes 21:26:37 dhellmann: let's chat with sdague at the summit about it more. 21:26:41 doesn't seem like we'll solve it right now 21:26:47 devananda: yeah 21:27:08 ttx: do you think we have the issues identified well enough for a cross-project session on this? 21:27:55 dhellmann: not sure -- maybe something for the infra/qa/rm meetup though 21:28:07 that works, too 21:28:16 I think that's the people who care about it anyway 21:28:27 * ttx adds to etherpad 21:28:28 I suspect some of the project folks will be interested, too 21:28:53 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 dhellmann: lots of stuff on the cross-project workshop etherpad already 21:29:56 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 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 ttx: yeah, that's going to be a tough list to pare down 21:30:39 oh that works out then, as long as the maintenance burden is in the right place 21:30:54 ok, anything else on that subject ? 21:31:05 When is this change occurring? 21:31:09 every time I open that Pandora box I'm more confused after the discussion than before 21:31:25 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 #topic Open discussion 21:33:33 Questions on summit ? 21:33:38 Anything else, anyone ? 21:34:54 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 And when do we get access to the tool to fill in our slots with actual sessions? 21:36:56 The deadline for the schedule is one week before summit starts 21:37:02 the sooner the better though 21:37:22 Also, I sent this email about resolving a meeting conflict: http://lists.openstack.org/pipermail/openstack-dev/2014-October/048305.html 21:37:24 I'll send (tomorrow hopefully) an email explaining how we'll push the schedule 21:37:32 ttx: so 27th? 21:37:33 I've not heard back, can I assume the PHP SDK meeting is no more? 21:37:57 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 ttx: Thanks for the summit schedule stuff. 21:38:11 (ODSREG being the software that did sumit.o.o before) 21:38:26 mestery: who was the chair? are they still around? 21:38:32 * mestery checks 21:38:33 mestery: yeah, maybe just remove the meeting from the meetings page 21:38:46 ttx: That was my thought as well, it's been months since hte last meeting 21:38:46 and ping me for the ical update 21:39:07 dolphm: Chair is mfer. 21:39:16 dhellmann: yeah, 24th/27th sounds about right 21:39:21 ttx: ok 21:40:25 no other question or topic to discuss ? 21:41:22 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 #endmeeting