15:00:29 <mmedvede> #startmeeting third-party
15:00:30 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:34 <openstack> The meeting name has been set to 'third_party'
15:01:07 <mmedvede> hey third-party CI folks, anyone around for the meeting?
15:01:13 <ajafo> hi
15:01:24 <asselin> i'm here and in another meeting
15:01:45 <mmedvede> hi ajafo, asselin
15:02:30 <mmedvede> anyone has anything to discuss?
15:02:53 <ajafo> I've only short two questions
15:03:03 <mmedvede> go ahead ajafo
15:03:15 <lennyb> i am here for about 20mins
15:03:20 <ajafo> 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 <lennyb> ajafo: can you send a link to the ci-sandbox with your commits
15:04:56 <ajafo> lennyb: https://review.openstack.org/#/c/340280/  https://review.openstack.org/#/c/340285/
15:05:43 <mmedvede> ajafo: you should probably ask the project before you start commenting on their repos
15:06:12 <mmedvede> ajafo: and initially you might want to set your CI to non-voting
15:06:40 <ajafo> mmedvede: I moved this projects to upstream in last week so I'm in contact with everyone
15:07:03 <ajafo> so additionally I added it as non-voting jobs to fuel-ccp*
15:07:15 <lennyb> ajafo: what is your CI?
15:07:32 <ajafo> lennyb: Mirantis CCP CI
15:07:35 <lennyb> ajafo: http://docs.openstack.org/infra/system-config/third_party.html#permissions-on-your-third-party-system
15:07:44 <asselin> 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 <ajafo> ok, so I need to send e-mail, and after it should we add in acl's permissions for CI user?
15:09:01 <lennyb> ajafo: first you should ask for permission to comment as non-voting CI ( If I am not mistaken )
15:09:14 <asselin> lennyb, ++
15:09:29 <mmedvede> this
15:09:34 <wznoinsk> hi all
15:09:52 <ajafo> lennyb: but you mean asking project not openstack-infra group?
15:09:56 <mmedvede> ajafo: so if they said it is ok for your CI to comment, you can start commenting
15:09:58 <wznoinsk> lennyb, I think Nova will be the restrictive to ask before commenting out
15:11:24 <wznoinsk> 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 <lennyb> 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 <wznoinsk> 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 <lennyb> wznoinsk: +1
15:12:29 <ajafo> ok thanks,"(given by project's core team)" - it was the part I wasn't sure
15:12:34 <asselin> #link ci permission documented here: http://docs.openstack.org/infra/system-config/third_party.html#posting-result-to-gerrit
15:13:11 <wznoinsk> (forgive syntax errors) :-)
15:14:20 <mmedvede> ajafo: you mentioned having two questions, what is the second one?
15:14:30 <ajafo> 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 <wznoinsk> 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 <mmedvede> ajafo: yes, no permission from infra team is needed. But infra team can disable your account if your CI misbehaves
15:15:39 <wznoinsk> 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 <ajafo> 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 <lennyb> ajafo: trust me, getting your CI being disabled and being shouted on by anteaya is not a pretty thing :)
15:17:24 <mmedvede> +1
15:17:25 <ajafo> lennyb: it's ther reason why I'm trying to make sure twice before do something :)
15:17:41 <wznoinsk> 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 <wznoinsk> 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 <lennyb> ajafo: dont forget that CI default is 'voting' :)
15:19:02 <mmedvede> wznoinsk: ci-watch.tintri only includes a few repos
15:19:33 <ajafo> wznoinsk: oh so it's interesting I thought it can be changed
15:20:07 <wznoinsk> mmedvede, right, doesn't cover fuel-*
15:20:20 <asselin> default is 'commenting'...not 'voting'
15:20:25 <wznoinsk> ajafo, been there, done that, hence clearing that out for you str8 away
15:20:32 <wznoinsk> asselin, +1
15:21:52 <wznoinsk> ajafo, are you using openstackci from os infra out of curiosity?
15:22:50 <ajafo> wznoinsk: we've own packages
15:24:17 <ajafo> thanks guys for all help and clarify everything
15:24:46 <lennyb> 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 <lennyb> wznoinsk: it's affects port direct
15:25:34 <mmedvede> ajafo: if you have more questions, find any of us on irc outside the meeting. I would be happy to help
15:26:05 <cbader> 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 <ajafo> mmedvede: thanks
15:26:34 <lennyb> cbader: yes, if you have errors in layout.yaml
15:26:40 <wznoinsk> ajafo, glad we could help
15:26:48 <cbader> ok thanks will look there.
15:27:08 <lennyb> cbader: try to validate yaml and run zuul manually to see errors
15:27:14 <mmedvede> 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 <cbader> I don't see any error in debug.log
15:28:06 <wznoinsk> 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 <lennyb> mmedvede: not always, i had bad yaml and zuul-servers was running, but not submitting jobs, nor pid file.
15:28:27 <cbader> ok thanks I will look.
15:28:43 <mmedvede> lennyb: interesting. This is a good thing to keep in mind then
15:28:54 <lennyb> i had to run it manually and only than I saw error during parsing or even missing python modules
15:29:39 <mmedvede> 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 <lennyb> mmedvede: ... and we though that this meeting will not take place  today :)
15:30:40 <mmedvede> lennyb: yes, good discussion today :)
15:32:12 <wznoinsk> cbader, I run tox -e zuul before restarting zuul to make sure issues  like yours doesn't happen
15:32:37 <cbader> I will check tha
15:33:41 <ajafo> 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 <mmedvede> 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 <lennyb> Sorry, I need to go. See you next time...
15:35:59 <mmedvede> lennyb: thanks for attending
15:36:03 <mmedvede> and for the help
15:37:08 <mmedvede> ajafo: so it is up to cores to pay attention to third-party CI results
15:37:41 <ajafo> mmedvede: so all 3rd party CI works only in check phase? not in gate?
15:37:53 <ajafo> mmedvede: I'm asking because I want to understand
15:37:53 <asselin> ajafo, correct
15:38:07 <ajafo> ok so it's clear now
15:39:35 <ajafo> thanks again :)
15:40:00 <mmedvede> woo, meeting serves its purpose :)
15:40:50 <mmedvede> more to discuss today?
15:40:50 <mmedvede> if not, I propose to end meeting
15:41:40 <wznoinsk> mmedvede one thing from me
15:42:49 <mmedvede> wznoinsk: go ahead
15:43:42 <wznoinsk> 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 <mmedvede> wznoinsk: I guess you are referring to some way of measuring how stable a CI is?
15:44:46 <wznoinsk> 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 <wznoinsk> mmedvede, yes, from infra point of view
15:46:51 <mmedvede> 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 <wznoinsk> 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 <mmedvede> wznoinsk: there was also a ci-status tools added to third-party-ci-tool repo to pull down CI stats
15:47:22 <mmedvede> #link https://review.openstack.org/#/c/339194/
15:48:34 <wznoinsk> mmedvede, wasn't aware of that one, will give it a go
15:50:00 <wznoinsk> 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 <mmedvede> wznoinsk: definitely
15:51:41 <ajafo> 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 <asselin> ajafo, infra doesn't allow it b/c of possible stability issue causing the entire gate to break.
15:53:34 <asselin> ajafo, so the most you can do is vote in check, which is quite close to gate, but not exactly.
15:53:52 <wznoinsk> 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 <ajafo> ok, so it's more rules based reason
15:54:49 <wznoinsk> 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 <ajafo> asselin, wznoinsk thanks again for calrify
15:55:42 <asselin> ajafo, wznoinsk afaik a voting 3rd party ci can prevent a change from merging
15:55:54 <wznoinsk> 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 <asselin> by blocking it's access to the gate pipeline.
15:56:18 <asselin> 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 <mmedvede> 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 <mmedvede> so technically possible to prevent gate on -1 from third-party CI automatically, but would not happen for reasons mentioned above
15:59:31 <mmedvede> ok, we are at a time
15:59:34 <asselin> ok, in that case, my statement is not correct ^^. voting 3rd party ci can still enter gate even with -1
16:00:00 <mmedvede> thanks everyone for attending
16:00:03 <mmedvede> #endmeeting