21:02:01 #startmeeting project 21:02:01 Meeting started Tue Oct 28 21:02:01 2014 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:02:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:02:04 The meeting name has been set to 'project' 21:02:04 marun: if it was only 2 projects, it wouldn't have made the list anyway 21:02:10 Our agenda for today: 21:02:15 #link http://wiki.openstack.org/Meetings/ProjectMeeting 21:02:25 #topic Final Design Summit scheduling 21:02:28 dhellmann: likely, yes ... though those 2 projects usually have packed agendas and a hard time getting together 21:02:33 We seem to have everything on the agenda at this point, except... 21:02:36 so would have been worth considering ... 21:02:40 * ttx refreshes 21:02:44 russellb: we should call it "all projects" instead of "cross projects" 21:02:49 ttx, I've pushed sahara sessions 21:02:50 dhellmann: heh 21:03:02 except TripleO 21:03:05 dhellmann: cross project, with preference for all project 21:03:12 doesn't have a good ring to it 21:03:19 * russellb gets out of ttx's meeting ... 21:03:39 Note that I changed a few titles so that it's clearer which project each session belongs to 21:03:52 since they won't appear in cheerful colors in the mobile app 21:04:00 ttx: I have to drop off, but I'll look at the logs tonight in case there's something you need from me 21:04:10 dhellmann: sure! 21:04:11 ttx: thank you for that 21:04:17 One session is unassigned in QA 21:04:21 ttx, yeah, it's a good idea, last time there were some very unclear titles (one of them were sahara session :) ) 21:04:30 we just published the tentative cross-project workshops 21:04:55 ttx: mtreinish and i have a plan for that 21:04:59 * asalkeld goes to look at cross projects 21:05:00 mtreinish: do you plan to make use of that unassigned session ? 21:05:03 jeblair: oh 21:05:05 o/ 21:05:10 ttx: thanks for fixing the titles 21:05:23 ttx: iiuc, we have put a joint infra/qa topic on formalizing gating strategies in there 21:05:26 notmyname: feel free to refix them if they look bad 21:05:30 cross project stuff: http://kilodesignsummit.sched.org/overview/type/cross-project+workshops#.VFAFFXVGjUa 21:05:36 ttx: looks fine from my perspective 21:05:54 hmmm, the cross-project session on notifications made the cut 21:05:56 http://kilodesignsummit.sched.org/event/0b6e7e23da3d4fdcdc5cec0777b92c6a#.VFAE-opziVo 21:05:57 ttx: it was contingent on functional testing being approved as a cross project (which it was), so i believe it's spoken for and mtreinish should be able to push the updated schedule 21:06:01 everyone: note that if you want to edit scheduled sessions in my crappy UI, you'll have to unschedule slots before you can edit them 21:06:06 then schedule them again and push to sched 21:06:18 eglynn: and still need a session lead for that btw 21:06:28 ttx: yeah I'm going to update the schedule nowish 21:06:28 * eglynn wonders if we need the ceilometer-specific session on notifications-as-a-contract also 21:06:40 eglynn: would you be interested in leading it? 21:06:40 russellb: jd__ is leading the ceilo session 21:06:51 ah OK 21:06:55 ttx: I have verified firefox works for me, but not the latest chrome. re: my email earlier about pushing the sched 21:06:58 russellb, who leads these? 21:07:06 asalkeld: still trying to figure that out 21:07:12 We need leads for all the cross-project sessions, to make sure they are going somewhere 21:07:13 most sessions didn't have obvious proposers listed 21:07:19 I fleshed 2 out 21:07:20 asalkeld: i have you down for the upgrades one, as i think you proposed it? 21:07:25 russellb: etherpad link for that ? 21:07:27 ha and upgrades 21:07:31 https://etherpad.openstack.org/p/kilo-crossproject-summit-topics 21:07:32 russellb: I'll chat with jd__ about it tmrw, we could decide to "repurpose" the ceilo session 21:07:33 but big topics 21:07:47 happy for others to get involved 21:07:50 asalkeld: i know dansmith is willing to help on the upgrades one, to give info on what nova has been doing, and some related things coming 21:07:58 great 21:08:29 So, please check the proposed schedule for conflicts, maybe we can move things around to facilitate your life 21:08:31 it's a shame beekhof is not coming to summit 21:08:41 asalkeld: indeed, i've never met him in person 21:08:56 ttx: if mtreinish doesn't update the qa slot, here's text that could go into it: http://paste.openstack.org/show/126134/ 21:09:10 Although the cross-project workshops current schedule is alkready the result of a lot of tweaks and we have trouble changing it at this point without breaking someone 21:09:31 jeblair: I just pushed the update 21:09:34 jeblair: mtreinish said he would update nowish 21:09:34 breaking someone == causing conflicts? 21:09:40 eglynn: yes 21:09:49 cool, got it 21:09:54 russellb / ttx, will there be some kind of ml thread to figure out who is leading the cross project sessions 21:09:58 ttx, mtreinish: cool, thanks. sorry i missed that, it wasn't in yellow. :) 21:10:22 asalkeld: we have an etherpad, and russellb will push a thread about it 21:10:31 #link https://etherpad.openstack.org/p/kilo-crossproject-summit-topics 21:10:34 cool, thx 21:10:35 asalkeld: yes, starting a thread now-ish 21:10:55 for the future, should really have some more formatting around idea proposals 21:10:58 including a lead for every proposal 21:11:02 this was a mess 21:11:08 yip 21:11:19 downside of using an etherpad instead of the system from before 21:11:20 so I happy to help with both upgrades and ha 21:11:24 russellb: yes, the etherpad-driven thing works well until you reach critical mass of proposers 21:11:32 asalkeld: anyone else that should be listed for HA? 21:11:38 also, how about including the PTL group in the session voting? 21:11:46 (as opposed to just the TC) 21:12:04 russellb, you could ask for interested parties 21:12:10 OK 21:12:31 lots of RHT and miratis folk are interested in HA 21:12:38 * russellb nods 21:12:44 eglynn: yes, I agree 21:12:53 no need to limit voting 21:13:00 eglynn: +1 21:13:12 asalkeld: fabio will be there 21:13:18 nice 21:13:36 yeah just gonna suggest fabio also 21:13:36 i don't think there's a need to limit feedback. i do think there's a need to limit voting. we are asking the tc to exercise some judgement and discretion here. 21:14:37 jeblair: well, I think the PTLs have plenty of judgement and discretion 21:14:41 jeblair: the selection is not necessarily the highest votes, depends on what gets selected and what can be merged, too 21:15:05 so we exercise discretion when we make the final selection, not necessarily when we vote :) 21:15:11 ttx: you said "no need to limit voting" i was responding to 'voting' :) 21:15:30 ttx: that works :) 21:15:40 and is in fact what we did in infra 21:16:05 i also don't believe ptls or anyone was excluded this time 21:16:16 i believe i saw quite a bit of feedback on the etherpad 21:16:41 the preamble at the top discouraged non-TC-members from voting though 21:16:51 which is I think what eglynn is referring to 21:17:22 heck, we should use Gerrit for this 21:17:31 :) 21:17:39 yeah I assumed it was a TC-only deal on the voting, apols if I misread that 21:17:44 anyway, that's a tangent again 21:18:01 i have this natural inclination not to call something "voting" if the tally of results doesn't count. ttx, i think we're getting hung up on terminology :) 21:18:11 any other question/ urgent action to take wrt: Design Summit ? 21:18:24 jeblair: that's a thing we do indeed 21:18:50 ttx: is it a good time to bring up scheduling conflicts? 21:18:58 mtreinish: as good as any 21:19:10 ttx: when does the schedule need to be absolute finalized? 21:19:12 ttx, do we have a venue map? (what's the distance between design summit sessions and summit itself) 21:19:25 it's literally across the street 21:19:35 I don't have a handy map 21:19:46 well I haven't seen mikal, but there is overlap with nova's functional testing and the qa track 21:19:47 i could only find one for the conference 21:19:48 ttx, ok, across the street is enough to know, thx 21:20:01 mtreinish: mikal said he had to drop 21:20:04 eglynn: in theory, today, but if we push changes they should be picked up until the end of the week 21:20:20 jeblair: ah, ok 21:20:28 the mobile app does async updates with sched 21:20:44 so the sooner we are final the less confusion we generate 21:20:52 cool 21:21:07 * ttx looks for a venue map 21:21:22 https://www.openstack.org/summit/openstack-paris-summit-2014/venue-maps/ seems to be conference only 21:21:30 ttx, jeblair, I'll join infra/qa/release meetup only afternoon, so, I hope not to miss something important 21:21:51 SergeyLukjanov: good to know, thanks 21:22:15 SergeyLukjanov: ok 21:22:54 (due to the sahara meetup before afternoon) 21:24:04 pwd 21:24:28 /tmp 21:24:32 :) 21:24:46 ok, any other question ? 21:25:04 ttx: i guess that's still a no on the design summit map? 21:25:05 all good, looking forward to getting to paris 21:25:12 jeblair: asking 21:26:02 ttx: also, is there an indoor passage between the two? 21:26:15 jeblair: no indoor passage for sure 21:26:21 it's two separate buildings. 21:26:38 so bring our umbrellas to lunch :) 21:27:01 you can survive crossing the street in open air, I think :) 21:27:05 ok, next topic 21:27:12 #topic Explicitly state which projects can add requirements 21:27:16 #link https://review.openstack.org/#/c/130245 21:27:30 Not exactly sure what we need to discuss there 21:28:15 dhellmann, sdague: ? 21:28:19 so "including stackforge" is new? 21:28:24 it's a major proposed policy change, yes 21:28:25 I think the idea was to check it with all PTLs 21:28:34 it even has a cross-project summit session 21:28:44 before it gets accepted and it's a pain to rollback 21:28:57 :q 21:29:18 there is also some infrastructure being added to devstack to make it probably not needed, so that should postpone 21:29:25 IMO due to the crossproject session it should be postponed to summit / after summit 21:29:26 i think it would have less impact on ptls than the requirements reviewers and distros, whare are actually the primary audience for the requirements repo 21:29:31 maybe we should all do our homework and read that, and keep the discussion about that for the cross-project session ? 21:29:44 yeah 21:29:51 big impact to distros 21:29:51 +1 21:30:15 also do we have a policy on what gets accepted 21:30:25 or is it open 21:30:37 asalkeld: https://wiki.openstack.org/wiki/Requirements 21:31:11 jeblair, so that part is staying the same then 21:31:12 one more issue - for now if we have some lib in global req. than we're trying to avoiding alt. lib too instead of using the first one 21:31:36 but in case if we'll open global reqs. it'll start looking like pypi.python.org eventually 21:32:33 I'm feeling myself disconnected from IRC 21:32:39 don't we already accept requirements from stackforge projects? ... is this just making that policy explicit? 21:32:56 eglynn, not to my knowledge 21:33:05 eglynn: we do not accept requirements from stackforge, and for good reason 21:33:38 jeblair, are you against this then? 21:33:53 just seeing the "and for good reason" 21:34:02 asalkeld: yes, i agree with sdague, both in the review, and in the alternate proposal to resolve the issue 21:34:11 ok 21:34:32 * jeblair reviews that change :) 21:34:33 jeblair: I was thinking specifically of posix_ipc for stackforge/tooz 21:34:45 jeblair: ... but I see now that was originally added for oslo lockutils 21:35:25 i like the "soft updating" 21:35:30 i reviewed the other ones (that implement soft update) 21:35:45 I wonder how global-requirements would work in the big tent proposal 21:36:33 jogo, "big tent" still doesn't mean totally unfiltered surely 21:36:53 jeblair: similarly for dependency version lower bounds that are motivated by stackforge usage? 21:36:55 jogo: yeah, definitely worth talking about. i believe the main thing we get from it is the ability for distros to sanely, well, distribute "openstack" 21:37:13 Part of the issue is that we use global-requirements for multiple things 21:37:20 hopefully it is sensible but more open acceptance 21:37:24 one of them is general dependency convergence 21:37:28 (... where the same dependency is also used by another project under openstack/ ) 21:37:35 others are more integration/testing related 21:37:37 so i think the answer to that is probably something like "it's small, for the stuff we think is really the core of openstack" or "it's big and anyone who wants to be part of the big tent uses it" 21:38:18 ttx: i think integration/testing is still part of the primary use -- dependency convergence + compatability 21:38:41 FYI Maps of Le Meridien shall be uploaded tonight, so that "venue maps" thing should hopefuly look better tomorrow 21:38:51 it's not to select a version of something we test with, it's so that we're testing with the set of dependencies we have selected for the project as a whole 21:40:13 ttx: thanks! 21:40:20 unless everyone uses docker this is going to get messy 21:40:36 asalkeld: what's going to get messy? 21:40:36 (big tent and global requirements) 21:40:43 asalkeld: fyi, heat already uses docker-py, just not in requirements 21:41:07 dims__, i mean to distribute openstack services 21:41:20 docker-py stuff is in contrib/ 21:41:26 asalkeld: ack 21:41:38 OK, so I think the next step on that one is the cross-project workshop on requirements at the summit 21:41:57 asalkeld: maybe? or maybe part of the big tent is taking a hard line on requirements to prevent it from getting messy... enough non-openstack projects want requirements enforcement that it seems like a possibility to me. 21:42:03 I'll leave a note on the review 21:42:13 jeblair, maybe 21:42:14 jeblair: just to clarify on the version lower bounds ... not kosher to require redis>=2.10.0 if motivated by tooz usage of redis, but kosher if say motivated by zaqar? 21:43:19 eglynn: correct. (and that's why we're talking about tents) 21:43:46 #topic Open discussion 21:43:51 Anything else, anyone ? 21:44:06 nope 21:44:08 er, python 3.4! 21:44:23 We should almost all be together in a few days 21:44:29 #link https://etherpad.openstack.org/p/py34-transition 21:44:44 we're waiting for a couple of bugs to clear through an ubuntu sru to trusty 21:45:05 but also i'm worried glanceclient won't get their tests working in time for us to cut them over from 3.3 to 3.4 21:45:18 seeing lots of client related patches 21:45:26 #link http://lists.openstack.org/pipermail/openstack-dev/2014-October/048659.html 21:45:41 #link https://launchpad.net/bugs/1382582 21:45:43 Launchpad bug 1382582 in python-glanceclient "untestable in Python 3.4" [Medium,Confirmed] 21:46:03 asalkeld: yes, the glanceclient patches are great. i've already tested them and they're working 21:46:05 nikhil_k: ^ 21:46:09 er, heatclient 21:46:21 cool 21:46:25 Looks like Glance is on the critical path 21:46:29 so i think heatclient is on track 21:47:05 but yeah, glanceclient may end up delaying our switch off the old py3k-precise nodes, or we might have to temporarily drop py3k testing for that project 21:47:10 fungi: not sure nikhil_k is around. Looks like you should pay a visit to the Glance crew next week 21:47:17 or we enforce python3.4 testing for it :) 21:47:23 i'll lurk in their team pod menacingly 21:47:43 * fungi makes sure to pack his most menacing hawaiian shirt 21:48:23 :-) 21:48:25 ok, one more minute for questions before I close the shop 21:48:34 * nikhil_k jumping between channels 21:48:48 fungi: grab nikhil_k while he is here! 21:49:08 nikhil_k: just asking for the glanceclient devs to bump priority on https://launchpad.net/bugs/1382582 if possible 21:49:10 Launchpad bug 1382582 in python-glanceclient "untestable in Python 3.4" [Medium,Confirmed] 21:49:31 fungi: noted 21:49:36 and planning for contingencies if needed 21:49:54 fungi: would that be sufficient on master or need a version? 21:50:02 nikhil_k: master will be fine 21:50:20 just want to make sure we can get it passing 3.4 tests before we drop 3.3 tests in infra 21:50:50 fungi: I'm sure I'd your email on my to-do list 21:51:06 nikhil_k: thanks! 21:51:08 will bring this up in the meeting 21:51:21 alrighty then. See you all in a few days! 21:51:24 #endmeeting