Monday, 2019-02-11

*** swest has quit IRC02:48
*** bhavikdbavishi has joined #zuul02:53
*** swest has joined #zuul03:03
*** sdake has quit IRC03:08
*** sdake has joined #zuul03:10
openstackgerritMerged openstack-infra/nodepool master: bindep: add sudo  https://review.openstack.org/63587603:54
*** chandankumar is now known as chkumar|ruck04:32
openstackgerritTristan Cacqueray proposed openstack-infra/zuul-jobs master: add-build-sshkey: remove previously authorized build-sshkey  https://review.openstack.org/63262004:44
openstackgerritTristan Cacqueray proposed openstack-infra/zuul-jobs master: DNM: trying to test add-build-sshkey  https://review.openstack.org/63608704:44
openstackgerritTristan Cacqueray proposed openstack-infra/zuul-jobs master: DNM: trying to test add-build-sshkey  https://review.openstack.org/63608704:54
openstackgerritTristan Cacqueray proposed openstack-infra/zuul-jobs master: DNM: trying to test add-build-sshkey  https://review.openstack.org/63608705:00
openstackgerritTristan Cacqueray proposed openstack-infra/zuul-jobs master: DNM: trying to test add-build-sshkey  https://review.openstack.org/63608705:16
openstackgerritTristan Cacqueray proposed openstack-infra/zuul-jobs master: DNM: trying to test add-build-sshkey  https://review.openstack.org/63608705:27
*** swest has quit IRC05:29
*** bjackman has joined #zuul06:00
openstackgerritTristan Cacqueray proposed openstack-infra/zuul-jobs master: add-build-sshkey: remove previously authorized build-sshkey  https://review.openstack.org/63262006:00
openstackgerritTristan Cacqueray proposed openstack-infra/zuul-jobs master: DNM: trying to test add-build-sshkey  https://review.openstack.org/63608706:06
*** swest has joined #zuul06:16
*** swest has quit IRC06:20
*** swest has joined #zuul06:34
*** sshnaidm|off is now known as sshnaidm|afk06:45
*** quiquell|off is now known as quiquell|rover06:48
*** saneax has joined #zuul06:53
*** AJaeger has quit IRC07:10
*** AJaeger has joined #zuul07:23
*** toabctl has joined #zuul07:26
*** saneax is now known as saneax|lunch07:29
*** quiquell|rover is now known as quique|rover|brb07:39
openstackgerritTristan Cacqueray proposed openstack-infra/zuul-jobs master: DNM: trying to test add-build-sshkey  https://review.openstack.org/63608707:50
openstackgerritTristan Cacqueray proposed openstack-infra/zuul-jobs master: DNM: trying to test add-build-sshkey  https://review.openstack.org/63608708:00
*** saneax|lunch is now known as saneax08:01
openstackgerritTristan Cacqueray proposed openstack-infra/zuul-jobs master: DNM: trying to test add-build-sshkey  https://review.openstack.org/63608708:05
*** gtema has joined #zuul08:09
openstackgerritTristan Cacqueray proposed openstack-infra/zuul-jobs master: DNM: trying to test add-build-sshkey  https://review.openstack.org/63608708:11
bjackmanDoes the name of a project in Zuul have to match its URL suffix wrt. the connection's base URL?08:17
*** electrofelix has joined #zuul08:18
bjackmane.g. if my connection.baseurl is https://git.kernel.org , and I want to add the Linux kernel stable tree as a project, do I have to call it "pub/scm/linux/kernel/git/stable/linux.git/"08:18
*** jpena|off is now known as jpena08:22
bjackmanHad a look in the code and it does indeed seem that way.. I think I'll just rather cheekily use a longer base URL - if it turns out we need repos from a different section of git.kernel.org I"ll just add a separate connection. ¯\_(ツ)_/¯08:34
bjackmanLong base URL is hidden from users but long project names aren't08:34
*** electrofelix has quit IRC08:35
*** electrofelix has joined #zuul08:37
*** quique|rover|brb is now known as quiquell|rover08:39
*** themroc has joined #zuul08:58
openstackgerritTristan Cacqueray proposed openstack-infra/zuul master: executor: enable zuul_return to update Ansible inventory  https://review.openstack.org/59009209:08
openstackgerritMatthieu Huin proposed openstack-infra/zuul master: [WIP] web: add tenant and project scoped, JWT-protected actions  https://review.openstack.org/57690709:11
*** bhavikdbavishi has quit IRC09:16
*** avass has joined #zuul09:20
fboHello ! we have some Zuul users that would like to trigger jobs based on the status of a web resource (an artifact for instance). They want to monitor when the artifact has changed then trigger job(s).09:25
*** sshnaidm|afk is now known as sshnaidm09:26
fboTo provide the feature I'm proposing a new driver https://review.openstack.org/#/c/635567/09:26
fboIs this a feature that could acceptable and eventually land in Zuul ? Or is there a better solution to trigger jobs based on an external resource change ?09:28
tobiashfbo: I think that can be useful09:33
avassI know you can use job.files to run a job if certain files are affected but does zuul supply information about which files were affected to the jobs?09:46
avassaffected by a change09:51
tobiashavass: you can git diff against origin/<target branch>09:55
tobiashavass: origin/<target branch> will contain the speculative future state of the change ahead (or tip of the branch if there is no change ahead)09:56
avasstobiash: I was figuring either that or querying gerrit. was just wondering if zuul were already carrying that inforamtion09:58
fbotobiash: alright, great, well what I wanted is a first agreement from a core that say "it not a completly dumb change" :) so then I can move forward and implement unittests.10:08
*** bhavikdbavishi has joined #zuul10:08
tobiashfbo: but you should also discuss it with corvus ;)10:10
fbotobiash: yes sure. corvus what do you think about this idea to have a new driver URLTrigger like https://review.openstack.org/#/c/635567/ ?10:14
*** bjackman has quit IRC10:33
openstackgerritFabien Boucher proposed openstack-infra/zuul-jobs master: Add the skip_bindep option to the tox job  https://review.openstack.org/63587710:37
openstackgerritFabien Boucher proposed openstack-infra/zuul-jobs master: Add the tox_install_bindep option to the tox job  https://review.openstack.org/63587710:38
AJaegerfbo: your change misses tests and documentation and thus will not merge as is. But sure, we can discuss whether we want this first...10:54
*** bjackman has joined #zuul10:58
fboAJaeger: yes I know but I prefer to get a first feedback on the idea and implementation then move forward with unittest and doc if feedback is good.10:59
AJaegerfbo: good practice is to mention this in commit message or mark as WIP with comment. That way it's clear what your intention is...11:00
fboAJaeger: yes you're right I'll amend the change then11:01
openstackgerritFabien Boucher proposed openstack-infra/zuul master: [WIP] URLTrigger driver time based - artifact change jobs triggering driver  https://review.openstack.org/63556711:07
*** bjackman has quit IRC11:18
*** gtema has quit IRC11:18
*** gtema has joined #zuul11:27
*** bjackman has joined #zuul11:28
*** bhavikdbavishi has quit IRC11:56
*** goern has joined #zuul11:57
*** bjackman has quit IRC12:07
*** jpena is now known as jpena|lunch12:32
*** swest has quit IRC12:41
*** swest has joined #zuul12:43
*** rlandy has joined #zuul13:10
*** jpena|lunch is now known as jpena13:35
*** quiquell|rover is now known as quique|rover|eat13:49
*** quique|rover|eat is now known as quiquell|rover14:17
*** gtema has quit IRC14:33
jktI wonder how much work would it be to convert the static provider in nodepool to execute an action such as a node reboot after a job finishes14:36
jktmy TL;DR use case can be roughly characterized as "I would prefer not to install OpenStack with all its layers on these eight physical servers"14:37
jktso I was thinking of VMs provisioned via libvirt with an auto-reimage-on-VM-reboot :)14:38
pabelangeryou could do a post-run playbook today, with reboot (node) and wait_for. When job finished, your static node is in correct state.14:44
jktpabelanger: thanks, I didn't know that ansible can do *that*14:51
jktpabelanger: the cosmetic issue is that it ties image-specific bits into a base job, which will become a problem once I migrate to that openstack that $other_department has been promising for quite some time14:52
jktbut me try that, I think I like it :)14:53
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Fix excluded config if excluded in earlier tenant  https://review.openstack.org/63614615:03
*** bhavikdbavishi has joined #zuul15:03
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Don't exclude config if excluded in earlier tenant  https://review.openstack.org/63614615:04
*** snapiri has quit IRC15:08
*** ParsectiX has joined #zuul15:20
*** saneax has quit IRC15:33
*** avass has quit IRC15:38
*** quiquell|rover is now known as quiquell|off15:39
*** electrofelix has quit IRC16:05
*** ParsectiX has quit IRC16:16
SpamapSjkt: you could write an ovirt driver. :)16:21
*** chkumar|ruck is now known as chandankumar16:24
*** themroc has quit IRC16:31
*** bhavikdbavishi has quit IRC16:32
*** bjackman has joined #zuul16:42
corvusfbo: sorry i should have responded to your email.  i think a urltrigger in principle is a good idea.  basing it on the timer trigger makes sense.  i wonder even if you could actually inherit from the timer trigger.  because basically it's a timer trigger which only triggers if the url has changed.  that might save some code.16:43
dkehntobiash: when setting the executor's hostname zuul.conf & docker-compose.yaml (example), it's assuming it will resolve to that for other containers (zuul-web) to find it?16:48
*** dmsimard6 has joined #zuul16:48
jktSpamapS: :)16:50
*** dmsimard6 is now known as dmsimard16:51
fbocorvus: hi, alright yes I should be able to refactor to use most of the existing timer driver. thanks for the feedback I'll provide a new PS :)16:54
tobiashdkehn: yes16:55
*** ParsectiX has joined #zuul16:58
*** sdake has quit IRC17:12
jktdo I have access to some info from nodepool within a job definition in ansible?17:13
jktto e.g. call a certain playbook just on nodes which originated within a given nodepool static pool17:13
corvusjkt: there are two things available to help with that17:14
corvus1 -- there is some information from nodepool available; it's not formally specified, but you can see it in the inventory file.  things like cloud, region, etc.  we've used that to, for example, configure region-local mirrors.17:15
*** sdake has joined #zuul17:16
corvus2 -- when zuul requests a node from nodepool, you can assign it a name, or assign it to a group.  so if you request nodes which only come from a specific region, you can name or group those in such a way that you can write a play that targets them.17:16
jktcorvus: thanks. My TL;DR use case is that I'm too lazy to deploy openstack, and I've setup my static VMs to reset to a known-good state after each reboot, so I would like to reboot them from within a pre-run playbook as per pabelanger's suggestion17:17
corvusjkt: for an example of (1) see the "nodepool" section at the top of http://logs.openstack.org/24/635924/5/check/netlify-sandbox-build-site/926bb0a/zuul-info/inventory.yaml17:17
corvusjkt: oh, with (1) i was assuming openstack driver17:17
corvusjkt: i see the word "static" in your question now.  sorry.17:17
jktcorvus: in future I will get access to a random openstack cloud from $another_dept, and I would like to do my base job properly, and only reboot/init/whatever that VM when it's coming form my crap pool17:19
corvusjkt: would option (2) work for you?  if the label you are requesting from nodepool only returns these static nodes, you should be able to do that17:19
corvusjkt: but if the label might return non-static nodes, then it won't work17:19
jktcorvus: I thought that I would use labels for bits like identifying a linux distro + version17:20
jktso I was thinking about a label like fedora-29 for that image, regardless whether it comes from my static pool or from openstack17:21
corvusok then #2 isn't suitable17:21
jktbut perhaps it's a wrong usage of labels/tags, dunno?17:21
corvusjkt: no i think you've got the right idea about labels17:21
corvusjkt: for the openstack driver we have this: https://zuul-ci.org/docs/nodepool/configuration.html#attr-providers.[openstack].pools.node-attributes17:21
corvusmaybe that needs to be ported to the other drivers17:21
jktthat sounds easy enough17:22
jktthanks!17:22
corvusi'm double checking that that gets passed through to the executor...17:22
corvusjkt: it is not.  but i think it would be a reasonable change to do so.  so that would need a change to nodepool to add that to the static driver, then a change to the zuul executor to include that information in the inventory.17:24
corvusi think those would both be fairly small changes.  we should run this by Shrews too.17:24
jktthanks for looking into this17:26
corvusclarkb, mordred: a review of https://review.openstack.org/634825 would help me move the docker registry work along17:28
openstackgerritJames E. Blair proposed openstack-infra/zuul-jobs master: Add intermediate registry push/pull roles  https://review.openstack.org/63482917:29
Shrewscorvus: jkt: i think that's one of the common config options (node-attributes) so my config changes from a couple weeks ago should get that in every driver17:32
corvusShrews: awesome -- do you know if the other drivers are putting that info into zk, or do we need to update them to do that?17:33
Shrewsconfirmed, that is a common attr17:33
Shrewscorvus: i think the driver(s) would need to be updated to actually use it17:33
corvusat least we're halfway there17:33
Shrewscurrently only openstack driver does17:33
Shrewsyeah, should be easy enough17:33
*** jpena is now known as jpena|off17:35
Shrewscorvus: but that only guarantees data shows up in zookeeper. does the executor dump all node-attributes values to the inventory file?17:35
Shrewsmight be a question for pabelanger ^^^17:36
corvusShrews: it does not, but it would be a small change to do so17:37
clarkbcorvus: in https://review.openstack.org/#/c/634825/5/zuul/driver/sql/sqlconnection.py why rename metadata to meta?17:41
*** panda is now known as panda|off17:41
corvusclarkb: ah, that probably warrants a note.  sqlalchemy reserves the attribute 'metadata' in the way we're using it17:42
corvusthat seemed the easiest way around the issue17:42
clarkbgotcha17:44
openstackgerritJames E. Blair proposed openstack-infra/zuul master: Add a note about sqlalchemy metadata  https://review.openstack.org/63618917:45
corvusclarkb: ^17:45
*** bhavikdbavishi has joined #zuul17:46
clarkbThanks. I went ahead and approved both changes (the first already had a +2 and the second is only a comment addition)17:47
*** bhavikdbavishi has quit IRC17:47
corvusclarkb: w00t, thanks :)17:47
corvuswhen we restart openstack's zuul with that, we can land the other 2 changes and start testing it out.  the opendev intermediate registry is running now.17:48
corvusthough... apparently i forgot to docker the docker network dockers or something17:49
clarkbis that our first srevice running on top of a docker image in production?17:49
corvusclarkb: yep.17:49
corvushopefully soon to be our first service running and listening on a network port :)17:50
Shrewscorvus: i think you have to be wearing dockers to docker properly17:50
Shrewsso, ya know... put some pants on17:51
* corvus goes to rectify the situation17:51
*** saneax has joined #zuul17:53
*** sdake has quit IRC18:01
*** sdake has joined #zuul18:03
openstackgerritMerged openstack-infra/zuul master: Return artifacts as dicts and add metadata  https://review.openstack.org/63482518:07
openstackgerritMatthieu Huin proposed openstack-infra/zuul master: [WIP] Allow operator to generate auth tokens through the CLI  https://review.openstack.org/63619718:14
*** bjackman has quit IRC18:14
*** ParsectiX has quit IRC18:14
*** sdake has quit IRC18:27
openstackgerritMerged openstack-infra/nodepool master: Rename aws flavor-name to instance-type  https://review.openstack.org/63515318:28
*** sdake has joined #zuul18:30
*** sdake has quit IRC18:32
* mordred now tries to imagine corvus wearing dockers18:42
*** openstackgerrit has quit IRC18:51
SpamapSBTW, GoodMoney's zuul and nodepool are now patch free!18:52
*** rlandy is now known as rlandy|brb18:52
corvusSpamapS: congrats!18:52
SpamapSI'm working on a patch to the EC2 driver to use EC2's capacity reservation system to act like quota management in OpenStack...18:53
mordredSpamapS: woot!18:54
SpamapSBecause just yesterday I ran into instance type limits... somebody spun up a t3.medium in the same region as nodepool, and I had max-servers: 10, but I can only run 10x t3.medium's. This resulted in NODE_FAILURE rather than queued jobs. If I use a capacity reservation, that user would have been denied the t3.medium.18:54
SpamapSNot sure if there's a way to also just decline a request if we try to take it, but then get that error back from EC2 actually.18:55
*** sdake has joined #zuul18:55
*** rlandy|brb is now known as rlandy19:09
*** sdake has quit IRC19:09
jktcan I have zuul stage content somewhere else than into the user's home dir?19:17
corvusjkt: yes.  zuul itself only stages it on the executor; it's the prepare-workspace role in zuul-jobs that's typically in the base job that pushes it on to the remote hosts19:18
jktcorvus: and how do I override bits like ~/.ansible?19:19
corvusjkt: i'm not sure i understand that question; i don't think ~/.ansible is required on remote nodes19:20
jkt2019-02-11 20:15:56.846380 | f29 |   "msg": "Authentication or permission failure. In some cases, you may have been able to authenticate and did not have permissions on the target directory. Consider changing the remote tmp path in ansible.cfg to a path rooted in \"/tmp\". Failed command was: ( umask 77 && mkdir -p \"` echo /home/ci/.ansible/tmp/ansible-tmp-1549912556.7046826-158828137740828 `\" && echo ansible-tmp-1549912556.7046826-158828137740828=\"` echo /home/ci/.ansi19:22
jktin case that was truncated, https://ci-logs.gerrit.cesnet.cz/t/public//89/1389/3/check/test-shell-f29/4005ebc/job-output.txt.gz19:22
mordredah - remote_tmp_path19:23
jktI can whitelist it pretty easily, but that's one more image rebuild for me :)19:23
corvusjkt: if you can do that, i think that's going to be the best option.  because support for an alternate remote_tmp_path in zuul might be a bit complex (in that it's probably more of a node attribute than an executor attribute, which probably means we have to plumb it all the way through nodepool).19:25
corvusat the very least, we would need to discuss it a bit :)19:25
mordredwe don't currently have any mechanism for configuring remote_tmp_path in the ansible.cfg differently - if we wanted to grow one, we'd need to think it through - cause it might be one of those things that should be a node attribute19:25
mordredcorvus: jinx19:25
jktack, no problem, let me hack around it19:25
corvusmordred: that's very reassuring :)19:26
*** saneax has quit IRC19:29
jktwhat am I doing wrong that this change: http://paste.openstack.org/show/744886/ on my base job won't really affect the prepare-workspace playbook?19:59
jktit is not getting propagated to the inventory as far as I can tell, https://ci-logs.gerrit.cesnet.cz/t/public//89/1389/3/check/test-shell-f29/77ace83/zuul-info/inventory.yaml20:01
corvusjkt: it looks like the prepare-workspace-git and mirror-workspace-git roles are hard-coded to put the repos in ansible_user_dir, so you may need to update those roles to support another location.20:02
corvusjkt: http://git.zuul-ci.org/cgit/zuul-jobs/tree/roles/prepare-workspace-git/tasks/main.yaml20:02
corvusjkt: and i can't seem to connect to that host20:03
jktcorvus: sorry, it's ipv6-only :(20:03
corvusjkt: cool, no apology necessary :)20:04
jktI'm actually using prepare-workspace, not prepare-workspace-git20:04
corvus(my tunnel is offline at the moment)20:04
jktthat one looks correct20:04
corvusjkt: hrm, i agree that should work.  i'll look at your inventory20:04
jkthere it is, http://paste.openstack.org/show/744887/20:05
corvusjkt: did you merge that change, or is it in review?20:06
jktcorvus: the job definition comes from a change that's under review20:06
jktcorvus: but I've force-pushed the change to the base job20:06
jktdoes Zuul like force-pushes to trusted project-config repos? :)20:07
corvusjkt: it should be fine20:07
corvuswell. actually...20:07
* jkt restarts20:07
corvusjkt: i'm sure that if you force-merged the change it would work20:07
corvusjkt: but if you *pushed* it, i'm not positive.20:07
jktcorvus: I restarted executor and scheduler, and it helped :)20:09
corvusjkt: cool, 'zuul-scheduler full-reconfigure' should fix that with a little less interruption in the future20:11
corvussomeday we'll add a cli tenant reconfig option too20:11
jkthowever, it seems that {{ zuul.project.src_dir }} still points to the home dir20:13
jktso apparently just overriding zuul_workspace_root within a base job is not the way to go20:13
pabelangeryou might be hitting variable precedence issue, you could try override the variable from your playbook20:15
mnasermordred: regarding zuul-preview, https://github.com/openresty/lua-nginx-module could be an interesting alternative :)20:18
jktwell, this actually makes sense -- if I create a variable within a scope of the base job, a variable called 'zuul_workspace_root', how is Zuul supposed to feed that data back to, e.g., zuul.project.src_dir ?20:18
jktso this probably has to be done via site-wide variables20:20
mordredmnaser: yeah - but then I'd have to write lua20:20
jktI think it would make a lot of sense to pass this zuul_workspace_root from nodepool, though20:20
mnasermordred: you did write c++ :)20:20
mnaser:P20:20
pabelangerjkt: http://paste.openstack.org/show/744889/ should work20:21
pabelangeror  https://zuul-ci.org/docs/zuul/user/jobs.html#user-jobs-sitewide-variables20:21
jktpabelanger: let me rephrase my question -- how does Zuul know what the "work dir" is going to be at the target node?20:27
corvusjkt: zuul.project.src_dir is actually a relative path20:29
corvusjkt: it's relative to zuul.executor.src_root, which is on the executor20:29
corvusjkt: allow me to back up and preface this by saying two things: 1) there's a lot of stuff that probably expects that the user's home dir on the remote node is accessible.  making that work is going to be the best experience.  :)20:31
corvusjkt: 2) but zuul is designed to account for any configuration on the remote node, so you can absolutely do whatever you want.  but it's going to be harder and may require you to implement (or re-implement) more things yourself20:32
corvusjkt: so with that out of the way, the key thing to remember here is that *zuul itself* only writes things into a work directory on the executor it controls.  everything else that happens after that is controlled by ansible jobs and roles.20:32
corvusjkt: so all of those path variables in the inventory are executor paths.20:33
corvusthey are, however, conveniently structured in such a way that they can and are also used by the roles in zuul-jobs.20:33
corvusso for example, on the executor, a repo might be checked out into /var/lib/zuul/builds/8b9b85d62fb14f3cab8f9d62274436fe/work/src/git.openstack.org/openstack-infra/system-config20:34
corvuswhich is zuul.executor.work_root + zuul.project.src_dir20:34
corvusthe workspace setup roles in zuul-jobs re-use the latter part of thet -- zuul.project.src_dir20:35
*** quiquell|off is now known as quiquell|rover20:35
corvusso on the remote node you end up with the repo at ansible_user_dir + zuul.project.src_dir20:35
jktcan I easily have zuul launch ansible with its cwd pointing "somewhere else"? that sounds like what I'm looking for20:35
corvusjkt: ansible is run on the executor, so that won't help here20:35
jktand there's no easy override for ansible_user_dir because that one comes from the remote system's config at runtime, and even if there were, that would breaks bits such as ssh key provisioning, okay20:37
corvusjkt: yeah, that goes into the same bucket as a configureable remote_tmp -- possible but needs thought.20:38
jktsounds like I will find a way to just have the home dir prepopulated on that throw-away filesystem20:38
*** gouthamr has quit IRC20:38
*** dmellado has quit IRC20:39
*** quiquell|rover is now known as quiquell|off21:00
tobias-urdincorvus: fungi friendly ping on https://review.openstack.org/#/c/635941/ if you have some minutes over today :) https://review.openstack.org/#/c/635965/ is related project-config change21:15
tobias-urdinpabelanger: ^ new approach without removing revoke-sudo, so secret never leaves executor21:15
mordredmhu: :)21:25
pabelangerjkt: sorry, stepped away from keybord, but agree with corvus21:35
pabelangerkeyboard*21:36
*** gouthamr has joined #zuul21:39
*** dmellado has joined #zuul21:43
*** openstackgerrit has joined #zuul21:54
openstackgerritMatthieu Huin proposed openstack-infra/zuul master: [WIP] Allow operator to generate auth tokens through the CLI  https://review.openstack.org/63619721:54
openstackgerritJames E. Blair proposed openstack-infra/zuul master: Add a note about sqlalchemy metadata  https://review.openstack.org/63618921:55
openstackgerritJames E. Blair proposed openstack-infra/zuul master: Fix typo in build api endpoint  https://review.openstack.org/63622721:55
*** sdake has joined #zuul22:19
*** sdake has quit IRC22:51
*** sdake has joined #zuul22:56
*** sdake has quit IRC22:59
*** sdake has joined #zuul23:06
clarkbcorvus: were there still potential test node performance issues being found by the zuul test suite?23:12
clarkbI'm trying to take stock of the current set of known failures now that e-r has some data in it again23:13
corvusclarkb: unclear.  i suspect so, but my non-zuul cup overfloweth at the moment.  :)23:13
clarkbok I'll keep an eye out for related issues. Right now I'm mostly just doing high level "what types of bugs are affecting us?" sorting23:14
corvusclarkb: yeah http://logs.openstack.org/89/636189/2/gate/tox-py36/27ccaf4/testr_results.html.gz had a performance sad23:15
*** sdake has quit IRC23:31
corvuszuul maintainers (should we define an irc highlight? zuul-maint?), i have uploaded https://review.openstack.org/636238 to import zuul-preview, please review :)23:38
openstackgerritMatthieu Huin proposed openstack-infra/zuul master: [WIP] Allow operator to generate auth tokens through the CLI  https://review.openstack.org/63619723:46
*** mrhillsman has quit IRC23:46
*** TheJulia has quit IRC23:46
*** jtanner has quit IRC23:46

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