| *** odyssey4me has quit IRC | 00:08 | |
| *** odyssey4me has joined #zuul | 00:08 | |
| *** JasonCL has joined #zuul | 00:14 | |
| *** JasonCL has quit IRC | 00:29 | |
| *** JasonCL has joined #zuul | 00:48 | |
| *** JasonCL has quit IRC | 00:54 | |
| *** JasonCL has joined #zuul | 00:58 | |
| *** JasonCL has quit IRC | 01:03 | |
| *** JasonCL has joined #zuul | 01:10 | |
| *** harlowja has quit IRC | 01:19 | |
| *** JasonCL has quit IRC | 01:19 | |
| dmsimard | The ara sqlite middleware is working fairly well but has some rough edges still. I'll try and improve that but I was thinking... at what point can we not just expose the live run while it's running on the executor ? | 02:17 |
|---|---|---|
| *** JasonCL has joined #zuul | 02:17 | |
| dmsimard | Like in the job frame ( https://i.imgur.com/t2HH0tN.png ) there could be a link to 1) the console stream 2) the live ara results | 02:19 |
| dmsimard | of course ara isn't really super async awesome and etc but eventually maybe | 02:19 |
| *** JasonCL has quit IRC | 02:20 | |
| *** JasonCL has joined #zuul | 02:21 | |
| *** threestrands has quit IRC | 02:47 | |
| *** JasonCL has quit IRC | 02:47 | |
| *** threestrands has joined #zuul | 02:47 | |
| *** threestrands has quit IRC | 02:47 | |
| *** threestrands has joined #zuul | 02:47 | |
| *** threestrands has quit IRC | 02:48 | |
| *** threestrands has joined #zuul | 02:49 | |
| *** threestrands has quit IRC | 02:49 | |
| *** threestrands has joined #zuul | 02:49 | |
| *** JasonCL has joined #zuul | 02:56 | |
| *** JasonCL has quit IRC | 03:00 | |
| openstackgerrit | Ian Wienand proposed openstack-infra/nodepool master: Add a backoff for failed builds https://review.openstack.org/558686 | 03:21 |
| openstackgerrit | Ian Wienand proposed openstack-infra/nodepool master: Add a backoff for failed builds https://review.openstack.org/558686 | 04:06 |
| *** JasonCL has joined #zuul | 04:21 | |
| *** JasonCL has quit IRC | 04:26 | |
| *** threestrands has quit IRC | 04:38 | |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul master: mqtt: add basic reporter https://review.openstack.org/535543 | 04:40 |
| *** dtruong2 has joined #zuul | 05:08 | |
| *** dtruong2 has quit IRC | 05:10 | |
| *** harlowja has joined #zuul | 05:16 | |
| *** harlowja has quit IRC | 05:20 | |
| *** hashar has joined #zuul | 06:13 | |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Move tmpdir into work root https://review.openstack.org/546698 | 06:55 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Update to Ansible 2.4 https://review.openstack.org/535781 | 06:56 |
| *** sc68cal has joined #zuul | 07:03 | |
| *** sc68cal- has quit IRC | 07:04 | |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: DNM: tmpdir test https://review.openstack.org/558719 | 07:12 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: DNM: tmpdir test https://review.openstack.org/558719 | 07:30 |
| *** electrofelix has joined #zuul | 07:39 | |
| *** jpena|off is now known as jpena | 07:46 | |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Move tmpdir into work root https://review.openstack.org/546698 | 07:56 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Update to Ansible 2.4 https://review.openstack.org/535781 | 07:58 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Disable action and lookup plugins from 2.4 https://review.openstack.org/535839 | 07:58 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: DNM: tmpdir test https://review.openstack.org/558736 | 08:15 |
| *** AJaeger has joined #zuul | 08:18 | |
| *** dtruong_ has joined #zuul | 10:05 | |
| *** colettecello has joined #zuul | 10:11 | |
| *** aluria` has joined #zuul | 10:12 | |
| *** mhu` has joined #zuul | 10:14 | |
| *** weshay_ has joined #zuul | 10:14 | |
| *** gothicmindfood has quit IRC | 10:15 | |
| *** dtruong has quit IRC | 10:15 | |
| *** weshay has quit IRC | 10:15 | |
| *** mhu has quit IRC | 10:15 | |
| *** dmsimard has quit IRC | 10:15 | |
| *** aluria has quit IRC | 10:15 | |
| *** aluria` is now known as aluria | 10:16 | |
| *** aluria has quit IRC | 10:16 | |
| *** aluria has joined #zuul | 10:16 | |
| *** dmsimard has joined #zuul | 10:18 | |
| *** mhu` has quit IRC | 10:28 | |
| *** mhu` has joined #zuul | 10:28 | |
| *** weshay_ has quit IRC | 10:28 | |
| *** weshay_ has joined #zuul | 10:28 | |
| *** JasonCL has joined #zuul | 10:33 | |
| *** JasonCL has quit IRC | 10:39 | |
| *** JasonCL has joined #zuul | 10:47 | |
| *** JasonCL has quit IRC | 11:06 | |
| *** jpena is now known as jpena|lunch | 11:53 | |
| *** JasonCL has joined #zuul | 12:10 | |
| *** odyssey4me has quit IRC | 12:23 | |
| *** odyssey4me has joined #zuul | 12:23 | |
| *** snapiri- has joined #zuul | 12:38 | |
| openstackgerrit | David Shrewsbury proposed openstack-infra/zuul master: Add static driver doc to Zuul From Scratch https://review.openstack.org/558802 | 12:38 |
| *** jpena|lunch is now known as jpena | 12:53 | |
| *** weshay_ is now known as weshay | 13:06 | |
| *** elyezer_ has joined #zuul | 13:12 | |
| *** pwhalen has joined #zuul | 13:15 | |
| *** pwhalen has joined #zuul | 13:15 | |
| *** elyezer has quit IRC | 13:16 | |
| *** yolanda_ has joined #zuul | 13:22 | |
| *** yolanda has quit IRC | 13:24 | |
| *** SotK has quit IRC | 13:25 | |
| *** hashar is now known as hasharAway | 13:25 | |
| *** dkranz has joined #zuul | 13:32 | |
| *** SotK has joined #zuul | 13:33 | |
| *** mugsie_ is now known as mugsie | 13:35 | |
| *** mugsie has quit IRC | 13:36 | |
| *** mugsie has joined #zuul | 13:36 | |
| openstackgerrit | David Shrewsbury proposed openstack-infra/zuul master: Add sample systemd service files. https://review.openstack.org/558830 | 14:01 |
| *** gouthamr has joined #zuul | 14:02 | |
| Shrews | corvus: i think i now have all of the content i wanted in docs up in reviews, as well as your suggestions (ending with 558830). We can now debate the content. Anyone can feel free to post new patchsets to help (I suck at docs, as established long ago). | 14:03 |
| dmsimard | I created a story with a shitty mockup for the idea I mentioned last night regarding live ara reports during job execution https://storyboard.openstack.org/#!/story/2001782 | 14:25 |
| *** maeca has joined #zuul | 14:31 | |
| *** maeca has quit IRC | 14:31 | |
| *** snapiri- has quit IRC | 14:40 | |
| sshnaidm | when I run zuul-cloner from command line, I got an error: TypeError: __init__() missing 2 required positional arguments: 'speed_limit' and 'speed_time' - how can I set them? | 15:05 |
| *** rcarrillocruz has quit IRC | 15:05 | |
| *** rcarrillocruz has joined #zuul | 15:08 | |
| tristanC | sshnaidm: this is being discussed on https://review.openstack.org/#/c/557826/ | 15:08 |
| sshnaidm | tristanC, thanks | 15:10 |
| sshnaidm | I wonder how it works here: http://logs.openstack.org/86/558786/1/check/tripleo-ci-centos-7-containers-multinode/027d645/job-output.txt.gz#_2018-04-04_11_51_21_628623 | 15:17 |
| sshnaidm | different version..? | 15:18 |
| pabelanger | it is using the fetch-zuul-cloner roles: http://git.openstack.org/cgit/openstack-infra/zuul-jobs/tree/roles/fetch-zuul-cloner | 15:18 |
| pabelanger | a shim that Shrews wrote | 15:18 |
| pabelanger | but, we are planning on removing that from base jobs in the near future, since that is no longer needed with zuul 3.0 | 15:19 |
| clarkb | sshnaidm: yes see my comment on that change. I expect you are installing the version 2 zuul cloner which is correct I think | 15:20 |
| clarkb | version 3 has no testing of the tool and we don't use it anymore so I hesitate trying to continue to support it there instead of removing it and pointing at version 2 if you need to tool. But corvus probably has a plan for this in mind | 15:20 |
| clarkb | oh pabelanger points out it is the shim that works too | 15:20 |
| clarkb | in any case the code being modified doesn't work it isn't tested and isn't used upstream. Better to use the version that was used and tested | 15:21 |
| clarkb | (if you need it) | 15:21 |
| sshnaidm | I'm trying to workaround zuul issue, when it's not capable to clone dependency from different branch. For example I have patch to "tripleo-ci" master branch which has dependency on "tripleo-upgrade" repo queens patch. Zuul fails to install this dependency | 15:26 |
| sshnaidm | pabelanger, ^^ any ideas..? | 15:26 |
| corvus | oh yeah, we should have removed the cloner command before the v3 release. that was an oversight. :) | 15:26 |
| sshnaidm | that's why I'm trying to clone this dependency manually with zuul-cloner | 15:27 |
| pabelanger | sshnaidm: is this for zuul.o.o or in RDO? | 15:28 |
| corvus | sshnaidm: in zuul v3, zuul should prepare all the repos, so the cloner isn't needed. there is a shim provided to handle jobs which haven't been rewritten for v3 yet: https://zuul-ci.org/docs/zuul-jobs/roles.html#role-fetch-zuul-cloner | 15:28 |
| sshnaidm | pabelanger, for both, but rdo is higher priority | 15:29 |
| sshnaidm | corvus, please see my message above about zuul issue | 15:29 |
| corvus | sshnaidm: rdo is v2, right? if so, install the cloner command from v2. | 15:29 |
| corvus | sshnaidm: show me where v3 isn't doing the right thing. | 15:29 |
| pabelanger | yah, it is likely the DIB images are not capped to use <3.0 of zuul | 15:29 |
| pabelanger | for RDO | 15:30 |
| sshnaidm | corvus, https://review.openstack.org/#/c/558189/ in this patch tripleo-upgrade is cloned from master branch, not from dependency | 15:32 |
| sshnaidm | pabelanger, what do you mean? | 15:32 |
| corvus | sshnaidm: what job should we look at? | 15:33 |
| sshnaidm | corvus, for example: http://logs.openstack.org/89/558189/6/check/tripleo-ci-centos-7-containers-multinode/fc3489f/ it uses zuulv3 | 15:34 |
| corvus | sshnaidm: that change is to the master branch, so zuul will check out the master branch of all projects by default | 15:37 |
| pabelanger | sshnaidm: before we would create the /usr/zuul-env at image build time with nodepool-builder, it is likely what the RDO project is still doing. If so, you want to update that element to cap zuul<3.0 to fix the exception. We no longer do this in openstack and use the fetch-zuul-cloner role that corvus linked | 15:39 |
| sshnaidm | corvus, that's exactly the problem :) | 15:39 |
| corvus | sshnaidm: i need you to articulate what you want to happen a bit more if you want me to help you | 15:40 |
| sshnaidm | corvus, I'd expect tripleo-upgrade repo to be cloned according to: ZUUL_CHANGES="openstack/tripleo-upgrade:stable/queens:refs/changes/99/558199/1^openstack-infra/tripleo-ci:master:refs/changes/89/558189/6" | 15:40 |
| sshnaidm | corvus, queens branch with ref refs/changes/99/558199/1 | 15:41 |
| sshnaidm | corvus, like it's set in dependencies | 15:41 |
| *** dtruong_ has quit IRC | 15:41 | |
| *** dtruong has joined #zuul | 15:42 | |
| corvus | sshnaidm: dependencies can be on any branch and don't affect the branch which is checked out. those jobs are all written to operate on "the branch being tested". in the case you linked, the branch was "master" because that's the change being tested. however, if you look at the dependent change, when the jobs run on that change, the branch being tested is "queens", and so the queens branch of | 15:43 |
| corvus | tripleo-upgrade is checked out in that case. | 15:43 |
| corvus | sshnaidm: fwiw, zuul-cloner behaved the same way. | 15:43 |
| corvus | sshnaidm: you can see that in action here: this is a job that ran on 558199: http://logs.openstack.org/99/558199/1/check/openstack-tox-linters/73ba9f6/zuul-info/inventory.yaml | 15:44 |
| sshnaidm | corvus, I understand the current behavior, I just say that I have a different expectations for it. And I don't think I expect something weird | 15:44 |
| corvus | sshnaidm: if you look at the bottom of that, you can see it checked out stable/queens there | 15:44 |
| sshnaidm | corvus, so you say it's in src/git.openstack.org/openstack/tripleo-upgrade with queens branch and changed applied? | 15:45 |
| corvus | sshnaidm: on 558199, tripelo-upgrade is checked out on the queens branch because it's a queens change. on 558189 tripleo-upgrade is checked out on the master branch because it's a master change. | 15:46 |
| sshnaidm | corvus, it's master change for tripleo-ci repo, but queens change for tripleo-upgrade repo | 15:47 |
| sshnaidm | corvus, different repos, where each one has different branch | 15:47 |
| sshnaidm | corvus, and I expected each repo to be cloned according to its branch, and not some default | 15:48 |
| corvus | sshnaidm: sure, but just because the change depends on a change in the queens branch, it doesn't follow that, when testing the master change, the dependent repo should be checked out on the queens branch. | 15:48 |
| corvus | sshnaidm: let's consider devstack for a moment. if a change to nova master happened to be behind a change to glance queens in the queue, it would be strange indeed for us to checkout nova master and glance queens and try to install them. they are not designed to work together. | 15:49 |
| sshnaidm | corvus, yeah, but we talk about CI code, where some repos have stable branches and some don't.. | 15:50 |
| sshnaidm | corvus, I agree it's a mess, but zuul could handle it I think | 15:50 |
| corvus | it's not a mess | 15:50 |
| corvus | sshnaidm: if a job needs to check out a specific branch of a repo, it can specify it needs that branch | 15:50 |
| sshnaidm | corvus, I mean cross-branch dependencies | 15:50 |
| corvus | sshnaidm: that's needed for certain kinds of jobs. for example, a job which is designed to run on queens no matter what (ie, a queens ugrade job) | 15:51 |
| corvus | sshnaidm: but most jobs are constructed to run on whatever branch is being tested | 15:51 |
| sshnaidm | corvus, but still, all repos will be cloned for queens, not one | 15:51 |
| *** acozine1 has joined #zuul | 15:51 | |
| corvus | sshnaidm: if you specify an override branch? it depends on how you do it. you can tell zuul to checkout queens on all projects, or just one. | 15:52 |
| sshnaidm | corvus, I wonder how can I specify override branch with dependencies | 15:52 |
| sshnaidm | corvus, it should check if I have dependency on this repo, calculate its branch and then override it | 15:53 |
| corvus | sshnaidm: what is it that you're ultimately trying to accomplish? | 15:53 |
| sshnaidm | corvus, in that patch I linked above I want on my host to be cloned: tripleo-ci repo with master change, tripleo-upgrade repo with queens change (from ZUUL_CHANGES) | 15:54 |
| corvus | sshnaidm: that's not what i'm asking. i'm asking what do you want to test? | 15:54 |
| sshnaidm | corvus, what do you mean..? | 15:54 |
| corvus | sshnaidm: i mean, let's pick a single job and describe what it is you want to do. | 15:55 |
| sshnaidm | corvus, I test tripleo, but how we test it is out of scope, it's like given situation | 15:55 |
| corvus | sshnaidm: are we still talking? | 15:58 |
| sshnaidm | corvus, I think so :) | 15:59 |
| sshnaidm | corvus, I gave an example: https://review.openstack.org/#/c/558189/ | 15:59 |
| corvus | sshnaidm: that's a change. i need you to pick a job from that change, and describe what the job is supposed to test. | 16:00 |
| sshnaidm | corvus, sure, it's for example: http://logs.openstack.org/89/558189/6/check/tripleo-ci-centos-7-containers-multinode/fc3489f/ | 16:00 |
| sshnaidm | corvus, it tests tripleo as I said | 16:00 |
| sshnaidm | corvus, if you want more details - tripleo-upgrade is ansible role, which I need to install in this job (from queens branch with change) | 16:01 |
| corvus | sshnaidm: does that job use that role? | 16:01 |
| sshnaidm | corvus, will use later | 16:02 |
| sshnaidm | corvus, for now I don't have it to install.. it's cloned from master | 16:02 |
| corvus | sshnaidm: if we ignore the dependency for a moment, and i just checked out master of all the repos and ran that job, should it work? | 16:03 |
| sshnaidm | corvus, the role installation part is not there yet, if you ask this | 16:04 |
| sshnaidm | corvus, it'll be like "pip install /path/to/repo/tripleo-upgrade" | 16:05 |
| sshnaidm | corvus, and I hoped to have it somewhere on the host.. | 16:05 |
| corvus | sshnaidm: what does tripleo-upgrade do? | 16:06 |
| sshnaidm | corvus, upgrades tripleo | 16:06 |
| corvus | sshnaidm: from what to what? | 16:07 |
| corvus | sshnaidm: like, if we checkout the master branch of tripleo-upgrade, what would the role do? upgrade from queens to master? upgrade from master to rocky? | 16:08 |
| corvus | or if it's easier, if we checkout the queens branch, what does it do? | 16:09 |
| sshnaidm | corvus, if we checkout queens branch, it will upgrade from queens to ... some target | 16:10 |
| *** elyezer_ has quit IRC | 16:10 | |
| corvus | sshnaidm: and the job, tripleo-ci-centos-7-containers-multinode, is that intended to perform this upgrade? | 16:11 |
| sshnaidm | corvus, no, this is just an example | 16:11 |
| corvus | sshnaidm: ah, well, the branch of a repo that's checked out is very much dependent on the job | 16:11 |
| corvus | sshnaidm: i think the underlying thing we're missing here is that what determines what gets checked out is not the dependency chain. it's the combination of the job and the change under test. | 16:12 |
| corvus | sshnaidm: so if you're building an upgrade job, you need to start by saying "what upgrade is this job going to test?" | 16:13 |
| *** elyezer_ has joined #zuul | 16:13 | |
| corvus | sshnaidm: for instance, if it's going to test an upgrade from queens to rocky, then it will need to check out the queens versions of things, install them, then checkout rocky, and perform the upgrade. the job should do that if it gets run on a change to queens, *or* if it gets run on a change to rocky (since both sides can affect an upgrade job) | 16:14 |
| corvus | sshnaidm: it's a very different process than constructing a job designed to run on any branch (which is what most jobs are) | 16:14 |
| corvus | sshnaidm: so the multinode job may very well be behaving exactly as it's supposed to (when it runs on a change to queens, it checks out queens; when it runs on a change to master, it checks out master). upgrade jobs just need to be constructed differently. | 16:15 |
| corvus | sshnaidm: let me expand on something i said a moment ago -- | 16:16 |
| sshnaidm | corvus, that's right, upgrade jobs use "override branch" usually | 16:16 |
| corvus | sshnaidm: what determines what gets checked out is not the dependency chain. it's the combination of the job and the change under test. the dependency chain holds the possible future state of all the repos. so if a job needs to check out queens, and there's a queens change in the dependency chain, the dependent change will be in the queens branch. but the fact that the change is in the dependency chain | 16:18 |
| corvus | doesn't automatically cause it to get checked out. it's the job that does that. and if the job doesn't specify anything specifically (via override-checkout), then it's the change under test that determines what gets checked out. | 16:18 |
| openstackgerrit | David Shrewsbury proposed openstack-infra/zuul master: Add Gerrit docs to Zuul From Scratch https://review.openstack.org/558600 | 16:19 |
| openstackgerrit | David Shrewsbury proposed openstack-infra/zuul master: Add static driver doc to Zuul From Scratch https://review.openstack.org/558802 | 16:19 |
| openstackgerrit | David Shrewsbury proposed openstack-infra/zuul master: Add sample systemd service files. https://review.openstack.org/558830 | 16:19 |
| openstackgerrit | David Shrewsbury proposed openstack-infra/zuul master: Move zuul jobs config to zuul config section https://review.openstack.org/558867 | 16:20 |
| sshnaidm | corvus, ok, I see.. seems like I need to review these dependencies chains again.. | 16:20 |
| *** elyezer_ has quit IRC | 16:24 | |
| dmsimard | corvus: random question -- I wonder if we could commission the foundation to work on a Zuul logo like they did with the OpenStack ones :) | 16:33 |
| dmsimard | Would be nice to have a logo/icon/favicon for Zuul | 16:33 |
| corvus | dmsimard: indeed! they just contacted me about starting to work on one. | 16:34 |
| dmsimard | huh, odd coincidence :D | 16:35 |
| corvus | that would have been a good thing to mention at the last meeting :) | 16:35 |
| dmsimard | zuul-discuss worthy perhaps | 16:35 |
| corvus | (well, very recently, not like, a minute ago :) | 16:35 |
| *** elyezer_ has joined #zuul | 16:36 | |
| pabelanger | spooky | 16:41 |
| *** acozine1 has quit IRC | 16:46 | |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: WIP: Check out more appropriate branches of role and playbook repos https://review.openstack.org/558643 | 16:46 |
| *** acozine1 has joined #zuul | 16:51 | |
| *** pwhalen has quit IRC | 17:03 | |
| *** Shrews has quit IRC | 17:06 | |
| *** Shrews has joined #zuul | 17:06 | |
| *** pwhalen has joined #zuul | 17:10 | |
| *** pwhalen has joined #zuul | 17:10 | |
| *** Shrews has quit IRC | 17:11 | |
| *** Shrews has joined #zuul | 17:11 | |
| *** jpena is now known as jpena|off | 17:19 | |
| *** gouthamr has quit IRC | 17:24 | |
| pabelanger | corvus: tristanC: mordred: so, it seems native fedmsg support in zuul might not be something we want to do. Talking with #fedora-admin it seems fedora maybe in the the process of migrating away from it. So, given that we seemed okay to support both mqtt / fedmsg drivers in zuul, maybe we just do mqtt directly and stand up external fedmsg infra is we still want to go down that path. | 17:25 |
| pabelanger | also seems debian is no longer using fedmsg either, according to #fedora-admin | 17:26 |
| clarkb | pabelanger: do we know what their reasons are/were? additionally is fedora using it the only reason we'd use it? | 17:26 |
| mordred | pabelanger: that's good information. if debian is no longer using it and fedora may be moving away from it, it doesn't seem like a good thing for us to add support for | 17:27 |
| mordred | clarkb: I think the reason we were drawn to it originally is that it was a bus that existed that both fedora and debian already use | 17:27 |
| clarkb | I ask because this was a major topic at the cross ci event and it seemed like a tool like fedmsg would solve that nicely | 17:27 |
| clarkb | so understanding why people may not want to continue using it and determining if it is still valid for a different use case would be helpful | 17:28 |
| mordred | clarkb: I believe one of the concerns that has been expressed about fedmsg is that it doesn't allow subscribing to a specific topic - all filtering of messages isdone client-side | 17:28 |
| clarkb | ah | 17:28 |
| clarkb | something that mqtt solves nicely | 17:28 |
| mordred | clarkb: which is one of the reasons firehose uses mqtt - so that a client can only subscribe to a subset of events | 17:28 |
| mordred | yup | 17:28 |
| clarkb | fwiw the big draw for me personally was the ease of setup and somewhat structured data | 17:29 |
| clarkb | but mqtt is fairly easy to setup and use and we can address the structured data problem if we agree on some common fields and practices | 17:29 |
| pabelanger | clarkb: I get the impression there isn't many active developers on fedmsg any more, so rather then keeping a stack of libraries working (eg: python3) they might just use ZMQ libraries directly | 17:29 |
| clarkb | pabelanger: that seems like the completely wrong direction to take based on our experience of using zmq directly :) | 17:30 |
| pabelanger | They do seem open to the idea of adding mqtt support into fedmsg, but I'm unsure if we as zuul want to recommend using it, if project is lacking developers | 17:30 |
| clarkb | pabelanger: but not our decision to make :) | 17:30 |
| pabelanger | yah | 17:31 |
| pabelanger | but since it was an important topic for ci meet up, I don't want to say not use it. But maybe we need to re-evaluate it | 17:32 |
| pabelanger | and spend some development effort updating it for python3 if needed | 17:32 |
| clarkb | considering that we would wanted to update fedmsg to mqtt anyways I'm personally happy to just mqtt | 17:33 |
| pabelanger | yah, the main interested for me, was some of the fedmsg tooling we'd get. Eg: fancy JS library or desktop app to subscribe to things | 17:34 |
| pabelanger | but using mqtt directly seems just as good too | 17:34 |
| *** Diabelko has quit IRC | 17:38 | |
| Shrews | I asked LinuxJedi how his zuul demo went earlier. Since I hadn't heard back, I'm assuming that it went SO well that they immediately dragged him out for some extreme vodka drinking. :) | 17:44 |
| Shrews | I hear that do that kind of thing in Finland | 17:45 |
| *** gouthamr has joined #zuul | 17:45 | |
| pabelanger | Ha | 17:45 |
| *** electrofelix has quit IRC | 17:47 | |
| *** Diabelko has joined #zuul | 18:13 | |
| LinuxJedi | Shrews: close, currently having food and wine 🙂. I’ll fill you in when I get back to the hotel later. | 18:13 |
| LinuxJedi | Vodka is tomorrow | 18:14 |
| Shrews | w00t | 18:14 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: WIP: Check out more appropriate branches of role and playbook repos https://review.openstack.org/558643 | 18:28 |
| corvus | andreaf, mordred: there's a surprising amount of subtle errors in the executor with respect to roles (and playbooks) on branches. i've been working on that ^ for most of the morning, and it will probably still take at least the rest of the day before it's finished. | 18:29 |
| mordred | corvus: nod | 18:31 |
| *** sshnaidm is now known as sshnaidm|afk | 18:51 | |
| *** hasharAway is now known as hashar | 19:07 | |
| *** harlowja has joined #zuul | 19:10 | |
| pabelanger | Hmm, are we still using /bin/kill -HUP $MAINPID to reload zuul service? I thought some of that was moved into commandsocket | 19:49 |
| *** gouthamr has quit IRC | 19:52 | |
| pabelanger | yah, seems only the scheduler. I could have thought we moved it into zuul-scheduler reload, I guess not | 19:57 |
| pabelanger | or | 19:57 |
| pabelanger | reconfigure | 19:57 |
| *** myoung is now known as myoung|mtg | 20:10 | |
| *** snapiri has quit IRC | 20:28 | |
| *** snapiri has joined #zuul | 20:30 | |
| *** snapiri has quit IRC | 20:33 | |
| *** snapiri has joined #zuul | 20:33 | |
| *** hashar has quit IRC | 20:48 | |
| *** myoung|mtg is now known as myoung | 21:03 | |
| *** acozine1 has quit IRC | 21:08 | |
| *** elyezer_ has quit IRC | 21:09 | |
| *** elyezer_ has joined #zuul | 21:22 | |
| *** elyezer_ has quit IRC | 21:29 | |
| dmsimard | Just a heads up, there'll be a 0.15.0 release of ARA. 1.0 is still some ways off and there's some fairly easy backports which would be helpful to us and some other users -- especially performance related | 21:34 |
| dmsimard | mordred: ^ I've started working on a model for nested jobs in ARA's gate, I'll try and see if I can leverage what you did for the functional zuul_stream job to get a nested zuul or something | 21:35 |
| dmsimard | I'm fairly certain there's nothing to change in our current implementation -- there'll be a sqlite middleware update but that's on the log server and backwards compatible | 21:36 |
| *** elyezer_ has joined #zuul | 21:41 | |
| mordred | dmsimard: neat | 21:43 |
| *** dkranz has quit IRC | 21:44 | |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: WIP: Check out more appropriate branches of role and playbook repos https://review.openstack.org/558643 | 22:43 |
| corvus | andreaf, mordred, clarkb, tobiash: ^ that's getting pretty close to ready -- enough that it may be worth a look to familiarize yourself with it. i suspect i'll be ready to talk about it tomorrow. | 22:49 |
| clarkb | corvus: a roles project is any project that defiens a role? | 22:54 |
| corvus | clarkb: it's a project that's listed in the 'roles' attribute of a job | 22:54 |
| clarkb | aha | 22:55 |
| corvus | (though if it's listed there, it must define roles, or it's an error) | 22:55 |
| clarkb | corvus: and being listed in that manner is what sets the roles type to zuul I assume? | 22:55 |
| corvus | clarkb: that's specified too. it's like "roles: [{zuul: projectname}]" | 22:56 |
| corvus | clarkb: so that we can later have "roles: [{zuul: projectname, galaxy: otherrolename}]" | 22:57 |
| clarkb | cool I was just making sure that check against role type was coming from where I assumed it was given ^ | 22:57 |
| clarkb | sounds like it is | 22:57 |
| corvus | ah yep. if it's not a zuul role, it'll be a galaxy role, and none of this applies. but only zuul roles exist now. that's future proofing. | 22:58 |
| clarkb | skimming it the logic makes sense | 22:59 |
| corvus | cool. i'm going to sleep on it to give my brain a chance to come up with any other edge (or test) cases | 23:00 |
| clarkb | zuul isn't really happy with it currently but I'm assuming thats largely just needing cleanup | 23:01 |
| mordred | corvus: dude. I read the commit message and believe I understand the first time - good commit message! | 23:02 |
| corvus | clarkb: hopefully; the new test passes locally, i didn't run the whole thing. so either it's cleanup... or fundamental flaw. :) | 23:04 |
| corvus | (or, it could actually be a behavior change affecting other tests) | 23:04 |
| corvus | this very much could alter current jobs -- but if so, they should hopefully be easy to fix | 23:05 |
| clarkb | feature request can we put the job name and change number in the streaming console parameters list? the server can totally ignore them its just a nice cue to browser users for what they are looking at | 23:06 |
| clarkb | I can probably attempt to hack the js to do that if people are opposed | 23:06 |
| clarkb | (I assume the server side won't error if it gets params it doesn't know about but maybe it will) | 23:07 |
| corvus | clarkb: what if we put them at the top of the console output -- and maybe the title? | 23:07 |
| clarkb | corvus: that would probably work too. Though scrolling is also weird | 23:08 |
| clarkb | I'd volnteer to fix scrolling btu expect that is beyond my js abilities | 23:08 |
| corvus | clarkb: (i'm slightly resistant to adding them to the url on usability grounds -- it suggests a feature that isn't there) | 23:08 |
| clarkb | in particular if autoscroll is on even if you scroll up it will scroll back down (so not just auto scroll at bottom) and if you disable autoscroll I have a hard time scrolling down from the top | 23:08 |
| corvus | clarkb: setting <title> should help with the scrolling case | 23:08 |
| corvus | oh yeah, i've noticed that too | 23:09 |
| clarkb | but ya generally putting it in a title would probably work | 23:10 |
| mordred | clarkb, corvus: I've got a streaming rework patch up | 23:11 |
| mordred | clarkb, corvus: so if you do decide to try to poke at things, you might want to do it on top of that | 23:11 |
| corvus | ++ | 23:11 |
| mordred | https://review.openstack.org/#/c/558646/ ftr | 23:12 |
| *** acozine1 has joined #zuul | 23:58 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
