21:01:00 #startmeeting Solum Team Meeting 21:01:00 Meeting started Tue Mar 24 21:01:00 2015 UTC and is due to finish in 60 minutes. The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:01 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:04 The meeting name has been set to 'solum_team_meeting' 21:01:21 #topic https://wiki.openstack.org/wiki/Meetings/Solum#Agenda_for_2015-03-24_2100_UTC Our Agenda 21:01:39 #topic Roll Call 21:01:40 Gilbert Pilz 21:01:40 ed cranford 21:01:44 Adrian Otto 21:01:46 murali allada 21:01:48 james li 21:01:51 devdatta 21:02:06 Melissa Kam 21:03:20 hi gpilz, datsun180b, muralia2, james_li, devdatta, mkam 21:03:30 hi adrian 21:03:44 #topic Announcements 21:04:09 1) The Solum speaking session was not chosen for the OpenStack Summit in Vancouver…. 21:04:20 Dimitry Ushakov 21:04:34 shoot 21:04:48 however, I do expect there is still a place for Solum at the Design Summit in the OpenSource at OpenStack track or "Other Projects" track. 21:06:06 2) PTL Elections 21:06:21 community projects are not required to hold PTL elections, but we do anyway. 21:07:08 in the past we have tried not to conflict with open elections for OpenStack projects, as there has been suggestions that having dozens of concurrent unrelated elections is confusing for the electorate 21:07:39 typically the PTL is selected by the contributors in the prior two releases. 21:08:29 how would you all feel about having a call for candidacy that is sent to all of the contributors by direct email instead of using the openstack-dev wiki? 21:08:56 That sounds fine to me 21:09:05 you mean openstack-dev mailing list? sounds fine 21:09:10 in the event that there is > 1 candidate, an election would be held. 21:10:05 we would have an agenda item in our next team meeting where candidacy could be announced by any challenger. 21:10:05 thoughts on this approach, versus an exact repeat of what we did in the last release cycle? 21:10:29 note that you can only run for the PTL position if you have contributed code to the prior release 21:10:29 I think we have something like 19 qualified individuals 21:10:37 devkulkarni: no 21:11:02 the specific request was that we not use openstack-dev@lists.openstack.org to request candidacy notices 21:11:10 I think no harm in trying this approach 21:11:16 ok 21:11:25 but instead send out direct email (by BCC) to individuals who have contributed 21:11:25 ok by me 21:11:31 right.. I just meant that in your earlier comment you had said openstack-dev wiki 21:11:39 oh, yes 21:11:55 the "wiki" meant that we would record the plan on our wiki on an election subpage 21:11:58 for posterity 21:12:21 ah, got it 21:12:26 the aim here is to balance the interests of open community and transparency with the sensitivities of running the OpenStack elections 21:13:02 on a similar note — there have been emails on the dev list about not using it to announce core reviewer additions as well 21:13:04 I will record this as an #agreed if there are no objections 21:13:10 +1 21:13:17 +1 21:13:24 +1 21:13:26 devkulkarni: no, core reviewer proposals may still use the list 21:13:32 +1 21:13:37 this is about selection of project PTLs 21:13:59 +1 21:14:03 right.. I am just saying that I have recently seen emails where folks have argued against using the dev mailing list to announce reviewer additions. 21:14:26 yes, there is an alternate idea about that 21:14:30 in fact, I haven't seen emails that say that PTL candidacy emails should not be sent to the dev list.. may be I missed those. 21:14:37 basically to have a governance file in the code repo 21:14:42 and you vote in Gerrit 21:14:49 I see 21:15:00 there has also been talk about having a stackforge elections repo, but that is some time out 21:16:12 #agreed the solum PTL shall be selected by the project contributors. Contributors will be invited to announce candidacy at the 2015-03-31 team meeting. If no new candidates are announced during that section of the team meeting IRC agenda, the incumbent PTL will remain in service. 21:16:27 I can still undo that if there are any objections 21:17:02 ok, any other announcements from team members this week? 21:17:36 #topic Review Action Items 21:17:39 (none) 21:17:49 #topic Blueprint/Task Review 21:17:54 adrian_otto: quick question.. do you have a link to the accepted talks for ODS? 21:18:07 yes. one moment 21:18:53 #link https://openstacksummitmay2015vancouver.sched.org/ OpenStack Summit Agenda 21:19:02 thanks adrian_otto 21:19:04 devkulkarni: is that what you meant? 21:19:13 yep 21:19:18 ok, great. 21:19:21 1) (silkey) Pin requests to 2.4.3 https://review.openstack.org/#/c/165603/ 21:19:30 is silkey present? 21:19:52 no.. but I can talk to that task 21:20:11 Nick Silkey made his first contribution to the OpenStack ecosystem in Solum 21:20:27 Jenkins disliked the proposal 21:20:37 devkulkarni: you have the floor 21:20:38 basically on the python-solumclient we are getting a SSL cert warning which can be prevented if we use 21:20:49 the specific version of requests 21:20:54 that is there in the review 21:21:15 however, global-requirements does not yet have the 2.4.3 version 21:21:44 we could use soft requirements probably 21:21:46 could we use "requests>=2.4.3" instead? If not, why not? 21:21:46 I think in fact global's requests is ahead of 2.4.3, which is our problem 21:22:46 After 2.4.3 a deprecation message for an SSL issue involving a missing value in a cert is shown with every use 21:22:49 so 2.5.0 breaks us 21:23:17 datsun180b: what version is global's requests? 21:23:32 requests>=2.2.0,!=2.4.0 21:24:09 soft requirements is for devstack, not sure a devstack is spun up for solum CLIENT tests 21:24:11 and this isn't so much a problem for solum general as it is for rackspace but i could be wrong about that 21:24:14 in the name of transparency, let's point out that this is an issue solely with Rackspace's certificates. HP doesn't have this problem. 21:24:17 datsun180b: +1 21:24:35 HP cloud* 21:24:51 since those are the two main cloud providers we use in upstream 21:24:52 there has been some discussion about adjusting all of our certs 21:25:04 so this problem may vanish if we take no action 21:25:12 are you all aware of this initiative? 21:25:14 yes sir...but it's dependent on Rackspace's cloud identity 21:25:24 there's no public timeline available 21:26:36 ok, so what I'm not sure about in this review is that all the gate tests are marked with SUCCESS, but Jenkins voted -1. I don't see why. 21:26:53 strictly because that change to requests doesn't jive with global-reqs 21:27:01 adrian_otto: click on 'toggle ci' 21:27:18 you will see the requirements don't match issue 21:27:33 where is "toggle ci"? 21:27:46 at the very bottom of the review page 21:27:54 #link https://review.openstack.org/#/c/165603/ 21:27:59 oh, I found it, thanks!! 21:29:34 #link http://logs.openstack.org/03/165603/2/check/gate-python-solumclient-requirements/6c8a53a/console.html#_2015-03-18_22_38_00_003 the gate objection 21:30:11 what options do we have to work around this? 21:30:17 we checked with rackspace's cloud orchestration team.. they have similar issue, but they are ignoring it for now 21:30:52 what is the community impact if we ignore this too? 21:31:08 probably none, right? 21:31:09 frankly, not much 21:31:12 epsilon squared 21:31:13 yeah 21:31:42 ok, so I suggest we fix that in an internal patch for now if it's custome rimpacting 21:31:56 and leave upstream alone 21:32:06 fair enough? 21:32:12 sounds good to me 21:32:21 any other viewpoints to consider? 21:32:37 just need to close silkey's patch then, and explain why 21:32:49 I will take care of that right now 21:33:05 while I do that, do team members have other work items to discuss today? 21:33:21 thank you kindly 21:33:27 adrian_otto: I have one 21:33:40 proceed! 21:33:50 I remember we had discussed sometime back about release of python-solumclient on a periodic cadence 21:34:11 what do you think about doing a release on a specific day each week — at your convenience 21:34:49 yeah, I'm open to that 21:34:55 cool 21:35:00 in fact I am willing to cut a release on demand any time you all want. 21:35:36 that will be awesome as well.. whichever is the most convenient for you 21:35:39 I should be able to act on those sort of requests on the same day. 21:35:42 is the process any more complicated than you tagging a release? 21:35:53 it's really easy 21:36:03 the only hard part is signing the release with GPG 21:36:03 is it so easy it's documented somewhere 21:36:15 basides that it's a couple of git commands 21:36:20 git -t tag 21:36:23 git push gerrit 21:36:24 also, on that note, I remember you had also mentioned about making it such that the process is automated triggered on every merge 21:36:25 that's it. 21:36:50 devkulkarni: I think that may be possibe 21:37:16 we can discuss to find the right effort/benefit ratio 21:37:21 cool.. but probably we could do that later.. 21:37:22 right 21:37:40 if I'm not fast enough doing it by request, then we should see about an automation approach 21:38:02 would you need to deputize someone else with a permission you have that we lack? 21:38:03 :) sounds good. 21:38:40 and, should it happen, would those permissions transfer to any future PTL, or would you still be the one to cut those releases? 21:39:14 all i'm trying to do is reduce the number of "adrian plz cut a release kthx" emails in the future 21:39:30 the individual with the PTL role can tag releases 21:39:53 the only gotcha is that that individual is required to GPG sign the commit 21:40:56 it may also be possible to have multiple individuals to whom that access level is delegated. 21:41:05 we could explore that option as well 21:41:42 +1 to datsun180b.. +1 to adrian_otto 21:41:48 so ping me on IRC, and if no answer then email me. You all have my phone number too, you can SMS. 21:41:58 the only time I don't answer an SMS is if I'm in flight. 21:42:18 i foresee a couple situations where you might be called upon more than once a day, just trying to test the structure before we have to put any real weight on it 21:42:37 that's fine with me 21:42:44 adrian_otto: the last four digits — are they 5417 or 6417 21:42:50 honestly, this process takes just a couple of minutes 21:43:11 devkulkarni: actually neither. I will PRIVMSG it to you. 21:43:19 ok.. sounds good 21:44:41 thanks adrian_otto 21:46:51 ok 21:46:59 #topic OpenDiscussion 21:47:08 #topic Open Discussion 21:47:40 so take a look at this: http://status.openstack.org/zuul/ and filter for solum 21:47:51 oh right!! F20 gate 21:48:01 james_li: want to take this one? 21:48:08 ok, so I might also mention that Magnum was approved to join the OpenStack project list about an hour ago by unanimous vote of the TC. This might be a good time for Solum to think about any future plans for Magnum integration. 21:48:14 59 hours, 32 hours, 22 hours, 2 and a half hours 21:48:22 just talked with infra guys 21:48:31 the F20 node won't boot 21:48:32 again 21:48:36 any longer and our tasks are going to have to be portrayed by James Franco 21:48:46 adrian_otto: congratulations 21:48:52 thanks devkulkarni 21:48:56 oh congratulations magnum 21:49:14 woohoo! congrats 21:49:17 so they suggested we switch to F21 or centos, the latter is better in their opinion 21:49:19 will be nice to start discussing where/how magnum can fit in with solum. 21:49:31 james_li: oh is that so? 21:49:33 nice! 21:49:36 so what are the next steps? 21:50:00 devkulkarni: for Magnum? 21:50:14 since we use F20 for some historical reasons and it is now non-voting 21:50:25 adrian_otto: could one of the magnum folks write a spec of possible integration points .. will it replace heat within solum? will it sit next to heat? 21:50:26 I would say switch to centos 21:50:39 adrian_otto: sorry.. I was asking for next steps to james_li 21:50:42 james_li: +1 21:51:08 i'm finding the parallel discussion of Magnum and the f20 gate confusing 21:51:12 devkulkarni: there are multiple ways it might fit 21:51:30 but let's revisit that later 21:51:34 there is no hurry 21:51:58 adrian_otto: sure 21:52:24 going back to f20 21:52:35 james_li: what is required to switch over to centos? 21:52:44 could we disable f20 first quickly? 21:53:00 I think that's in the project-config repo now 21:53:07 it might help to explain the why before we worry about the if and the how 21:53:07 for centos gate — we will have to put in some efforts to see that everything works 21:53:41 we need infra guys approval for any changes 21:53:50 to gate 21:54:39 james_li: yes.. but from process point-of-view, what are the steps? 1) disable f20 2) test with centos 3) propose addition of centos 21:54:40 ? 21:55:13 for centos we definitely needs infra guys' help for amending the patch to change gate config, thats some additional work 21:55:40 for disabling F20 we can handle the patch by ourselves, just wait for their approval 21:56:03 got it.. so could we make the decision right now to disable f20? what do others think? 21:56:15 i _think_ it's just a matter of removing a line or two from infra's project-config 21:56:25 +1 for disabling F20 for now 21:56:36 datsun180b: yep.. the change should be straight forward. 21:56:42 of course, testing that kind of change is super tough without feedback from the gate! 21:56:51 I am more concerned about we being a single flavor (Ubuntu) system in the time being 21:57:12 later we can add a centos gate 21:57:13 devkulkarni: counterarguments: git and docker 21:57:25 #link https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/solum.yaml Solum Gate Jobs 21:57:31 having said that — I do care about patches getting merged — so I am a +1 to turn off f20 21:57:32 I don't see the fedora job in there 21:58:05 adrian_otto: gate-solum-devstack-dsvm-f20 21:58:15 adrian_otto: line 49 21:58:24 yep, that's what we need to patch 21:58:43 ok, time to wrap up here 21:58:47 just removing that line? i'll pull the trigger on this review then 21:59:05 you remove that job entry, yes 21:59:20 oh this diff doesn't say anything near a line 49 21:59:40 Our nextmeeting is 2015-03-31 at 2100 UTC. See you all then! 21:59:45 #endmeeting