Thursday, 2020-02-20

*** Defolos has quit IRC00:07
*** mattw4 has quit IRC00:33
*** shanemcd has quit IRC00:55
*** shanemcd has joined #zuul00:55
*** rfolco has quit IRC01:44
*** Goneri has quit IRC02:34
*** swest has quit IRC02:36
*** igordc has quit IRC02:45
*** openstackstatus has joined #zuul02:56
*** ChanServ sets mode: +v openstackstatus02:56
*** rlandy|bbl is now known as rlandy03:03
*** bhavikdbavishi has joined #zuul03:14
*** jamesmcarthur has joined #zuul03:14
*** bhavikdbavishi1 has joined #zuul03:17
*** bhavikdbavishi has quit IRC03:18
*** bhavikdbavishi1 is now known as bhavikdbavishi03:18
*** sgw has quit IRC03:25
*** evrardjp has quit IRC03:42
*** evrardjp has joined #zuul03:45
*** sgw has joined #zuul03:45
*** jamesmcarthur has quit IRC03:48
*** jamesmcarthur has joined #zuul03:49
*** jamesmcarthur has quit IRC03:54
*** jamesmcarthur has joined #zuul04:13
*** jamesmcarthur has quit IRC04:25
*** rlandy has quit IRC04:41
*** bhavikdbavishi has quit IRC04:58
*** bhavikdbavishi has joined #zuul04:58
*** saneax has joined #zuul05:01
*** bolg has joined #zuul05:08
*** mmedvede has quit IRC05:17
*** mmedvede has joined #zuul05:18
*** evrardjp has quit IRC05:34
*** evrardjp has joined #zuul05:34
*** reiterative has quit IRC05:37
*** reiterative has joined #zuul05:38
*** NBorg has joined #zuul06:01
NBorgHello. I have added a project to a tenant, but it does not appear under projects for that tenant. I've tried smart-reconfigure a couple of times and full-reconfigure once, but I don't see anything about that project in the scheduler log. Any ideas about where I could look for clues?06:15
openstackgerritMohammed Naser proposed zuul/zuul master: configloader: validate playbook-less + secret jobs  https://review.opendev.org/70873106:17
openstackgerritSimon Westphahl proposed zuul/zuul master: Diable misfire grace time of apscheduler job  https://review.opendev.org/70784206:22
*** yolanda has joined #zuul06:22
openstackgerritSimon Westphahl proposed zuul/zuul master: Disable misfire grace time of apscheduler job  https://review.opendev.org/70784206:22
*** jamesmcarthur has joined #zuul06:27
*** jamesmcarthur has quit IRC06:31
*** felixedel has joined #zuul06:55
*** felixedel has quit IRC06:59
*** felixedel has joined #zuul07:00
*** swest has joined #zuul07:26
openstackgerritJan Kubovy proposed zuul/zuul master: Scheduler test app factory  https://review.opendev.org/70881207:27
*** dpawlik has joined #zuul07:31
*** snapiri has joined #zuul07:47
*** jpena|off is now known as jpena07:51
*** jcapitao_away is now known as jcapitao08:06
*** Defolos has joined #zuul08:07
*** bolg has quit IRC08:15
openstackgerritMohammed Naser proposed zuul/zuul master: configloader: validate playbook-less + secret jobs  https://review.opendev.org/70873108:21
*** tosky has joined #zuul08:29
mnaserNBorg: do you see any issues in your zuul web interface? there might be a little bell in the top right corner08:36
openstackgerritMohammed Naser proposed zuul/zuul master: configloader: validate playbook-less + secret jobs  https://review.opendev.org/70873108:43
openstackgerritJan Kubovy proposed zuul/zuul master: Scheduler test app factory  https://review.opendev.org/70881208:48
openstackgerritMohammed Naser proposed zuul/zuul master: ci: use bionic for functional tests  https://review.opendev.org/70882008:53
*** felixedel has quit IRC08:56
*** felixedel has joined #zuul08:58
openstackgerritMohammed Naser proposed zuul/zuul master: DNM: exercising usage of bionic for stream jobs  https://review.opendev.org/70882109:01
*** felixedel has quit IRC09:02
*** carli has joined #zuul09:10
*** avass has joined #zuul09:30
openstackgerritMohammed Naser proposed zuul/zuul master: configloader: validate playbook-less + secret jobs  https://review.opendev.org/70873109:39
*** bhavikdbavishi has quit IRC09:56
openstackgerritMatthieu Huin proposed zuul/zuul master: Authorization rules: add templating  https://review.opendev.org/70519310:01
*** sugaar has joined #zuul10:07
openstackgerritTobias Henkel proposed zuul/zuul master: Make most test cases work on MacOS  https://review.opendev.org/70758510:08
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: Tests ensure-tox on all-platforms  https://review.opendev.org/70864210:14
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: Tests bindep role on all-platforms  https://review.opendev.org/70870410:14
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: Tests bindep role on all-platforms  https://review.opendev.org/70870410:15
*** NBorg has quit IRC10:28
*** sgw has quit IRC10:48
*** reiterative has quit IRC11:04
*** reiterative has joined #zuul11:04
*** sshnaidm|afk is now known as sshnaidm11:23
*** paulalbertella has joined #zuul11:29
*** reiterative has quit IRC11:30
yoctozeptohttps://storyboard.openstack.org/#!/story/2007316 I found how to pass zuul while breaking all jobs :-)11:38
*** jcapitao is now known as jcapitao_lunch11:52
*** rfolco has joined #zuul11:52
openstackgerritTobias Henkel proposed zuul/zuul master: Make most test cases work on MacOS  https://review.opendev.org/70758511:59
*** jpena is now known as jpena|lunch12:00
tobiashyoctozepto: interesting12:01
*** bhavikdbavishi has joined #zuul12:16
AJaegeryoctozepto: Congratulations! ;)12:32
openstackgerritTristan Cacqueray proposed zuul/zuul-operator master: Add zuul-operator-upload-image job  https://review.opendev.org/70886012:34
mnaseroh neat12:35
mnasermy little 'warning' check caught some technically invalid zuul test configs12:35
yoctozeptoAJaeger: well, thank you ;p actually discovered by having to fix other mess in kolla12:35
*** jcapitao_lunch has quit IRC12:38
openstackgerritMohammed Naser proposed zuul/zuul master: configloader: validate playbook-less + secret jobs  https://review.opendev.org/70873112:42
tobiashzuul-maint: I'd appreciate a second review on merge handling improvements: https://review.opendev.org/#/q/topic:merger-refactor12:46
*** rlandy has joined #zuul12:51
*** sshnaidm has quit IRC13:00
*** sshnaidm has joined #zuul13:01
Shrewscorvus: tobiash: I left a comment (and +2) on the scheduler scale out spec that I think is pretty important.13:12
*** jamesmcarthur has joined #zuul13:14
tobiashShrews: should we write this into the spec (gathering metrics) or just to keep in mind?13:14
Shrewstobiash: just to keep in mind. I think ideally there would be some sort of workload that we could capture and replay during development to gather the metrics13:15
*** jamesmcarthur has quit IRC13:15
tobiashShrews: we're using the zookeeper exporter and have quite decent performance data of our zookeeper13:15
Shrewstobiash: but i'm not sure how feasible that is13:15
Shrewstobiash: what is zk exporter?13:16
tobiashit's a metrics exporter that makes zookeeper metrics available to prometheus13:16
Shrewsoh that's neat13:16
openstackgerritFelix Edel proposed zuul/zuul master: Report retried builds via sql reporter.  https://review.opendev.org/63350113:17
Shrewstobiash: i think the biggest thing we want to be able to say to someone running maybe 1 zk server (or 3, etc) is if they should consider adding more nodes or not before using the new scaled out scheduler13:19
tobiashShrews: zk (write) performance is highest with fewer nodes (3 to 7 is recommended)13:20
tobiashfwiw we're using this exporter: https://github.com/carlpett/zookeeper_exporter13:21
openstackgerritAlbin Vass proposed zuul/zuul-base-jobs master: Remove ssh key in base cleanup run.  https://review.opendev.org/70887113:21
*** jpena|lunch is now known as jpena13:24
tobiashShrews: looks like for reads it scales quite well with number of nodes: https://zookeeper.apache.org/doc/r3.5.5/zookeeperOver.html#Performance13:25
avass^ We changed our base job to look like this instead since we encountered some problems with removing ssh keys during post-run with static nodes.13:25
tristanCtobiash: Shrews: also, during the implementation phase, would it be possible to toggle the zookeeper usage to avoid affecting the performance of existing user, at least until the scaled-out feature is completed13:26
tristanCtobiash: hmm, is it normal there is no performance graph for writes ? :)13:28
tobiashtristanC: that graph contains the writes (as a percentage on the x axis)13:28
*** jamesmcarthur has joined #zuul13:29
tristanCtobiash: oh i see, iiuc it's less than 10k write per sec if you have 13 server13:30
tobiashtristanC: of you have only writes then yes ;)13:30
ShrewsI just want us to keep ZK performance in mind as we add workload to it. I don't know anything about tuning it or what factors cause it to slow down, but I know it can hurt us if it doesn't work well. That's all I'm suggesting.   :)13:30
tobiashso tldr, writes are expensive and we'll try to minimize them13:31
*** jamesmcarthur has quit IRC13:31
tristanCshould we recommend to use two clusters in big setup, like one for nodepool and one for zuul?13:32
*** jamesmcarthur has joined #zuul13:32
tristanCiirc, nodepool is already doing quite a few rw request13:32
tobiashtristanC: that cannot be said atm, we need to see how it performs13:33
Shrewsyep, nodepool is constantly iterating through the nodes. lots of zk traffic from it already13:33
tristanCtobiash: i meant, will it even be possible to use two clusters?13:33
tobiashtristanC: theoretically that should be no problem, we'd need to refactor the config for this13:34
tobiashbut I think we should avoid it if possible13:34
*** avass has quit IRC13:34
tristanCtobiash: i agree it seems over complicated, but as the scaled-out implementation is a breaking change, we might as well do that config refactor if it's needed13:35
tobiashbut we have a quite decent deployment, so opendev or we will likely be the first ones to notice performance problems in this regard ;)13:36
tobiashI'm not sure if it will be that breaking once it's working13:36
tristanCtobiash: yeah, hence my question about toggling the feature until it's ready for prime-time.13:37
tristanCtobiash: it is breaking in the sense that executor and schedulers will requires access to zookeeper13:37
tobiashscheduler already has access to zookeeper13:37
tobiashwhat's breaking is executor's access to zookeeper13:38
tristanCexecutor access to zookeeper is a significant change, especially without zookeeper-auth ...13:39
tobiashdo you have executos on different locations?13:39
tristanCwe need that to avoid using floating-ip yes13:41
tobiashthen I think we should consider reviving your zk auth changes13:42
tristanCi'm on it yes :)13:42
*** jamesmcarthur has quit IRC13:44
tobiashtristanC: an alternative could be ssl.clientAuth (https://zookeeper.apache.org/doc/r3.5.5/zookeeperAdmin.html) on zookeeper13:45
openstackgerritTristan Cacqueray proposed zuul/nodepool master: Implement zookeeper-auth  https://review.opendev.org/61915513:45
tristanCtobiash: okay... seems like a very different alternative. should we do that instead?13:47
tobiashhttps://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeper+SSL+User+Guide13:47
tobiashthat link is better13:47
tobiashsounds like if you're doing ssl you're automatically auth'ed13:47
tobiashmaybe that's even better than handling it in zuul13:47
tobiash(needs at least zookeeper 3.5.5)13:48
tristanCtobiash: and what about management. sasl auth is what is currently supported by the bitnami zookeeper image, is there operator or recipe for managing a ssl zookeeper service?13:49
tobiashah I guess we still need to set the ACLs (which can refer then the client id)13:50
tristanChmm, https://github.com/pravega/zookeeper-operator doesn't support either sasl or ssl13:51
tobiashmaybe start first with your change (it'll be neccessary anyway as it seems) and add tls if needed13:51
tristanCwhy would we need acl with tls?13:52
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: Tests ensure-tox on all-platforms  https://review.opendev.org/70864213:52
tobiashtristanC: reading the docs it reads like anyone can connect but you can set acls referring to client certs13:52
tobiashso pretty much like sasl13:52
openstackgerritTristan Cacqueray proposed zuul/zuul master: Implement zookeeper-auth  https://review.opendev.org/61915613:53
*** jamesmcarthur has joined #zuul13:54
*** Goneri has joined #zuul13:55
openstackgerritMohammed Naser proposed zuul/zuul master: configloader: validate playbook-less + secret jobs  https://review.opendev.org/70873114:05
*** phildawson has joined #zuul14:08
openstackgerritMohammed Naser proposed zuul/zuul master: ci: use bionic for functional tests  https://review.opendev.org/70882014:12
openstackgerritMohammed Naser proposed zuul/zuul master: DNM: exercising usage of bionic for stream jobs  https://review.opendev.org/70882114:12
*** jamesmcarthur has quit IRC14:26
mordredpabelanger: heya - I have a task to start publishing the openstack collection to galaxy. the role we have in zuul-jobs is only for doing galaxy import vs galaxy publish ... before I go and do any work here, I know you're doing a lot with collections - do you have any collections content that's not in zuul-jobs that I might want to use or steal?14:29
*** sshnaidm is now known as sshnaidm|afk14:34
openstackgerritFelix Edel proposed zuul/zuul master: Report retried builds via sql reporter.  https://review.opendev.org/63350114:39
pabelangermordred: I've been using https://github.com/ansible/ansible-zuul-jobs/tree/master/roles/upload-ansible-collection-fork but hasn't pushed upstream yet14:39
pabelangerI think we could now14:39
mordredpabelanger: oh neat- that uses twine?14:40
pabelangerhttps://dashboard.zuul.ansible.com/t/ansible/build/abd816bcc33d45b3abcaa9b450e8a620 is an example of our release-ansible-collection-galaxy14:40
pabelangermordred: no, readme is wrong14:40
pabelangercopypasta14:40
mordred:)14:40
pabelangerwe use ansible-galaxy14:40
mordredcool14:40
pabelangerhttps://github.com/ansible-network/releases/blob/master/ansible_releases/cmd/generate_ansible_collection.py14:41
pabelangeris how we generate version numbers for galaxy14:41
pabelangergalaxy.yml14:41
mordredpabelanger: I think the ansible-galaxy setup is identical to ansible-galaxy-upload - so maybe we should split out an ansible-galaxy-login role and include_role it14:41
pabelangerI want to add that into ansible-galaxy CLI by default14:41
mordredYES14:41
mordredbut I will be stealing that in the meantime14:41
pabelangermordred: yah, there is some overlap.  But, you need an ansible.cfg file now, roles didn't14:42
*** jamesmcarthur has joined #zuul14:42
mordrednod. maybe we'll just leave it for now14:42
mordredpabelanger: do you have time to submit that to zuul-jobs? or would you like me to?14:42
pabelangersure, I can add PR14:43
pabelangererr, change14:43
mordredpabelanger: you're being infected ;)14:43
mnaserbased on what i'm seeing, it seems like if a job is aborted inside zuul, it doesnt actually get logged in the sql reporter?14:44
mordredpabelanger: and thanks! sshnaidm|afk will be happy14:44
pabelanger++14:44
mordredtobiash: weren't you working on better reporting for aborted jobs?14:44
mnasermy scenario is if a 2 hour job has been running and then someone submits another change14:44
mordredtobiash: or am I just hallucinating that?14:44
pabelangerI guess I only pushed up https://review.opendev.org/702502/14:44
pabelangerfor github actions14:44
mnaserjust for context14:45
mnaserusing the zuul builds db for billing purposes14:45
mordredpabelanger: oy14:45
mnaserso needing accuracy for every single confused build minute for example14:45
mnaserconfused??14:45
mnaserwhat am i even writing14:45
mordred:)14:45
mnasercounted is what i assume i was going for14:45
*** snapiri has quit IRC14:46
tobiashmordred, mnaser: check out https://review.opendev.org/633501, https://review.opendev.org/632727 and https://review.opendev.org/69667014:46
pabelangermnaser: yah, openstack and rdo track that via ELK, when logs are uploaded14:46
tobiashmnaser: there are also statsd-based usage metrics that report job-hours based on labels14:47
mordredtobiash: that last one seems to match mnaser's use case - gate resets would include jobs aborted due to new patch yeah?14:47
mnaseryeah i come from the prometheus land so i assume we can use that too, but i dont trust prometheus for billing stuff (yet)14:48
tobiashmordred: only in the gate, check would still not land in the db with that14:48
tobiash(would need to be added as well then)14:49
mordredtobiash: gotcha. so we'd still need a followup patch14:49
mordredseems to be a reasonable thing to add with adding the others14:49
mnaseryeah if this lands i think i can add that onto it14:49
mnaseras this will help establish a pattern i can reuse14:50
mordred++14:50
tobiashmordred: but I just today discussed with Felix the possible addition of a dequeue-reporter that would be useful when working with checks api14:50
tobiashthis also could be used to report any items that got dequeued without error or success14:50
mnasersomething i've been mulling over is decoupling of pipeline and zuul config...14:50
mordredooh yeah14:50
tobiashI think this would solve the check use case as well as a side effect14:51
mordredyeah, I think so14:51
mordredmnaser: whatcha mean?14:51
mnaserright now for things like reporters/triggers/etc, you need to *know* what the zuul.conf connections are defined as14:51
mnasersay, if i changed the connection name in my zuul.conf i could potentially break a lot of pipelines14:52
mnaserand i guess we operate a lot with the idea of person defining pipelines = person running zuul14:52
tobiashmnaser: with the ha scheduler patches we'll make sql reporting independent of pipelines14:52
mnaserright, that takes care of that aspect but i was generally just thinking from a UI pov when you're defining pipelines with triggers/etc, you need to know what the name of the connections are in zuul.conf14:53
tobiashmnaser: maybe this could be changed to 'all connections of type x'14:54
tobiashbut you'd still need different settings for say gerrit and github14:55
mnaseryeah, or something where you alias it inside the tenant config14:55
mnaserlike i totally dont have a smart solution for this14:55
mnaserbut its something i've been trying to think about solving in a clean way..14:55
mordredtobiash: I haven't thought it through yet - but I think I like the idea of being able to define "all connections of type x" - because that way pipeline definitions could be shared a bit more easily by people looking for similar workflows without getting caught up in the connection specifics14:58
mordredI'm guessing if you have both public and private github, you're still likely to want a "gate" pipeline to behave the same on both14:59
tobiashyeah, most people anyway add all connections there14:59
mordredyeah14:59
tobiashbut there is still the need to specify a specific connection14:59
tobiashso the syntax would get tricky there14:59
corvusopendev has very different pipeline configurations for the same types of connections in different tenants15:00
mordredcorvus: yah - I definitely don't think it's a config option that could supllant the current one - even in the same tenant gerrit-review and opendev gerrit behave differently15:01
corvusyeah while it's certainly the case that saying "i want check to behave this way for all gerrits" is common, the counter is not at all abnormal...15:01
mordredyah15:01
*** avass has joined #zuul15:02
corvusmordred, mnaser: i think that would be possible to express (ie, i don't think there's a logical problem with the idea), and the implementation wouldn't be too bad, but is also not exactly a one-liner :)15:08
mnaseri mean i was thinking/considering some sort of pipeline inheritance thingamajig15:09
corvus(i think you'd have to iterate over all the matching connections when constructing the pipeline event filters and add one for each)15:09
mnaserwhich would be quite similar to how we handle jobs and wouldn't be far off reach of usual consumers for example15:09
corvusmnaser: btw, the list of available connection names is available to the end user on this page: https://zuul.opendev.org/t/zuul/projects15:10
mnaserah yes15:10
mnaserthats true15:10
corvus(and set aside sql for the moment -- we're solving that by getting it out of pipeline configs)15:10
mnaserperhaps if we added the type of connection too, that would be helpful for users in building their pipelines (obviously some are self-explanitory with names)15:10
corvusyeah that'd be no problem15:11
corvusmnaser: i'm going to mull over pipeline inheritance.  i've never thought about that.  :)15:11
mnaser:)15:11
mnaseralso, i iterated over the 'your job is borked' stuff and it surfaced some other failures in some of our fixtures that we use -- https://review.opendev.org/#/c/708731/15:12
mnaserif we agree that this is something we want to move forward with then i can go ahead and 'fix' those fixtures to be more sane, but didnt want to go all over them in case the failures actually uncovered a real possible scenario that we missed15:12
mnaser(this is a job with no playbooks + secrets without pass-to-parent:true)15:13
corvusmnaser: cool!  i'll look into those and verify15:13
mnaserthank you, corvus15:14
*** sgw has joined #zuul15:14
corvusmnaser: those are all okay to "fix".  i believe they all merely omit playbooks to keep the test data simpler.15:22
mnasercorvus: ok cool, i'll iterate and push up a fix shortly15:25
mnaserthanks15:25
openstackgerritMerged zuul/zuul-jobs master: set jobs for installing openvswitch  https://review.opendev.org/70872715:31
openstackgerritJames E. Blair proposed zuul/zuul-jobs master: Add ensure-bazelisk role  https://review.opendev.org/70889915:34
corvusmordred: ^ 1/215:34
mordredcorvus: \o/15:35
openstackgerritJames E. Blair proposed zuul/zuul-jobs master: Add ensure-bazelisk role  https://review.opendev.org/70889915:36
corvusforgot to add the job :)15:36
openstackgerritJames E. Blair proposed zuul/zuul-jobs master: Add ensure-java role  https://review.opendev.org/70890115:43
corvusmordred: ^ 2/215:43
*** sshnaidm|afk is now known as sshnaidm15:43
mordredcorvus: awesome. I'll work on getting our gerrit jobs changed as soon as I'm done with gitea this morning15:44
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: Tests ensure-tox on all-platforms  https://review.opendev.org/70864215:47
sshnaidmpabelanger, for building collection role, where do you install ansible? in tox venv or other place?15:51
pabelangersshnaidm: in virtuelenv15:52
sshnaidmpabelanger, it has configurable path, right?15:52
sshnaidmpabelanger, and ansible version15:52
pabelangeryes, build-collection role we had exposed that15:52
pabelangerlet me share15:52
sshnaidmpabelanger, I'd like to use ansible-galaxy from devel now, it has some critical features15:53
pabelangeryes, you can use it15:53
sshnaidmnice15:53
pabelangerwe today test with ansible-base, which is migrated content from devel15:53
pabelangerhttps://github.com/ansible/ansible-zuul-jobs/tree/master/roles/build-ansible-collection15:54
pabelangerthat is our role15:54
sshnaidmpabelanger, yeah, I stole it for us :) https://review.opendev.org/#/c/708372/3/ci/playbooks/roles/build-ansible-collection/tasks/main.yml15:54
sshnaidmpabelanger, but didn't see there deps isntall15:55
sshnaidmpabelanger, do you have it in separate role?15:55
pabelangeryah, we do it outside of that role15:56
pabelanger1 sec15:56
pabelangerhttps://dashboard.zuul.ansible.com/t/ansible/build/3d8c01cfbfaf4b82ba6d982d2cbcbdf515:57
pabelangeris an example job, build-ansible-collection15:57
pabelangerit is a little different, as today it builds _all_ collection dependencies, not just one15:57
pabelangerbut, pre-run playbooks setup ansible venv15:57
*** rfolco is now known as rfolco|doctor16:04
*** jpena is now known as jpena|off16:07
*** mattw4 has joined #zuul16:08
sshnaidmpabelanger, so you actually use ansible from tox venv, ok16:31
sshnaidmpabelanger, also wanted to use it for installing various ansible releases..16:32
*** Defolos has quit IRC17:08
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: Tests ensure-tox on all-platforms  https://review.opendev.org/70864217:13
*** jpena|off is now known as jpena17:27
*** evrardjp has quit IRC17:34
*** carli has quit IRC17:34
*** evrardjp has joined #zuul17:35
*** chandankumar is now known as raukadah18:14
*** jpena is now known as jpena|off18:34
*** igordc has joined #zuul18:34
openstackgerritJames E. Blair proposed zuul/zuul-jobs master: Add ensure-bazelisk role  https://review.opendev.org/70889918:35
openstackgerritJames E. Blair proposed zuul/zuul-jobs master: Add ensure-java role  https://review.opendev.org/70890118:36
mnaserhow much people would i piss off if i split off tests_v3 :)18:43
corvusmnaser: if you can figure out a good organizational structure, it may be welcome.18:45
fungisince i'm not sure what tests_v3 is, not me at least! ;)18:45
mnaseri just worry that it will merge conflict the heck of everyone18:45
corvusfungi: most of zuul's tests are in 2 files.  as clarkb describes it, "test_scheduler" is "test all the things" and "test_v3" is "test all the rest of the things"18:45
openstackgerritMohammed Naser proposed zuul/zuul master: configloader: validate playbook-less + secret jobs  https://review.opendev.org/70873118:46
mnasermy vim runs pylint post-save but its doing it non asynchronously so it destroys my machine on every save :p18:47
clarkbtestv3 was where the v3 new behavior stuff got tested and test_scheduler is where the bulk of testing has lived and was retrofitted. Generally those files don't tend to merge conflict too much though as people work in specific areas of them (that said organizing a bit more would probably be worthwhile)18:47
fungii'm not getting any hits out of `git ls-files '*tests_v3*'` in zuul/zuul18:47
clarkbfungi: test_v3 iirc no extra 's'18:47
fungiaha, tests/unit/test_v3.py thanks!18:47
*** saneax has quit IRC18:55
tobiashmnaser: it will conflict with all I have, but I'd still appreciate that ;)18:56
mnaseri think i might have a reaosnable step #118:56
tobiashactually I'd like to split some more files (e.g. scheduler, executor server) as I find it still hard to navigate through those files with >2500 lines18:58
tobiashbut I don't know what the general feeling in this regard is so I didn't so far18:59
tobiashe.g. AnsibleJob could be moved into its own file19:00
openstackgerritMohammed Naser proposed zuul/zuul master: cleanup: move AnsibleZuulTestCase to test_ansible  https://review.opendev.org/70895219:06
mnasercorvus, tobiash: here is a small thing we can do (passed pep8 locally)19:07
*** plaurin has joined #zuul19:10
tobiashmnaser: I think we shouldn't judge on the base class but more on the use case/component that get's tested19:10
mnasertobiash: i agree, but this seemed like a small first iteration of slowly splitting things19:10
tobiashok, I think it makes sense of a first step to make the file smaller, however we probably should think about a general structure19:13
*** rlandy is now known as rlandy|mtg19:16
mnaseri agree19:16
mnaserhmm19:26
mnasercorvus: there seems to be a behaviour change in my change here https://review.opendev.org/#/c/708731/ in the unit tests - https://ad793cc4ef661bc84354-a22e2178400a1d74c0dfc0d0570ba9cf.ssl.cf5.rackcdn.com/708731/8/check/tox-py37/e3057dc/testr_results.html19:27
mnasermaybe i did something wrong :\ but im not sure why adding 'run' into the playbook made the secret come from parent instead of the job itself19:28
mnasereven tho that wasnt a pass-to-parent, so i'm a bit confused19:28
*** rlandy|mtg is now known as rlandy19:34
*** Defolos has joined #zuul19:35
plaurinHello irc people ;-)19:36
plaurinHey about the discussions we had the other days about kubernetes related srdout logging, hum, I'm not used to participate that much in open source communities (very limited experience...) Should I be reporting somehting like a bug or feature request somewhere?19:37
plaurinAlso then I can maybe follow the progress on this an help in any way I can, by testing fixes or else19:38
*** igordc has quit IRC19:38
clarkba story on storyboard would probably help. (https://storyboard.openstack.org/#!/story/list then click create story) you'll need an ubuntu one account for that19:40
corvusplaurin: if you do that, you could add this link to the story: http://eavesdrop.openstack.org/irclogs/%23zuul/%23zuul.2020-02-03.log.html#t2020-02-03T19:30:5219:43
corvusthen we'll remember what we need to do :)19:43
plaurinokay will do, yeah I have my ubuntu one account somewhere...... :P19:44
plaurinthx19:44
*** jamesmcarthur has quit IRC19:45
plaurinWhat would you recommend as a story name?19:45
plaurinKubernetes logging in zuul?19:45
corvusplaurin: "Kubernetes log streaming"19:46
corvusplaurin: the 'streaming' keyword helps narrow down what kind of logging we're talking about19:46
corvusthough i guess we also discovered that the stdout isn't working correctly19:47
corvusso maybe "kubernetes command output"19:47
plaurinshouldn't zuul be a keyword as well?19:47
corvusplaurin: the story will be against the zuul project, so it's implied19:47
corvus(or, well, the task will be, but that's enough)19:47
plaurinokay, hmm.. how is it implied that this is for zuul? (sorry that may be dumb from your perspective... :P )19:48
clarkbplaurin: when you create the story one of the fields is the project which you should enter 'zuul/zuul' for19:49
plaurinoh, got it19:49
plaurinprivate?19:57
fungipublic19:57
fungiprivate is mainly for reporting suspected security vulnerabilities19:57
plaurinmakes sense19:57
fungijust so that we might have a chance of fixing them before more folks find out and can exploit them19:58
plaurinyes, that's a good idea19:58
plaurinokay I submitted the story!19:58
fungithanks plaurin! looks like it's https://storyboard.openstack.org/#!/story/200732120:00
plaurinyep!20:00
plaurinah, I should add the link above to the story20:01
plaurinthe eavesdrop url, done20:03
fungiperfect, thanks again!20:06
plaurinMy first report on story board hehe \o/ thx to you20:08
mordredplaurin: thanks you!20:31
plaurinanytime20:32
*** bhavikdbavishi has quit IRC20:39
*** armstrongs has joined #zuul21:07
*** armstrongs has quit IRC21:11
*** Goneri has quit IRC21:25
*** igordc has joined #zuul21:28
*** plaurin has quit IRC21:40
*** dpawlik has quit IRC22:33
*** sshnaidm is now known as sshnaidm|afk23:02
*** Defolos has quit IRC23:38

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