15:00:29 #startmeeting third-party 15:00:30 Meeting started Mon Jul 18 15:00:29 2016 UTC and is due to finish in 60 minutes. The chair is mmedvede. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:31 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:34 The meeting name has been set to 'third_party' 15:01:07 hey third-party CI folks, anyone around for the meeting? 15:01:13 hi 15:01:24 i'm here and in another meeting 15:01:45 hi ajafo, asselin 15:02:30 anyone has anything to discuss? 15:02:53 I've only short two questions 15:03:03 go ahead ajafo 15:03:15 i am here for about 20mins 15:03:20 I want to add 3rd party CI to fuel-ccp* repos, I prepared some cases in ci-sandbox, to show it works, and I wan't to connect it to repos with voting permissions but I'm not sure how to do this, because there is information in docs about to send information to openstack-dev mailing list, from another side I found that there is third-party-anounce mailing list (I see there some informations about disabling 3rd party CI's), also I found this post http://list 15:04:07 ajafo: can you send a link to the ci-sandbox with your commits 15:04:56 lennyb: https://review.openstack.org/#/c/340280/ https://review.openstack.org/#/c/340285/ 15:05:43 ajafo: you should probably ask the project before you start commenting on their repos 15:06:12 ajafo: and initially you might want to set your CI to non-voting 15:06:40 mmedvede: I moved this projects to upstream in last week so I'm in contact with everyone 15:07:03 so additionally I added it as non-voting jobs to fuel-ccp* 15:07:15 ajafo: what is your CI? 15:07:32 lennyb: Mirantis CCP CI 15:07:35 ajafo: http://docs.openstack.org/infra/system-config/third_party.html#permissions-on-your-third-party-system 15:07:44 each project has their voting permissions, so you can't actually vote even if you tried until the acls are set to allow you to do so 15:08:25 ok, so I need to send e-mail, and after it should we add in acl's permissions for CI user? 15:09:01 ajafo: first you should ask for permission to comment as non-voting CI ( If I am not mistaken ) 15:09:14 lennyb, ++ 15:09:29 this 15:09:34 hi all 15:09:52 lennyb: but you mean asking project not openstack-infra group? 15:09:56 ajafo: so if they said it is ok for your CI to comment, you can start commenting 15:09:58 lennyb, I think Nova will be the restrictive to ask before commenting out 15:11:24 ajafo, in short... there's a few levels of what a CI may be doing: 1. running builds (without commenting back to review.o.o), 2. doing as above with commenting back the results, 3. voting = doing as above but also having the permission (given by project's core team) to see it's +/- 1 Verified 15:11:41 ajafo: yes, ak project folks, not infra. you need to ask permissions for commenting as non-voting first, and after a while with a valid history you may ask for voting commenting. 15:12:23 ajafo, as lennyb says, it's upto the project's (nova, neutron etc. team to speak about commenting to this particular project), not the infra team 15:12:26 wznoinsk: +1 15:12:29 ok thanks,"(given by project's core team)" - it was the part I wasn't sure 15:12:34 #link ci permission documented here: http://docs.openstack.org/infra/system-config/third_party.html#posting-result-to-gerrit 15:13:11 (forgive syntax errors) :-) 15:14:20 ajafo: you mentioned having two questions, what is the second one? 15:14:30 thanks guys for help, I asked project core teams(now got CI in non-voting + comments mode), but just wasn't sure do I need another permissions from openstack infra to vote, but now I know that core team can do this 15:15:00 regarding what mmedvede said, it's a good practice to ask the project's core team are they ok a new to CI to start commenting back to review.o.o on their project, especially Nova... on other project it may be accepted as long as the comments/results your CI doesn't look like 'still sandboxing and testing' 15:15:22 ajafo: yes, no permission from infra team is needed. But infra team can disable your account if your CI misbehaves 15:15:39 ajafo, technically it's an infra team that merges your CI's permission, but politically that's the project's core team that approves it 15:15:47 mmedvede: second one probably was answered with first one, I just wanted to make sure - if I want to have merge permissions for CI (to set it main gate) do I need some special permissions from infra team, but as I understand here permissions from core teams are enough too 15:16:46 ajafo: trust me, getting your CI being disabled and being shouted on by anteaya is not a pretty thing :) 15:17:24 +1 15:17:25 lennyb: it's ther reason why I'm trying to make sure twice before do something :) 15:17:41 ajafo, just to be clear here, as the 4th point on my previous 3 would be 4. gating rights = +/- 1 Verified from a CI decides whether to merge a change or not - only upstream Jenkins has it (meaning: non of the 3rdparty CI have it = non of them can stop a change from mergin) 15:18:23 ajafo, this may be of help to sanity checks your CIs builds against others: http://ci-watch.tintri.com/project?project=nova 15:18:42 ajafo: dont forget that CI default is 'voting' :) 15:19:02 wznoinsk: ci-watch.tintri only includes a few repos 15:19:33 wznoinsk: oh so it's interesting I thought it can be changed 15:20:07 mmedvede, right, doesn't cover fuel-* 15:20:20 default is 'commenting'...not 'voting' 15:20:25 ajafo, been there, done that, hence clearing that out for you str8 away 15:20:32 asselin, +1 15:21:52 ajafo, are you using openstackci from os infra out of curiosity? 15:22:50 wznoinsk: we've own packages 15:24:17 thanks guys for all help and clarify everything 15:24:46 wznoinsk: btw, we've found some bugs in tempest #link https://review.openstack.org/#/c/343294/ and #link https://review.openstack.org/#/c/335447/ 15:25:31 wznoinsk: it's affects port direct 15:25:34 ajafo: if you have more questions, find any of us on irc outside the meeting. I would be happy to help 15:26:05 I have a question has anyone had an issue with one of the zuul servers not creating a pid file? the issues I am seeing is the zuul url says json:error 15:26:32 mmedvede: thanks 15:26:34 cbader: yes, if you have errors in layout.yaml 15:26:40 ajafo, glad we could help 15:26:48 ok thanks will look there. 15:27:08 cbader: try to validate yaml and run zuul manually to see errors 15:27:14 cbader: but if you have errors in layout, your /var/log/zuul/debug.log should show errors when you try starting up zuul server 15:27:40 I don't see any error in debug.log 15:28:06 cbader, as lennyb says - it may be the reason, it's good to run tox -e zuul from 'project-config' repo to check your layout.yaml against jbb 15:28:11 mmedvede: not always, i had bad yaml and zuul-servers was running, but not submitting jobs, nor pid file. 15:28:27 ok thanks I will look. 15:28:43 lennyb: interesting. This is a good thing to keep in mind then 15:28:54 i had to run it manually and only than I saw error during parsing or even missing python modules 15:29:39 I have internal CI that runs tox -ezuul on each project-config change, so this is probably why I never have seen the pid file missing problem 15:29:50 mmedvede: ... and we though that this meeting will not take place today :) 15:30:40 lennyb: yes, good discussion today :) 15:32:12 cbader, I run tox -e zuul before restarting zuul to make sure issues like yours doesn't happen 15:32:37 I will check tha 15:33:41 hmm I've another question, if there is no possibility to get 3rd party as gate, is it possible to have configuration that we want to have merged code by CI but after 3rd party CI will be successful? 15:35:38 ajafo: technically, maybe. But I do not think infra would want that. In the end, it is up to humans to decide if -1 given by third-party CI should prevent thing from merging 15:35:48 Sorry, I need to go. See you next time... 15:35:59 lennyb: thanks for attending 15:36:03 and for the help 15:37:08 ajafo: so it is up to cores to pay attention to third-party CI results 15:37:41 mmedvede: so all 3rd party CI works only in check phase? not in gate? 15:37:53 mmedvede: I'm asking because I want to understand 15:37:53 ajafo, correct 15:38:07 ok so it's clear now 15:39:35 thanks again :) 15:40:00 woo, meeting serves its purpose :) 15:40:50 more to discuss today? 15:40:50 if not, I propose to end meeting 15:41:40 mmedvede one thing from me 15:42:49 wznoinsk: go ahead 15:43:42 mmedvede, is there any 3rdparty CI maturity kind of measure? I keep bogging anteaya about these topics constantly just to be on the right track 15:44:38 wznoinsk: I guess you are referring to some way of measuring how stable a CI is? 15:44:46 I'm about to ask for voting rights in nova and neutron soon and want to satisfty both project and infra team req 15:44:59 mmedvede, yes, from infra point of view 15:46:51 wznoinsk: I think it mostly is voting history. There is no official tool yet. ci-watch.tintri can be used for that if your CI is tracked 15:47:13 mmedvede, I don't want to sound as trying to stress some answer from yourself here, I kind of know there's no strict measures in place - was wondering about what to do best 15:47:18 wznoinsk: there was also a ci-status tools added to third-party-ci-tool repo to pull down CI stats 15:47:22 #link https://review.openstack.org/#/c/339194/ 15:48:34 mmedvede, wasn't aware of that one, will give it a go 15:50:00 mmedvede, I wrote something kind of similar some time ago to alert if our CIs result is Failure where upstream Jenkins is SUCCESS to highlight possible CI/feature issues - I'll have a look whether that's something that could land in third-party-tools maybe 15:51:15 wznoinsk: definitely 15:51:41 guys, last one question what is the reason to not have gate from 3rd party CI? I'm asking because if e.g we'll agree to remove from openstack-infra layout.yaml gate tests at our repos then it could be merged only with external 3rd party CI so technically it's not problem? 15:52:20 ajafo, infra doesn't allow it b/c of possible stability issue causing the entire gate to break. 15:53:34 ajafo, so the most you can do is vote in check, which is quite close to gate, but not exactly. 15:53:52 ajafo, as asselin says... you don't want gating to rely on 3rd party CI, there are some good and some bad ones... also... upstream jenkins have some basic tests done always (i.e.: unit/functional tests)... you don't want to get the code merged if these fail ... code reviewers take into accout 3rd party ci results 15:54:31 ok, so it's more rules based reason 15:54:49 asselin, isn't 3rdparty ci voting (or commenting) in check also not important when it comes whether the changes lands in gate pipeline or not? 15:54:53 asselin, wznoinsk thanks again for calrify 15:55:42 ajafo, wznoinsk afaik a voting 3rd party ci can prevent a change from merging 15:55:54 ajafo, technically it is possibly to give any 3rdparty CI gating rights... by rules as you said, it's not enabled because of different reason 15:56:01 by blocking it's access to the gate pipeline. 15:56:18 once it's in the gate pipeline, then only infra jobs run and determine if the patch merges or not 15:56:22 * wznoinsk didn't know that, needs more testing 15:58:24 the requirement for gate job to start is here https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L41-L47 15:59:04 so technically possible to prevent gate on -1 from third-party CI automatically, but would not happen for reasons mentioned above 15:59:31 ok, we are at a time 15:59:34 ok, in that case, my statement is not correct ^^. voting 3rd party ci can still enter gate even with -1 16:00:00 thanks everyone for attending 16:00:03 #endmeeting