Tuesday, 2019-06-25

*** saneax has quit IRC00:07
*** mattw4 has quit IRC00:12
*** sgw has quit IRC00:13
*** igordc has quit IRC00:13
*** rfolco has joined #zuul00:19
*** wxy-xiyuan has joined #zuul01:08
*** rfolco has quit IRC01:33
*** bhavikdbavishi has joined #zuul01:47
*** bhavikdbavishi1 has joined #zuul01:50
*** bhavikdbavishi has quit IRC01:51
*** bhavikdbavishi1 is now known as bhavikdbavishi01:51
*** sshnaidm has quit IRC02:05
*** bhavikdbavishi has quit IRC02:08
*** threestrands has joined #zuul02:54
*** bhavikdbavishi has joined #zuul03:07
*** mnaser has quit IRC03:19
*** mnaser has joined #zuul03:20
*** saneax has joined #zuul04:07
*** saneax has quit IRC04:25
openstackgerritAndreas Jaeger proposed zuul/zuul-jobs master: Expand documentation of test-setup role  https://review.opendev.org/66724404:27
*** sgw has joined #zuul04:34
*** sgw has quit IRC04:41
*** swest has joined #zuul04:46
*** pcaruana has joined #zuul05:56
*** pcaruana has quit IRC05:57
*** pcaruana has joined #zuul05:57
openstackgerritMerged zuul/zuul-jobs master: Add install-devstack role  https://review.opendev.org/66715705:58
openstackgerritMerged zuul/zuul-jobs master: Expand documentation of test-setup role  https://review.opendev.org/66724405:58
*** saneax has joined #zuul06:17
*** gtema has joined #zuul06:30
*** altlogbot_0 has quit IRC06:46
*** altlogbot_1 has joined #zuul06:56
*** threestrands has quit IRC07:00
*** threestrands has joined #zuul07:00
*** themroc has joined #zuul07:14
*** saneax has quit IRC07:31
*** saneax has joined #zuul07:32
*** jangutter has joined #zuul07:41
*** jangutter has quit IRC07:42
*** jangutter_ has joined #zuul07:42
*** sshnaidm has joined #zuul07:42
*** jpena|off is now known as jpena07:48
*** jpena is now known as jpena|mtg07:48
*** threestrands has quit IRC07:57
*** hashar has joined #zuul08:00
*** themroc has quit IRC08:02
*** themroc has joined #zuul08:06
*** yolanda has joined #zuul09:07
zbr|ruckdoes anyone know if the zuul example is currently broken? I got into https://etherpad.openstack.org/p/zuul-standalone09:33
*** bhavikdbavishi has quit IRC09:47
*** panda has quit IRC09:55
*** panda has joined #zuul10:00
*** gtema_ has joined #zuul10:05
*** gtema has quit IRC10:05
zbr|ruckcan anyone give me some hints on how to create a dependency chain for zuul jobs? mainly I want to stack jobs into 3 classes or "waves" based on their resource costs. A) linters ... B) medium C) fat ones. Jobs in B would start only if all ones from A would pass.10:34
openstackgerritMark Meyer proposed zuul/zuul master: Extend event reporting  https://review.opendev.org/66213410:36
*** tobiash has joined #zuul11:25
badboyfungi: thank you!11:51
fungibadboy: did upgrading to a newer pyca/cryptography fix it?11:53
badboyfungi: pip3 install cryptography --upgrade11:54
fungii expect paramiko failed to increase the minimum version of it in their install_requires11:54
badboyfungi: I had cryptography-2.1.4 but the latest 2.7 works fine11:55
*** bhavikdbavishi has joined #zuul11:56
fungithe function it was looking for was introduced in 2.5 according to their changelog:11:56
fungi"Added :meth:`~cryptography.hazmat.primitives.asymmetric.ec.EllipticCurvePublicKey.from_encoded_point`, which immediately checks if the point is on the curve and supports compressed points. Deprecated the previous method :meth:`~cryptography.hazmat.primitives.asymmetric.ec.EllipticCurvePublicNumbers.from_encoded_point`."11:56
fungihttps://github.com/pyca/cryptography/blob/master/CHANGELOG.rst#25---2019-01-2211:56
badboyfungi: good catch, I'm not up to date with that11:57
badboyfungi: so downgrading paramiko worked as well11:57
fungihuh, seems they did update their install_requires in https://github.com/paramiko/paramiko/commit/36fbe57629cbbb7bf0f4a1e98c43352b82fe181d which was released as far back as paramiko 2.5.011:59
*** bhavikdbavishi1 has joined #zuul11:59
fungiso i have to wonder why that didn't upgrade cryptography11:59
badboyI guess I have to update cryptography on my templates to avoid that issue in the future12:00
*** bhavikdbavishi has quit IRC12:00
openstackgerritAndy Ladjadj proposed zuul/zuul master: [doc][monitoring] Fix the wait_time parent attribute  https://review.opendev.org/66734212:00
*** bhavikdbavishi1 is now known as bhavikdbavishi12:00
openstackgerritAndy Ladjadj proposed zuul/zuul master: [doc][monitoring] Fix the wait_time parent attribute  https://review.opendev.org/66734212:01
flaper87anyone that has windows workers? I'm setting up a couple of windows workers and I'm wondering how the login is done. Does zuul just use a certificate? I don't see in the docs how the password can be passed to nodepool12:02
* flaper87 is certainly missing something12:02
badboyflaper87: WinRM?12:02
* badboy AFK12:03
flaper87badboy: yeah, it's WinRM. I have the node ready, tested connection, ran some ansible playbooks against it and I'm now configuring nodepool12:03
flaper87nodepool allows me to set the username, connection type, connection port but I don't see how to pass the password/cert, etc12:04
openstackgerritAndy Ladjadj proposed zuul/zuul master: [doc][monitoring] Fix the wait_time parent attribute  https://review.opendev.org/66734212:04
flaper87unless it expects it to be just open12:04
*** rfolco has joined #zuul12:12
openstackgerritMark Meyer proposed zuul/zuul master: Extend event reporting  https://review.opendev.org/66213412:15
*** rlandy has joined #zuul12:29
openstackgerritFabien Boucher proposed zuul/zuul master: Remove non working tests/base.py ZuulTestCase.getPipeline method  https://review.opendev.org/66735112:40
flaper87oh, by reading zuul's code it looks like it uses keys12:44
zbr|ruckI added a feature request to allow use of tags on dependencies, some feedback would be appreciated. https://storyboard.openstack.org/#!/story/200595112:46
*** jangutter_ is now known as jangutter12:51
zbr|ruckhttps://storyboard.openstack.org/#!/story/2005952 -- about allowing regex on dependencies12:57
zbr|ruckfungi: do ^ make sense?12:58
fungithat's an interesting idea... i guess it's scoped to only the set of jobs which would have been triggered for a particular event?13:09
*** bhavikdbavishi has quit IRC13:39
tobiashcorvus: I think I found a problem with nodeless jobs when having all executors zoned. In this case there will be no executor that will accept that job. I'm not sure how we should handle that case. Should we pick a main zone in this case?13:47
*** openstackgerrit has quit IRC13:48
*** tosky has joined #zuul13:52
*** openstackgerrit has joined #zuul13:53
openstackgerritSimon Westphahl proposed zuul/nodepool master: wip: Allow proceeding with requests on quota exceeded  https://review.opendev.org/66737113:53
openstackgerritSimon Westphahl proposed zuul/nodepool master: wip: Allow proceeding with requests on quota exceeded  https://review.opendev.org/66737113:55
*** portdirect has joined #zuul13:57
*** saneax has quit IRC13:58
*** michael-beaver has joined #zuul14:10
corvustobiash: or run at least one unzoned executor?  or add an extra option to the executor to specify that it can also handle unzoned jobs?14:17
tobiashI think the last option would be great14:18
tobiashthat could make it possible to define one set of executors as fallback if the node has no zone14:18
*** sgw has joined #zuul14:25
*** hashar has quit IRC14:27
mnaserclarkb, pabelanger: yeah, it was a ceph issue at the time and we were retuning to fix it and improve that issue14:29
mnaserit shouldn't happen again.14:29
*** panda has quit IRC14:41
tobias-urdinjust upgraded zuul and nodepool to latest version in just a couple of minutes, release notes was on point, high five o/14:42
*** panda has joined #zuul14:43
*** igordc has joined #zuul14:49
corvustobias-urdin: \o/14:59
*** themroc has quit IRC15:02
*** jpena|mtg is now known as jpena|off15:11
*** themroc has joined #zuul15:12
*** flepied has quit IRC15:18
openstackgerritFabien Boucher proposed zuul/zuul master: URLTrigger driver time based  https://review.opendev.org/63556715:26
*** igordc has quit IRC15:32
*** mattw4 has joined #zuul15:52
*** themroc has quit IRC16:01
*** hashar has joined #zuul16:03
*** igordc has joined #zuul16:04
*** chandankumar is now known as raukadah16:13
*** hashar has quit IRC16:17
openstackgerritJames E. Blair proposed zuul/nodepool master: Switch functional testing to a devstack consumer job  https://review.opendev.org/66502316:35
openstackgerritJames E. Blair proposed zuul/nodepool master: Remove devstack plugin functional test jobs  https://review.opendev.org/66715616:35
openstackgerritJames E. Blair proposed zuul/nodepool master: Switch functional testing to a devstack consumer job  https://review.opendev.org/66502316:37
openstackgerritJames E. Blair proposed zuul/nodepool master: Remove devstack plugin functional test jobs  https://review.opendev.org/66715616:37
*** hashar has joined #zuul16:42
*** pwhalen has quit IRC16:42
*** pwhalen has joined #zuul16:45
*** panda has quit IRC16:46
*** panda has joined #zuul16:48
*** igordc has quit IRC16:56
*** igordc has joined #zuul16:59
*** hashar has quit IRC17:03
openstackgerritAlex Schultz proposed zuul/zuul master: Additional note about branches for implied-branches  https://review.opendev.org/66741517:07
openstackgerritMerged zuul/zuul master: Add command processor to zuul-web  https://review.opendev.org/66630717:09
openstackgerritMark Meyer proposed zuul/zuul master: Extend event reporting  https://review.opendev.org/66213417:10
*** raukadah is now known as chandankumar17:11
*** chandankumar is now known as raukadah17:13
*** gtema_ has quit IRC17:16
*** gtema_ has joined #zuul17:16
*** gtema_ has quit IRC17:20
*** jeliu_ has joined #zuul17:21
openstackgerritMerged zuul/zuul master: Add repl server for debug purposes  https://review.opendev.org/57996217:22
*** mattw4 has quit IRC17:38
*** mattw4 has joined #zuul17:45
*** sgw has left #zuul18:13
*** sgw has joined #zuul18:13
*** gtema has joined #zuul18:29
openstackgerritTobias Henkel proposed zuul/zuul master: Filter out unprotected branches from builds if excluded  https://review.opendev.org/66666418:37
openstackgerritTobias Henkel proposed zuul/zuul master: Filter out unprotected branches from builds if excluded  https://review.opendev.org/66666418:39
*** ianychoi_ has quit IRC18:49
openstackgerritTobias Henkel proposed zuul/zuul master: Filter out unprotected branches from builds if excluded  https://review.opendev.org/66666418:50
*** ianychoi_ has joined #zuul18:50
*** gtema has quit IRC19:11
*** hashar has joined #zuul19:13
*** gtema has joined #zuul19:13
*** mattw4 has quit IRC19:18
*** jeliu_ has quit IRC19:27
hwangboIs there a gerrit event I can specify to reject draft reviews from entering pipelines?19:31
*** pcaruana has quit IRC19:38
*** tosky has quit IRC19:40
corvushwangbo: you might be able to set a 'status' requirement for the change, but i don't know what that would be off the top of my head19:43
corvushwangbo: maybe something like "reject: status: draft"19:43
clarkbopendev's Gerrit avoids this by disabling pushes to the drafts magic ref in gerrit19:43
corvushwangbo: yeah, if you can avoid using draft status at all, i would recommend that19:44
corvushwangbo: but if you have to use it, look at https://zuul-ci.org/docs/zuul/admin/drivers/gerrit.html#requirements-configuration and see if that helps19:44
evgenylHi everyone, I'm trying to use standard zuul-jobs, and I have a failure for a log fetching job, so I was wondering if anybody experienced anything similar http://paste.openstack.org/raw/753396/ `rsync: chown "dst-path" failed: Invalid argument (22)` for the context, I run executor in a privileged container.19:46
hwangbocorvus: from the gerrit docs, I don't see a status for draft https://gerrit-review.googlesource.com/Documentation/user-search.html#status19:48
corvushwangbo: hrm, then i'm not sure...  if there's some other attribute for it, we can add it19:49
fungihwangbo: one of the reasons we disabled drafts in opendev's gerrit was that they would trigger jobs which zuul for refs zuul could not retrieve19:50
fungibut that was also a very, very long time ago19:50
corvusevgenyl: i'm not sure what would cause that, but you can run "zuul-executor keep" in your executor container and zuul will keep the build directory around after the job finishes, so you can cd into it and inspect it19:51
pabelangerevgenyl: make sure your executor has permissions to chown the files you are rsyncing. Possible one file is own by root, lets say, and executor doesn't have privileges to --chown that19:51
corvusevgenyl: (just run that before starting the job)19:51
hwangbofungi: Unfortunately, drafts are a pretty integral part of our existing CI workflow to avoid automatic testing19:51
hwangboI'll keep poking around the API, and test different things. Thanks for the advice!19:54
evgenylcorvus: `zuul-executor keep` - this is really helpful, thank you.19:54
evgenylpabelanger: Yeah, I will try to poke around with manual chowning, thanks!19:54
corvusevgenyl: 'nokeep' is the opposite to turn that off when you're done19:56
*** pwhalen has quit IRC20:04
*** mattw4 has joined #zuul20:14
openstackgerritJames E. Blair proposed zuul/nodepool master: Switch functional testing to a devstack consumer job  https://review.opendev.org/66502320:23
openstackgerritJames E. Blair proposed zuul/nodepool master: Remove devstack plugin functional test jobs  https://review.opendev.org/66715620:23
*** ianychoi_ has quit IRC20:59
*** ianychoi_ has joined #zuul21:00
hwangboIt looks like you can use 'status: draft' as a require condition but not a reject condition21:05
*** ianychoi_ has quit IRC21:05
*** ianychoi_ has joined #zuul21:09
openstackgerritJames E. Blair proposed zuul/nodepool master: Remove devstack plugin functional test jobs  https://review.opendev.org/66715621:10
openstackgerritJames E. Blair proposed zuul/nodepool master: Add Zypper to openstack func job  https://review.opendev.org/66746621:10
openstackgerritJames E. Blair proposed zuul/nodepool master: Switch functional testing to a devstack consumer job  https://review.opendev.org/66502321:12
openstackgerritJames E. Blair proposed zuul/nodepool master: Remove devstack plugin functional test jobs  https://review.opendev.org/66715621:12
fungihwangbo: that seems like it could be a bug if we can require conditions we can't reject21:15
hwangbofungi: from the documentation, it seems like we can only reject "approval" conditions, but not any of the others (open, current-patchset, status)21:16
hwangbohttps://zuul-ci.org/docs/zuul/admin/drivers/gerrit.html#attr-pipeline.reject.%3Cgerrit%20source%3E21:16
*** openstackgerrit has quit IRC21:18
*** ianychoi_ is now known as ianychoi21:18
fungihwangbo: in that case, it seems like it may be a well-documented bug ;)21:20
fungithe documentation calls reject a "mirror" of require, so that tells me that anything which require supports is at least fair game to add support for in reject21:22
fungieven if nobody's wanted it enough to spend time implementing that yet21:22
*** gtema has quit IRC21:27
*** jeliu_ has joined #zuul21:30
*** hashar has quit IRC21:41
*** tobberydberg has quit IRC21:49
*** fdegir has quit IRC21:50
*** tobberydberg has joined #zuul21:51
*** fdegir has joined #zuul21:51
*** openstackgerrit has joined #zuul21:54
openstackgerritJames E. Blair proposed zuul/nodepool master: Switch functional testing to a devstack consumer job  https://review.opendev.org/66502321:54
openstackgerritJames E. Blair proposed zuul/nodepool master: Remove devstack plugin functional test jobs  https://review.opendev.org/66715621:54
fungipaladox mentioned this to me earlier... https://lists.wikimedia.org/pipermail/wikitech-l/2019-June/092227.html22:12
fungizuul v3 in the running for new wikimedia ci system (along with gitlab ci and argo)22:12
* paladox has a change that imports zuul v3 into our zuul repo.22:13
paladoxthough that change won't be merged, as it was more of an experiment for me :) (testing a migration to scap deployments)22:14
fungipaladox: if it helps the opendev crowd, as well as at least a few other folks in here, have extensive experience porting zuul v2 jobs to v3 and are usually happy to provide guidance and recommendations22:14
paladoxfungi oh, i'll pass that onto hashar.22:15
fungiyeah, i would have highlighted him too but he's not in channel at the moment22:15
paladoxhe tryed to migrate existing jobs (https://gerrit.wikimedia.org/r/#/c/integration/config/+/517545/, https://gerrit.wikimedia.org/r/#/c/integration/config/+/517546/ and https://gerrit.wikimedia.org/r/#/c/integration/config/+/517547/)22:16
fungiahh, yeah, that's the script we originally used, though we had the luxury of not relying on many jenkins plugins and eventually (with zuul 2.5's experimental ansible launcher) using no jenkins plugins for a while before zuul v3 existed22:18
paladoxah22:19
fungiobviously the more your jobs rely on shell script literals or external executables, the easier they are to migrate22:19
paladoxfungi also hashar left for the evening (he was on only ~30 mins ago - is on UTC +2)22:21
fungithe other worry i'd have now is that the ansible that generated was contemporary with the ansible versions available at the time, and ansible syntax has evolved in the couple intervening years, so some adjustments may need to be made to create valid modern ansible (though maybe not, it's fairly simple stuff)22:21
paladoxyeh22:22
fungifigured. it's well late in his part of the globe22:22
fungii'm only just coming up for air unfortunately22:22
paladoxyup, he's only an hour ahead of me.22:22
paladoxalso i think some of the releng department experimented with different CI tools22:22
paladoxhence why zuul v3 is in the running :)22:22
funginice!22:23
paladoxfungi https://phabricator.wikimedia.org/T21813822:24
pabelangerhttps://phabricator.wikimedia.org/T218138#5039263 is interesting. For the most part I would generally agree, but since the ansible 2.4 release, I've personally had minimal issues upgrading playbooks / roles used to deploy zuul / nodepool. In fact, zuul.ansible.com zuul jobs were just upgraded from ansible 2.7 to 2.8 without any changes required.22:27
pabelangerTesting in ansible/ansible has come a long way in last 2 years22:27
fungipabelanger: thanks! that's got some great feedback in it22:28
fungier, paladox i mean22:28
paladoxyour welcome :)22:28
pabelangerYah, looks well done22:29
fungiand yeah, historical impressions of software having gaps or lack of stability can sometimes just be an indication that the individual last used it while it was still somewhat immature and evolving rapidly22:29
clarkbpabelanger: we've had to make changes to get 2.8 to work iirc22:30
fungisimilarly, the impression of the webui for zuul being read-only is accurate, but likely to change *very* soon ;)22:31
clarkbianw fixed them and we could test it all with zuul, but still not seamless22:31
clarkbthings around handlers22:31
clarkband include tasks22:31
fungizuul giving you the option of trying different ansible versions concurrently also helps ease the ansible upgrade pain, even if there is still somewhat of a treadmill22:31
pabelangerclarkb: yah, I should have used a (*) there, our jobs are pretty minimal. No handlers, mostly shell / tox based jobs22:32
pabelangerclarkb: was the issue in zuul-jobs or some other place?22:33
* paladox was the one that filed the task to upgrade to v3 https://phabricator.wikimedia.org/T18642622:33
clarkbpabelanger: it was in a role somewhere22:34
clarkbpabelanger: the issue was with handlers including tasks and that has to be done in some very specific way now22:35
paladoxfungi oh yes, now i remember why i experimented with zuul v3, i did it to see if jenkins still worked with zuul v3.22:36
pabelangerclarkb: yah, I tend to avoid handlers as much as possible22:37
fungieven with ansible's warts, i'm still glad that zuul v3 went the way of not creating its own domain-specific language for remote execution, since there are plenty of projects out there already who specialize in doing that and we get network effects by siding with one rather than competing with all22:38
pabelangerI did notice the following when upgrading to 3.9.0: https://review.opendev.org/666972/22:39
pabelangerseems to be something we missed when we merged multi-ansible bits22:39
fungiand we did pick one which is written in python and uses yaml for its data, so was not too dissimilar with what we would have ended up implementing independently22:39
clarkbthat does have me thinking a bit about what sorts of config might be removable if we shipped with sane defaults (that could be overridden)22:50
clarkbIn the gitlab example it was silly simple because it wasn't talking to gerrit (yet) and just runs single node jobs?22:51
clarkbmakes me wonder if we could have a default zuul config that given a connection parameter did a sanish check style green red reporting and you'd only need in repo .zuul.yaml22:52
clarkb(I think the nodepool config becomes the complicated bit there)22:52
clarkband maybe for nodepool using nodepool localhost as a static node resource would work? (I'm just throwing ideas out there thinking about what simplifying setup might look like)22:54
pabelangerwhat was the gitlab example?22:55
clarkbpabelanger: basically stick a repo in gitlab.com and go https://phabricator.wikimedia.org/T21759422:55
clarkbso some of the simplicity there is that its a hosted service too. I'm sure that as soon as you  run your own gitlab you've got to tell ti a lot more about where jobs can run and how many jobs can run and so on22:56
pabelangeryah22:57
clarkbhttps://phabricator.wikimedia.org/T217325 is the top level issue and has links and stuff22:57
clarkbya you have to setup https://docs.gitlab.com/runner/configuration/advanced-configuration.html23:00
clarkb(and k8s and prometheus for additional features)23:00
paladoxhttps://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/CI_Futures_WG/Report#Zuul23:02
openstackgerritJames E. Blair proposed zuul/nodepool master: Switch functional testing to a devstack consumer job  https://review.opendev.org/66502323:03
openstackgerritJames E. Blair proposed zuul/nodepool master: Remove devstack plugin functional test jobs  https://review.opendev.org/66715623:03
pabelangerthere seems to be some discrepency about in-tree configuration, but that aside, with zuul that could be done in a single if wanted23:07
pabelangerdiscrepancy*23:07
*** jeliu_ has quit IRC23:08
clarkbpabelanger: I think the criticism there is fair. Basically you have to configure what resources are available to tests via a separate nodepool config (and service) which you don't have to do if you put something on gitlab.com23:08
clarkbyou do have to do similar when you setup up a gitlab runnre though23:09
pabelangerAgree, the report is well done. It is easier to get your own CI image in some cases with others23:10
clarkband then there is the base job setup that is centrally managed. Also seems that one of the wants is to have project auto enroll with the ci system23:11
clarkbzuul doesn't directly support auto enroll but it owuldn't be too hard to put something between gerrit and zuul to do that (or possibly even add that as an option to the gerrit driver?)23:11
SpamapSpaladox: Nodepool also supports OpenShift and AWS for nodes.23:12
clarkbbasically process all gerrit events regardless of whether or not the project is in the project list23:12
pabelangeryah, auto-enroll is something I've seen asked for a few times for zuul.a.c.  eg: click this button on github and poof, done23:12
SpamapS(the report only mentions OpenStack and Kubernetes)23:12
clarkbpabelanger: its harder with public github because you'd need a filter of somesort23:12
clarkbpabelanger: though maybe that is an acl on the app you install in github?23:13
paladoxSpamapS i think we have our own nodes (wikimedia cloud) :)23:13
clarkb"these groups can use the app" then zuul processes all events it gets?23:13
SpamapSpaladox:oh cool!23:13
paladoxwhich runs openstack23:13
SpamapSI wasn't sure if that was still a thing. Good.23:13
clarkbpaladox: fwiw the report notes that nodepool+ openstack would be an issue23:13
pabelangerclarkb: yah, not sure. I haven't looked to hard at it.23:13
paladoxYeh we had issues with nodepool.23:13
paladoxie was very slow for us23:13
paladoxwe only within the last year got rid of nodepool and replaced it with docker. But looks like we may be going back to nodepool :)23:14
* SpamapS wonders if paladox is aware of just how big the "it's slow" iceberg is...23:14
clarkbSpamapS: well that and I think they were running 4 year old nodepool23:14
paladoxheh23:14
clarkbthe software has gotten better over time :) hopefully the update paladox is pushing improves perceptions23:14
SpamapSI mean.. if you tell an engineer something's slow.. they're going to prove you wrong in 0.48s23:14
paladoxyeh, was a pretty old version.23:15
paladoxIt was slow, but im not sure if that was the decision behind going to docker though.23:15
SpamapSdocker.. like.. docker swarm?23:15
SpamapSor like, static nodes with docker to run concurrent isolated things on them?23:16
* SpamapS is just curious. :)23:16
clarkbthinking about the auto enrollment a bit more it probably does make sense to be able to have just trusted projects listed in the main config then any other project it sees events for get processed as untrusted projects23:17
paladoxthere static as far as i know.23:17
SpamapSclarkb:yes!23:17
clarkbthat would greatly simplify configuration churn, I'll have to think about why that may be problematic more23:17
paladoxhttps://integration.wikimedia.org/ci/ (integration-slave-docker-*)23:17
clarkbone potential problem with that is the initial config load, zuul does preload all configs for things it knows about23:19
clarkbbut maybe it can ask gerrit for that list (or github)23:19
clarkbthat is probably the biggest hurdle to get over to make that possible23:20
clarkbbuilding the initial global config sanely with minimal info23:20
paladoxi do quite like the idea of a .zuul* file (we have a task somewhere to create something similar)23:20
SpamapSclarkb: back in the Bonny days jamie lennox built a little python app that would generate the tenant.yaml for anybody that installed the BonnyCI GitHub app automatically.23:22
SpamapSIIRC it would add a whole new tenant for the org.23:22
SpamapS(or user)23:22
clarkbSpamapS: I think the concern from wmf is that when a new repo is created you hvae to create a new entry in the tenant config23:23
clarkbwhat is automateable for sure23:23
clarkbjust wondering if zuul could do the right thing sanely without explicit listing in its config23:23
SpamapSGitHub apps can definitely query the API for installed orgs/repos.23:23
SpamapSGerrit could probably just scan the list for config.23:24
SpamapSOr keep a cache.23:24
clarkbpabelanger: that bind mount chnage has me wondering where the venv install gets mounted in23:25
clarkbpabelanger: once I sort that out I'll leave a vote23:25
pabelangermy idea, much like SpamapS said, some script that will fire when github app installs, generate tenant configs, have human merge, then post jobs to open new PR on new repo to confirm a noop job ran, and point to some docs23:25
paladoxOr you could create a new gerrit plugin that zuul listens on so that project owners can add there project to zuul using a rest api (created by the plugin)23:25
clarkbpaladox: for us (opendev) that doesn't really chnage the amount of management work (project owners == people approving changes to zuul main config)23:29
pabelangerclarkb: yah, took me a bit to figure it out too: https://opendev.org/zuul/zuul/src/branch/master/zuul/executor/server.py#L191023:29
paladoxoh23:29
clarkbpabelanger: thanks23:29
clarkbpaladox: we don't give out project owner in gerrit because it allows a bit too much control :/23:30
paladoxah yeh, as we recently found it also exposes something else :(23:31
paladoxhttps://phabricator.wikimedia.org/T222653 (hidden)23:31
clarkbya it implies a lot of permissions23:31
paladoxThough im a gerrit manager for the wmf (in the group "Gerrit Manager" which grants me rights to create projects/groups). I also have +2 in refs/meta/* for All-Projects (but carn't merge as im not an admin)23:33
*** mattw4 has quit IRC23:37
pabelangeryah, that is a hard one for github right now. People want to tryout zuul, but not give admin access to their own repo. So, there still ways humans can force merge behind zuul and break things23:39
fungithis was an easier sell for openstack since we'd well before taken away anyone's ability to directly merge changes and already placed that under automated process23:41
fungipossibly the biggest hurdle for many organizations to jump23:41
pabelangeryah23:44
pabelangerthere are also thing that github makes hard too, like doing git tags, you need push for that23:45
pabelangerand no ACL to just allow tag23:45
pabelangerall or nothing23:45
fungii do really appreciate the granularity gerrit's acls offer23:46
fungilike, looking forward to being able to set acls explicitly allowing branch deletion in newer gerrit23:47
pabelangerI do think there is good use case to make some of the openstack/releases code more generic to use that workflow with a zuul-job. I looked at it briefly a few months ago, but just haven't found the time23:50
pabelangergitops releases23:50
fungipush tag, enjoy release23:51
pabelangerI was more thinking, commit sha1 into yaml, then zuul does the tagging, etc23:54
fungioh, you mean the release request reviewing and tag generation stuff23:54
fungiyeah23:54
pabelangeryah23:54
fungia lot of that is simply working around one of the glaring gerrit feature omissions going on many years now: reviewing git tags23:54
paladoxThe ui for tags is nice :)23:57
*** rlandy has quit IRC23:59

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!