15:01:19 #startmeeting third-party 15:01:20 Meeting started Mon Jun 29 15:01:19 2015 UTC and is due to finish in 60 minutes. The chair is anteaya. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:25 The meeting name has been set to 'third_party' 15:01:41 anyone here for the third party meeting? 15:01:50 o/ 15:01:52 Hi 15:02:00 o/ 15:02:25 o/ 15:02:32 o/ 15:02:49 hello 15:03:03 thanks to asselin for charing last weeks meeting 15:03:55 reminder that asselin's common-ci sprint is coming up July 8 & 9 15:03:59 #link https://wiki.openstack.org/wiki/VirtualSprints#OpenStack_Common-CI_Solution 15:04:23 does anyone have anything they wish to discuss at today's third party meeting? 15:04:50 0o0 15:05:06 taturn: you are in a meeting channel 15:05:29 taturn: if you wish to participate in the third party meeting you are welcome, but please contribute something of use 15:05:42 taturn: the general discussion channel is #openstack-dev 15:06:12 sorry i am new here 15:06:33 let me use translater to know what u said i am a chinese 15:06:36 lol 15:06:36 taturn: yeah I saw that in the rally meeting 15:06:47 taturn: I gave you some guidance 15:07:07 so does anyone have anything pertient to share at today's meeting 15:08:08 so if noone has anything of any importance to share at today's third party meeting 15:08:21 not me 15:08:23 how about we find more productive uses of our time? 15:08:30 hi lennyb, thanks 15:08:41 our Zuul occasionally falls into busyloops of a kind: http://paste.openstack.org/show/325044/ 15:09:03 which happens after reconfiguration 15:09:24 does it ever break out of the loop? 15:09:41 anteaya: Not until zuul-server restarted 15:10:03 so after you reconfigure zuul you need to restart it? 15:10:29 eantyshev: are you using the latest upstream? 15:10:30 sometimes, yes 15:10:38 i saw that happen to mine on friday night, filled up like 70GB of log file with that error :( 15:10:51 patrickeast: was a zuul restart the solution? 15:10:53 i did the same thing, killed zuul, pulled all the latest changes and restarted 15:11:09 unsure if there was an update that fixed it, but it went away 15:11:11 lennyb: sure 15:11:31 eantyshev: when did you first notice this behaviour? 15:12:23 yantyshev: may it be related to the late patches that were added. there was some fix related to the loop ( I even think it was yours ) 15:13:05 anteaya: that happened last Thursday at 3pm 15:13:26 eantyshev: so this is recent behaviour then 15:13:43 eantyshev: next time you restart zuul can you be sure to pull the most recent patches 15:14:04 eantyshev: and if the looping behaviour persists are you willing to file a bug against zuul? 15:14:34 #link http://paste.openstack.org/show/325044/ 15:14:35 anteaya: it dissapears every time after restart 15:15:04 eantyshev: right, I'm asking if you are willing to pull the latest patches and evaluate if a patchset fixes the situation 15:15:20 eantyshev: and if it doesn't, if you are willing to file a bug against zuul 15:16:34 eantyshev: are you willing to file a bug against zuul if you keep seeing this? 15:16:36 anteaya: Zuul is up-to-date, AFAIU, head last updated on Jun12 (Support external cross-project dependencies in ui). And I'd rather investigate it myself, though 15:16:47 eantyshev: oh okay 15:17:01 eantyshev: can you let us know if you find anything? 15:17:16 why not file a bug and assign it to yourself? 15:17:16 a bug report allows others to track progress 15:17:23 patrickeast: good point 15:17:38 and you can update teh bug status as you work on it 15:17:57 then I'll make this a bug 15:18:02 it is a workflow which is considered friendlier in an open source spac 15:18:06 thanks eantyshev 15:18:36 #link https://storyboard.openstack.org/#!/project/679 15:18:48 is the storyboard link for zuul 15:18:56 anything more on this topic? 15:19:29 patrickeast: did you experienced busyloops too? can you share the piece of your debug logs? 15:20:35 eantyshev: yea i’ll go dig up the links 15:21:22 does anyone have any other topic to discuss? 15:21:49 eantyshev: http://paste.openstack.org/show/321511/ 15:22:01 same callstack, different patchset 15:22:09 hi all, sorry for being late 15:22:14 #link http://paste.openstack.org/show/321511/ 15:22:20 ociuhandu: np 15:22:30 anteaya: I’ve seen a quite long thread discussing about third-party CI voting rights 15:22:31 ociuhandu: do you have anything you wish to discuss today? 15:22:53 ociuhandu: yes the discussion is taking place on the mailing list 15:23:04 and voting isn't a right, it is at best a permission 15:23:04 patrickeast: thanks! 15:23:18 and it seems that the topic heads towards non-voting CIs 15:23:33 the decision to allow any ci voting permissions lies with the ptl of the project in question 15:23:53 individual projects can make the decision that works best for their project 15:24:03 I don't expect openstack wide consensous on this 15:24:24 the ability to grant permissions on cis lies with the ptl of the project in question 15:25:47 anteaya: from what I have seen it seems that though this started from one project it’s now involving multiple projects and they seem to lean towards the same direction 15:26:17 #link http://lists.openstack.org/pipermail/openstack-dev/2015-June/067992.html 15:26:24 ociuhandu: okay 15:26:28 but i see your point, so we’ll have to discuss them with the individual project ptls 15:26:37 did you have any point you wanted to make about that? 15:26:45 yes 15:26:53 I have no say in what the decision is 15:27:34 I encourage you to participate in the thread if you have a perspective you wish to ensure others know about 15:27:48 well, as a general idea i feel that telling now any third-party that we’ll revoke any kind of voting rights kind of defeats the purpose of the CI requirements in the first place 15:28:10 you are welcome to have that opinion 15:28:14 as in, you have to have a reliable CI but we don’t let you say if a patch is good or not 15:28:17 ociuhandu, I disagree, comments are useful, if they are reliable 15:28:28 and I do agree that it is frustrating from the perspective of teh ci operators 15:28:35 as the message seems to keep changing 15:28:36 (since anyway everyone is complaining about the noise the CIs add to the commenting section) 15:29:00 however the infra message is clear, if you have a gerrit ci account, you are expected to adheare to infra requirements 15:29:11 all else is up to the individual projects 15:29:28 hi all 15:29:32 ok, thanks 15:29:33 wznoinsk: hello 15:29:43 ociuhandu: welcome, thanks for bringing it up 15:30:06 ociuhandu: I encourage you to comment on the mailing list thread, and discuss it with the project you are testing 15:30:42 anything more on this topic? 15:31:10 ociuhandu: I think it came down with recent changes to not to ahve integrated releases 15:31:11 anteaya: will do, just wanted to get a deeper understanding on this from the infra perspective 15:31:45 ociuhandu: sure, the infra perspective is about gerrit accounts, voting permissions and many other decisions are up to the projects 15:32:47 does anyone have anything else they wish to discuss today? 15:32:53 in short, cores will be looking at CIs results less by the looks of things 15:33:17 wznoinsk: I don't understand either of your last two statements 15:33:27 wznoinsk: can you try again to express your point? 15:35:18 or shall we move on? 15:35:33 * anteaya is uncertain if waiting is a worthy use of time 15:35:55 I'm not trying to dismiss what you said wznoinsk, I'm trying to understand it 15:36:08 anteaya: sure, when there was any enforcing of the features in releases, cores/ptls were interested in the tests CI provide as a wider testing ground for features, now when we report rather than enforce and a lot of neutron code went out of tree, cores/ptl are not directly looking at whether they work or not 15:36:26 oh 15:36:47 well to be honest it never was the job of the core reviewers to review the ci jobs 15:36:58 to me CIs are becoming the help to features devs only 15:37:07 it was and is the responbility of the ci/driver maintainer 15:37:20 well becoming/is yes 15:37:30 anteaya: not saying it was, but as for features that were promised in a release it was a good testing ground 15:37:33 it just is taking some folks a while to realize that 15:37:37 no it was 15:37:41 I am saying it was and is 15:38:32 the ci results are meant for the consumption of the driver maintainer 15:38:57 except in the case of infra ci 15:39:01 and others just look to see if the driver maintainer is paying attention or not 15:39:01 the help to devs yes, I never said cores job was to look at the CI results, it was more of an additional info 15:39:16 krtaylor: no, especially in the case of infra ci 15:39:29 wznoinsk: right 15:40:01 the addtional info being wether the driver maintainer was paying attention or not 15:40:22 anything more here? 15:40:54 I sort of don't like the fact the more loose rights we have now (big tent, 4 OPENs etc) the less we pay attention to proper testing of all of that... I'm not saying cores/ptls should be looking after it tho 15:41:11 wznoinsk: I don't like it either 15:41:25 wznoinsk: I am out of suggestions for what to do about it though 15:41:41 wznoinsk: if you have any contructive thoughts I am looking for suggestions 15:41:43 ideally some sort of certified CI badge would be good to have 15:42:21 I'm not certifying anything 15:42:33 some CI ops are interest-less, some are looking after well, but may stop doing so if there's no real value it in anymore - that would hurt openstack testing 15:43:03 I have opinions on the use of the word certified 15:43:16 here is a thread from last year on the topic in case you missed it 15:43:20 #link http://lists.openstack.org/pipermail/openstack-dev/2014-June/036933.html 15:43:34 wznoinsk: I agree 15:43:40 values are important 15:43:58 not necessarily "certified" but at least recognized as good. Some tag that says "CI actually means something here" could be interesting 15:44:04 difficult to define though 15:44:11 and experiencing a lack of values is hard to give or recieve guidance 15:44:12 anteaya: well, maybe "powered by Openstack CI suite" could be for CIs using downstream-puppet when you have it done with proper self-diagnosis 15:44:19 anteaya: only throwing thoughts here... 15:44:28 wznoinsk: sure 15:44:33 brainstorming is good 15:44:51 I have nothing to offer, unfortunately, though I wish I did 15:45:00 but I definitely feel a lack of values 15:45:08 there used to be values 15:45:15 and I can't find them today 15:45:22 not sure what to do about that 15:45:28 ttx: it is difficult, once we agree on who values from CIs (and these are devs and components vendors imho only atm) we would make the certification/recognition right 15:46:03 * anteaya reiterates she has opinions on the use of the word certified 15:46:40 but identifying what we value 15:46:45 or what is valued 15:46:57 and recognizing when that value is respecting 15:47:01 I support that 15:47:07 as well as all those words 15:47:17 values, recogniztion and respect 15:47:53 on the other hand, if infra plans to extend their testing, why not to do it using community (3rd party ci)? 15:48:14 if infra plans to extend their testing 15:48:22 does infra plan to extend their testing? 15:48:27 if so this is news to me 15:48:43 what plans does infra have 15:48:51 and what tests are being extended 15:48:53 and how? 15:49:48 wznoinsk: what are you reading or referencing that leads you to these conclusions? 15:49:52 there were couple of talks on the summit about testing, some ppl wanted to have more testing, I don't know whether that's in projects plan (to extend by additional distro testing ie.) which would be eventually thrown at infra 15:50:10 do the summit sessions have names? 15:50:16 distro testing? 15:50:20 that is a new one for me 15:50:24 o/ 15:50:53 we are discussing packaging repos, that were hoped to be shared by different distros and are looking less likely now 15:50:57 hi asselin_ 15:51:13 we have talks every summit about testing 15:51:29 since we have a whole project dedicated to the topic, the qa project 15:51:52 I'm light on details on how this is affecting infra 15:52:13 I'm not saying its not, I'm saying I don't have the same perspective you have 15:52:24 and need some detail or references to understand 15:52:32 and right now I have none 15:52:34 anteaya: ok, my 'if infra' was 'in case infra' rather than 'because infra wants to increase testing' 15:52:54 well infra is consuming the common-ci solution 15:53:03 as fast as new modules are merged 15:53:16 so in terms of infra should use the common-ci solution 15:53:18 we are 15:53:27 yes! :) 15:53:32 as soon as there is anything to consume 15:53:41 asselin_: thanks for all your hard work! 15:54:10 so we seem to be in a close to wrap up place 15:54:21 I'll just remind folks that when discussing topics 15:54:40 it is really helpful to not assume anyone else knows the details of what you are talking about 15:54:48 so bringing links with you is really helpful 15:55:03 etherpads, mailing list threads, summit session topics, anything 15:55:27 please bring the link so that others, who may be interested in understanding what you are trying to say, can follow along 15:55:39 anything more for today before we wrap up? 15:56:18 re common-ci solution. I'll request zuul patches to merge today 15:56:25 asselin_: wonderful 15:56:38 so next, requesting reviews on the nodepool patches 15:56:41 have you links so taht those present can review quickly if they wish 15:57:37 looking for link now 15:58:00 thanks 15:58:12 #link https://review.openstack.org/#/c/188325/ 15:58:35 didn't find the others....but ping we later if you're interested.... 15:58:39 sure 15:58:42 thank you asselin_ 15:58:56 thanks all for your attendance and participation today 15:59:00 see you next week 15:59:04 #endmeeting