*** sdake has joined #zuul | 00:47 | |
*** sdake has quit IRC | 01:03 | |
*** sdake has joined #zuul | 01:07 | |
*** threestrands has joined #zuul | 01:10 | |
*** sdake has quit IRC | 01:19 | |
*** bhavikdbavishi has joined #zuul | 01:28 | |
*** threestrands has quit IRC | 01:35 | |
*** jamesmcarthur has joined #zuul | 02:17 | |
*** bhavikdbavishi has quit IRC | 02:50 | |
*** jamesmcarthur has quit IRC | 02:59 | |
*** jamesmcarthur has joined #zuul | 03:00 | |
*** sdake has joined #zuul | 03:02 | |
*** jamesmcarthur has quit IRC | 03:05 | |
*** jamesmcarthur has joined #zuul | 03:30 | |
openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul master: executor: add zuul_release_nodeset Ansible action https://review.openstack.org/639002 | 03:32 |
---|---|---|
*** sdake has quit IRC | 03:36 | |
*** jamesmcarthur has quit IRC | 03:36 | |
*** sdake has joined #zuul | 03:41 | |
*** jamesmcarthur has joined #zuul | 03:45 | |
*** jamesmcarthur has quit IRC | 03:51 | |
*** jamesmcarthur has joined #zuul | 03:53 | |
*** sdake has quit IRC | 03:56 | |
*** bhavikdbavishi has joined #zuul | 03:56 | |
*** jamesmcarthur has quit IRC | 04:09 | |
*** jamesmcarthur has joined #zuul | 04:12 | |
*** sdake has joined #zuul | 04:21 | |
*** spsurya has joined #zuul | 04:24 | |
*** sdake has quit IRC | 04:25 | |
*** sdake has joined #zuul | 04:28 | |
*** jamesmcarthur has quit IRC | 04:30 | |
*** sdake has quit IRC | 04:30 | |
*** sdake has joined #zuul | 04:31 | |
*** jamesmcarthur has joined #zuul | 04:31 | |
*** sdake has quit IRC | 04:35 | |
*** sdake has joined #zuul | 04:37 | |
*** sdake has quit IRC | 04:40 | |
*** sdake has joined #zuul | 04:43 | |
*** sdake has quit IRC | 04:45 | |
*** sdake has joined #zuul | 04:46 | |
*** sdake has quit IRC | 04:48 | |
*** sdake has joined #zuul | 04:51 | |
*** sdake has quit IRC | 04:55 | |
*** sdake has joined #zuul | 04:56 | |
*** sdake has quit IRC | 05:00 | |
*** sdake has joined #zuul | 05:02 | |
*** jamesmcarthur has quit IRC | 05:05 | |
*** sdake has quit IRC | 05:10 | |
*** sdake_ has joined #zuul | 05:11 | |
*** bhavikdbavishi has quit IRC | 05:12 | |
*** bhavikdbavishi has joined #zuul | 05:13 | |
*** sdake_ has quit IRC | 05:15 | |
*** sdake has joined #zuul | 05:18 | |
*** sdake has quit IRC | 05:21 | |
*** sdake has joined #zuul | 05:22 | |
*** sdake has quit IRC | 05:26 | |
*** sdake has joined #zuul | 05:28 | |
*** sdake has quit IRC | 05:30 | |
*** sdake_ has joined #zuul | 05:33 | |
*** jamesmcarthur has joined #zuul | 05:35 | |
*** sdake_ has quit IRC | 05:35 | |
*** sdake has joined #zuul | 05:36 | |
openstackgerrit | Tristan Cacqueray proposed openstack-infra/nodepool master: Add python-path option to label https://review.openstack.org/637338 | 05:37 |
openstackgerrit | Ian Wienand proposed openstack-infra/nodepool master: [dnm] testing rhel8 images https://review.openstack.org/639013 | 05:39 |
*** jamesmcarthur has quit IRC | 05:40 | |
*** pradyunsg has joined #zuul | 05:43 | |
*** sdake has quit IRC | 05:45 | |
pradyunsg | Hi all! Is there any way to detect if a program is being run in a Zuul job? | 05:45 |
*** bhavikdbavishi has quit IRC | 05:45 | |
*** saneax has joined #zuul | 05:48 | |
pradyunsg | context: I'm working with a team, where we're looking to collect metrics automated vs organic invocations of a CLI application. Does Zuul export any environment variables in the execution environment? | 05:48 |
pradyunsg | (like: https://docs.travis-ci.com/user/environment-variables/#default-environment-variables) | 05:48 |
*** sdake has joined #zuul | 05:48 | |
*** sdake has quit IRC | 05:51 | |
*** sdake has joined #zuul | 05:52 | |
*** sdake has quit IRC | 05:55 | |
*** sdake has joined #zuul | 05:58 | |
*** sdake has quit IRC | 06:00 | |
*** sdake has joined #zuul | 06:01 | |
*** bjackman has joined #zuul | 06:05 | |
*** sdake has quit IRC | 06:06 | |
*** sdake_ has joined #zuul | 06:08 | |
*** sdake_ has quit IRC | 06:10 | |
*** jamesmcarthur has joined #zuul | 06:11 | |
*** jamesmcarthur has quit IRC | 06:16 | |
*** chandankumar has quit IRC | 06:39 | |
*** chandankumar has joined #zuul | 06:40 | |
*** quiquell|off is now known as quiquell | 06:48 | |
*** jamesmcarthur has joined #zuul | 06:53 | |
*** jamesmcarthur has quit IRC | 06:58 | |
*** bjackman_ has joined #zuul | 07:03 | |
*** bjackman has quit IRC | 07:04 | |
*** AJaeger has quit IRC | 07:05 | |
*** bjackman has joined #zuul | 07:06 | |
*** bjackman_ has quit IRC | 07:07 | |
*** AJaeger has joined #zuul | 07:24 | |
*** bhavikdbavishi has joined #zuul | 07:30 | |
*** jamesmcarthur has joined #zuul | 07:33 | |
openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul master: Add depends-on support to frozen jobs API https://review.openstack.org/639022 | 07:35 |
tristanC | jhesketh: ^ should be the zuul-runner depends on implementation server side, should i rebase the rest of the patches on this? | 07:36 |
tristanC | corvus: could you please review topic:freeze_job | 07:37 |
*** jamesmcarthur has quit IRC | 07:37 | |
*** gtema has joined #zuul | 07:37 | |
openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Fix missing semaphore release around dequeue https://review.openstack.org/639023 | 07:46 |
tobiash | zuul-maint: this fixes a semaphore leak we're seeing so I think that's an important bugfix ^ | 07:50 |
jhesketh | tristanC: I haven't looked closely, but it could be an independent commit before the depends-on support in the cli rather than reworking it all | 07:51 |
*** bhavikdbavishi has quit IRC | 07:54 | |
tristanC | jhesketh: alright that can wait. would be nice to land the changes that mostly move code around | 08:01 |
jhesketh | agreed :-) | 08:01 |
*** takamatsu_ has quit IRC | 08:19 | |
*** takamatsu_ has joined #zuul | 08:21 | |
*** bhavikdbavishi has joined #zuul | 08:23 | |
*** electrofelix has joined #zuul | 08:31 | |
*** quiquell is now known as quiquell|brb | 08:31 | |
*** takamatsu_ has quit IRC | 08:32 | |
*** jamesmcarthur has joined #zuul | 08:33 | |
*** zbr|ssbarnea has joined #zuul | 08:34 | |
*** jamesmcarthur has quit IRC | 08:38 | |
*** takamatsu_ has joined #zuul | 08:38 | |
*** jpena|off is now known as jpena | 08:48 | |
*** hashar has joined #zuul | 09:00 | |
*** bjackman has quit IRC | 09:05 | |
*** quiquell|brb is now known as quiquell | 09:07 | |
*** bjackman has joined #zuul | 09:09 | |
*** jamesmcarthur has joined #zuul | 09:10 | |
*** zbr|ssbarnea is now known as zbr|out | 09:13 | |
*** jamesmcarthur has quit IRC | 09:14 | |
*** bjackman has quit IRC | 09:20 | |
*** bjackman has joined #zuul | 09:26 | |
*** jamesmcarthur has joined #zuul | 09:49 | |
*** jamesmcarthur has quit IRC | 09:54 | |
*** jamesmcarthur has joined #zuul | 09:59 | |
*** gtema has quit IRC | 10:05 | |
*** sshnaidm|off is now known as sshnaidm | 10:05 | |
*** gtema has joined #zuul | 10:39 | |
*** jamesmcarthur has quit IRC | 10:50 | |
*** gtema has quit IRC | 11:22 | |
quiquell | tristanC: o/ Do you know if there are any way to connect nodepool to ironic to run on baremetal ? | 11:22 |
*** snapiri has quit IRC | 11:23 | |
*** hashar has quit IRC | 11:24 | |
*** bhavikdbavishi has quit IRC | 11:27 | |
*** hashar has joined #zuul | 11:27 | |
tristanC | quiquell: through cloud label flavor? | 11:29 |
*** bjackman_ has joined #zuul | 11:31 | |
quiquell | tristanC: well there is not much flavor you can choose at BM | 11:31 |
quiquell | tristanC: Don't really know | 11:31 |
*** bjackman has quit IRC | 11:34 | |
tristanC | quiquell: iirc that's how you use ironic with nodepool, you associate some flavor with BM, then nodepool should be able to use them | 11:34 |
*** gtema has joined #zuul | 11:34 | |
quiquell | tristanC: that's all ? | 11:35 |
quiquell | tristanC: is not nodepool openstack provider only talking nova ? | 11:35 |
quiquell | tristanC: Ahh ok nodepool->nova->ironic was thinking about just nova Thanks! | 11:38 |
quiquell | tristanC: something like this ? https://docs.openstack.org/ironic/pike/install/configure-nova-flavors.html | 11:42 |
*** saneax has quit IRC | 11:42 | |
*** saneax has joined #zuul | 11:43 | |
*** sdake has joined #zuul | 11:45 | |
tristanC | quiquell: i guess, never used it though | 11:46 |
quiquell | ok we will look thanks mate | 11:47 |
*** hashar has quit IRC | 11:48 | |
*** sdake has quit IRC | 11:50 | |
*** sdake has joined #zuul | 11:51 | |
*** sdake has quit IRC | 11:55 | |
*** sdake has joined #zuul | 11:57 | |
*** sdake has quit IRC | 12:00 | |
*** panda|ruck is now known as panda|ruck|lunch | 12:02 | |
*** jamesmcarthur has joined #zuul | 12:02 | |
*** hashar has joined #zuul | 12:07 | |
*** jamesmcarthur has quit IRC | 12:08 | |
*** quiquell is now known as quiquell|lunch | 12:13 | |
*** jamesmcarthur has joined #zuul | 12:13 | |
*** saneax has quit IRC | 12:17 | |
*** jamesmcarthur has quit IRC | 12:19 | |
*** jamesmcarthur has joined #zuul | 12:22 | |
*** quiquell|lunch is now known as quiquell | 12:28 | |
*** jpena is now known as jpena|lunch | 12:31 | |
*** bhavikdbavishi has joined #zuul | 12:33 | |
*** jamesmcarthur has quit IRC | 12:43 | |
*** electrofelix has quit IRC | 12:44 | |
*** jamesmcarthur has joined #zuul | 12:53 | |
*** bjackman_ has quit IRC | 13:01 | |
*** jamesmcarthur has quit IRC | 13:01 | |
*** jamesmcarthur has joined #zuul | 13:05 | |
*** jamesmcarthur has quit IRC | 13:10 | |
*** rlandy has joined #zuul | 13:15 | |
sshnaidm | is there any docs about how to write plugin to nodepool? | 13:15 |
*** jamesmcarthur has joined #zuul | 13:18 | |
*** bhavikdbavishi has quit IRC | 13:22 | |
*** panda|ruck|lunch is now known as panda|ruck | 13:26 | |
*** jpena|lunch is now known as jpena | 13:28 | |
*** jamesmcarthur has quit IRC | 13:29 | |
*** snapiri has joined #zuul | 13:37 | |
*** saneax has joined #zuul | 13:45 | |
tristanC | sshnaidm: not yet, though i was going to write one soon related to this story: https://tree.taiga.io/project/morucci-software-factory/us/2315 | 13:48 |
*** jamesmcarthur has joined #zuul | 13:50 | |
*** saneax has quit IRC | 13:55 | |
pabelanger | quiquell: there are humans doing baremetal testing on nodepool via nova / ironic. | 13:58 |
quiquell | pabelanger: that's cool, can we reach them ? | 14:00 |
pabelanger | sorry, reach who? | 14:01 |
quiquell | humans doing baremetal testing on nodepool | 14:03 |
pabelanger | I can't remember who it was atm, maybe clarkb does. I know they posted on openstack ML a while back | 14:07 |
pabelanger | I know ovh has some baremetal, pretty sure that is behind nova | 14:07 |
*** jamesmcarthur has quit IRC | 14:08 | |
quiquell | pabelanger: Let's see were our experiments end with this | 14:08 |
quiquell | pabelanger: Thanks ! | 14:08 |
*** pwhalen has joined #zuul | 14:14 | |
*** jamesmcarthur has joined #zuul | 14:25 | |
*** gtema has quit IRC | 14:37 | |
*** jesusaur has quit IRC | 14:42 | |
*** jesusaur has joined #zuul | 14:47 | |
AJaeger | corvus, Zuul experts, can we really define a job twice with different branches lines? Please review https://review.openstack.org/#/c/639096/3/zuul.d/jobs.yaml | 14:48 |
tobiash | AJaeger: that will be merged into one job because the branches are the same | 14:55 |
tobiash | AJaeger: if the intention is to have two jobs and also run two jobs then they must be named different | 14:55 |
*** bhavikdbavishi has joined #zuul | 14:55 | |
openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Fix rare semaphore leak during reconfiguration https://review.openstack.org/639118 | 14:57 |
AJaeger | tobiash: it's two abstract jobs - and then in-repo jobs that should inherit from the right one. Will that work? | 14:58 |
tobiash | no, both will match | 14:58 |
tobiash | they filter basically on the same branches | 14:58 |
AJaeger | tobiash: really? could you comment. Will answer later, now in a call... | 15:00 |
tobiash | AJaeger: oh no, sorry I read the regex wrong | 15:01 |
tobiash | as long as the regexes don't overlap that should work | 15:01 |
tobiash | sorry | 15:01 |
*** josefwells has joined #zuul | 15:09 | |
openstackgerrit | Merged openstack/pbrx master: Remove container build jobs https://review.openstack.org/636019 | 15:18 |
*** bhavikdbavishi has quit IRC | 15:31 | |
AJaeger | tobiash: cool - thanks | 15:34 |
*** chandankumar is now known as raukadah | 15:51 | |
openstackgerrit | Merged openstack-infra/zuul master: config: add playbooks to job.toDict() https://review.openstack.org/621343 | 15:52 |
*** bhavikdbavishi has joined #zuul | 15:57 | |
jkt | it seems that I'm struggling with that difference of playbook-vs-role yet again | 16:00 |
jkt | I have a bunch of Ansible tasks in a shared repo, these tasks prepare git submodules | 16:00 |
jkt | how do I use that feature from within other repositories? | 16:00 |
jkt | so far I've added another job called, say, "build-with-submodules" in the $company-jobs repo, that job inherits from my generic "build" job | 16:01 |
jkt | now I'm trying to work on artifacts to be returned, so I'm about to reshuffle the jobs definitions, and it seems that I should have made my "prepare git submodules" a role, not a playbook to be run in pre-run | 16:02 |
jkt | but when I add `pre-run: playbooks/git-submodules/pre.yaml` into my leaf project, along with `roles:\n - zuul: git-submodules`, zuul complains that it cannot find that playbook | 16:04 |
*** jamesmcarthur_ has joined #zuul | 16:06 | |
jkt | ah, right, this is actually much simpler -- the roles are not "prepared" for consumption by playbooks as the docs imply | 16:06 |
*** jamesmcarthur has quit IRC | 16:08 | |
jkt | ok, they are not :), apparently they *are* only prepared | 16:11 |
corvus | tristanC: i left exactly the same comments on PS 11 of https://review.openstack.org/607077 that tobias did on PS 7. | 16:29 |
corvus | jkt: a "zuul role" is the name of a project that either has one role or a collection of roles. so you should list the name of whatever project has the "prepare git submodules" role | 16:32 |
jkt | corvus: but the root dir of the project should always have either "tasks/" subdir, or "role/$name/tasks", right? | 16:37 |
corvus | jkt: "tasks/" or "roles/" | 16:37 |
jkt | corvus: also, it seems that I have to write my own playbook which refers to that role in another repo, and there's no way to refer to playbooks in another repo except by job inheritance, right? | 16:38 |
*** takamatsu_ has quit IRC | 16:39 | |
corvus | jkt: right, the ansible construct for code re-use is roles, so zuul is designed accordingly. they're working on reusable playbooks, but i don't think it's there yet. | 16:39 |
jkt | perhaps I'm doing it wrong (wouldn't be the first time), but my end goal is not producing nice ansible playbooks, my goal is a nice CI :), and this feels like a lot of boilerplate code | 16:41 |
*** takamatsu_ has joined #zuul | 16:41 | |
jkt | if my .zuul.yaml could reference roles directly, without adding them to a playbook first, now that would be nice | 16:41 |
jkt | I understand that there are multinode jobs etc etc, but it's a learning curve | 16:41 |
corvus | jkt: if you can show me what you're working on, i'd be happy to take a look and see if there's an easier way. | 16:42 |
jkt | thanks! | 16:42 |
jkt | corvus: this is about building random C++ code, and that thing requires a lot of handholding, so we have a file in our repos, ci/build.sh, which sets up whatever build system in whatever way it needs to be set up (think different Python versions, and a set of additional orthogonal parameter such as build-vs-release etc) | 16:44 |
*** raukadah is now known as chandankumar | 16:44 | |
jkt | some of that build system setup is typically done by exporting env variables in response to debug vs. release builds, whether to use some, er, compiler plugins as as ASAN, UBSAN etc | 16:45 |
jkt | but in the end, I think I need just one playbook, something which runs ./ci/build.sh from within a repo | 16:45 |
*** takamatsu_ has quit IRC | 16:45 | |
corvus | jkt: the thing we try to do with zuul-jobs is put all of the logic in roles, and playbooks are just there to orchestrate and coordinate those roles. so we end up with playbooks that are usually very short (sometimes one-line) lists of roles. | 16:45 |
jkt | some projects have external dependencies that I cannot gate and which have funny ideas about backward compatibility, and for these we're using git submodules | 16:45 |
jkt | exactly, and this looks like an extra indirection to me | 16:46 |
jkt | I realize that it's probably native to someone who is used to Ansible, true, though | 16:46 |
jkt | so, some of our projects essentially want to run `git submodule init`, so I added a role for that (and with fixes to make it work in Zuul) | 16:47 |
jkt | how do I specify whether a project needs to prep the submodules or not? | 16:47 |
jkt | so far, I've used two jobs, one which just has a run: playbook that includes a role which runs ./ci/build.sh | 16:47 |
jkt | the other job inherits from that, adding a pre-run that prepares submodules | 16:48 |
jkt | now I'm about to add artifact caching; do I need to add two more jobs? | 16:48 |
jkt | that looked like a wrong solution to me, so I went looking into moving stuff to roles instead, i.e. https://gerrit.cesnet.cz/plugins/gitiles//ci/zuul-jobs-cesnet/+/457fecff8ec887bccff1ae97eb555715a62f0bab | 16:49 |
jkt | that example should also show how I'm dumping the {{ zuul }} variable for use in shell, that's nicely done in these roles | 16:49 |
*** hashar has quit IRC | 16:50 | |
jkt | but the TL;DR is that my leaf repo now has to carry a super-simple pre-run playbook which just references the git-submodules role in there | 16:51 |
*** takamatsu_ has joined #zuul | 16:51 | |
corvus | why your leaf repo? you can declare that job centrally | 16:51 |
jkt | and whenever I'm adding a file which only adds another file, I cannot help but ask if this can be done in some less verbose way | 16:51 |
jkt | yup, I could define four jobs, as a 2x2 matrix (needs_submodules, provides_artifacts) | 16:52 |
jkt | what I am a bit afraid is that there will be another "variable" to be used, perhaps whether to use GCC or clang, and that would lead to a big number of job templates quite quickly | 16:53 |
corvus | jkt: you could use zuul variables | 16:53 |
corvus | jkt: which compiler to use sounds like a good thing to use a zuul variable for. just set that variable in the job and you don't need to make a new playbook | 16:54 |
jkt | corvus: so that I have just one job and two variables, one for whether to prepare submodules, the other for artifact caching, etc? | 16:54 |
corvus | jkt: you could do that as well | 16:55 |
jkt | corvus: how evil is it to parse the job name for compiler selection, btw? :) | 16:55 |
corvus | jkt: very | 16:55 |
corvus | jkt: and uneccessary -- it's less work to just set the variable in the job | 16:56 |
jkt | I need that variable to hit the process environment in the end (either it's CXX=g++, or CXX=clang++), and it's a bit awkward to use random ansible variables from my shell script | 16:57 |
jkt | but perhaps I could just pass this to build.sh from ansible, ah! | 16:58 |
corvus | ++ | 16:58 |
jkt | corvus: thanks a lot, now I have new bits to think about, that's good | 16:59 |
*** hashar has joined #zuul | 17:03 | |
*** takamatsu_ has quit IRC | 17:06 | |
*** takamatsu_ has joined #zuul | 17:07 | |
*** gtema has joined #zuul | 17:15 | |
*** takamatsu_ has quit IRC | 17:21 | |
*** takamatsu_ has joined #zuul | 17:22 | |
*** takamatsu_ has quit IRC | 17:25 | |
*** sdake has joined #zuul | 17:26 | |
*** takamatsu_ has joined #zuul | 17:31 | |
*** chandankumar is now known as raukadah | 17:32 | |
*** takamatsu_ has quit IRC | 17:46 | |
*** takamatsu_ has joined #zuul | 17:48 | |
jkt | are job artifacts supposed to work across tenants? I have a change that was built under tenant A, it is referenced by a job which runs within tenant B, there's a Depends-on: change_A, but I don't see any artifacts in zuul.* variables | 17:55 |
jkt | I also don't see them listed for the A's job in the web UI, not sure if they are supposed to show up in the human-readable build overview page | 17:56 |
*** gtema has quit IRC | 18:02 | |
*** takamatsu_ has quit IRC | 18:05 | |
*** sdake_ has joined #zuul | 18:06 | |
*** sdake has quit IRC | 18:07 | |
*** sdake_ has quit IRC | 18:10 | |
*** takamatsu_ has joined #zuul | 18:10 | |
*** sdake has joined #zuul | 18:11 | |
*** jpena is now known as jpena|off | 18:11 | |
*** takamatsu_ has quit IRC | 18:14 | |
*** sdake_ has joined #zuul | 18:15 | |
*** sdake has quit IRC | 18:16 | |
*** takamatsu_ has joined #zuul | 18:20 | |
*** sdake_ has quit IRC | 18:20 | |
*** hashar has quit IRC | 18:21 | |
*** sdake has joined #zuul | 18:22 | |
*** sdake has quit IRC | 18:26 | |
*** sdake_ has joined #zuul | 18:27 | |
corvus | jkt: i don't think artifacts are in the web ui yet (they will be). artifacts won't be shared across tenants -- tenants are *completely* separate in zuul. think of them as existing only to make it so that you don't have to run more than one zuul, but otherwise they behave almost exactly like that. | 18:30 |
jkt | corvus: if I have a repo which is supposed to provide artifacts for both tenant A and tenant B, that means that I have to built it twice, then, right? | 18:33 |
jkt | my use case is once again that C++ code, the dependencies are shared among public projects (tenant A) and company-internal projects (tentant B) | 18:33 |
jkt | I already have that common project present in both tenants -- in the public one as a regular project with active pipelines, and in the private one just as include: [] | 18:35 |
*** sdake_ has quit IRC | 18:35 | |
*** sdake has joined #zuul | 18:36 | |
*** sdake has quit IRC | 18:41 | |
*** sdake_ has joined #zuul | 18:41 | |
*** hashar has joined #zuul | 18:41 | |
corvus | jkt: yes. that's a use case i don't think we've thought much about. you can see the danger though: while it might be fine for tenant B to see artifacts from tenant A, the reverse could be very bad. so to be safe, there's no visibility across the boundary. | 18:44 |
* jkt reconfigures, thanks | 18:45 | |
corvus | jkt: the only things i can suggest are: yes, add a job (it could be the same job with a shared config) to the other tenant and build twice when needed. | 18:45 |
*** sdake_ has quit IRC | 18:45 | |
*** sdake has joined #zuul | 18:47 | |
corvus | jkt: or (and i don't really like this idea and would recommend against it) stash the artifact in some private repository that you access via out-of-band knowlege. for example: you could have a job look at the change numbers ahead of it and know that there might be a build stored under that change/patchset number. there are a number of problems that result from this though (for example, do you wait for the | 18:47 |
corvus | build if it isn't there yet?) | 18:47 |
*** takamatsu_ has quit IRC | 18:50 | |
*** sdake has quit IRC | 18:50 | |
*** sdake has joined #zuul | 18:52 | |
*** sdake has quit IRC | 18:55 | |
*** takamatsu_ has joined #zuul | 18:56 | |
*** sdake has joined #zuul | 18:56 | |
*** hashar has quit IRC | 18:58 | |
*** sdake has quit IRC | 19:01 | |
*** sdake has joined #zuul | 19:01 | |
*** sdake has quit IRC | 19:05 | |
*** sdake has joined #zuul | 19:07 | |
*** sdake has quit IRC | 19:11 | |
*** sshnaidm is now known as sshnaidm|afk | 19:11 | |
*** sdake has joined #zuul | 19:13 | |
*** yolanda has joined #zuul | 19:15 | |
*** sdake has quit IRC | 19:15 | |
*** sdake_ has joined #zuul | 19:17 | |
*** sdake_ has quit IRC | 19:20 | |
*** hashar has joined #zuul | 19:51 | |
*** hashar has quit IRC | 19:56 | |
*** jesusaur has quit IRC | 19:59 | |
*** hashar has joined #zuul | 20:00 | |
*** jesusaur has joined #zuul | 20:02 | |
*** bhavikdbavishi has quit IRC | 20:31 | |
corvus | tobiash: what do you think we need to do for the base64 change? do you think the usage footprint is small enough we can just make the change, send an email to zuul-announce, and apologize to anyone caught in the middle? or do we need to support both and do a transition? | 20:57 |
*** dkehn has joined #zuul | 20:58 | |
josefwells | In the docker quick-start, I had a problem where web couldn't connect to mysql server for reporting | 21:03 |
josefwells | I changed docker-compose.yaml to make the web command "sh -c 'sleep 120; zuul-web -d'" | 21:03 |
josefwells | this let mysql come up before web tried to connect and get mad or whatever | 21:04 |
josefwells | I guess zuul-web doesn't have ansible, so you can't just add the wait-to-start.yaml playbook | 21:04 |
josefwells | sleep 120 is terrible, but works | 21:05 |
josefwells | maybe because I'm using github and don't actually use the gerrit that is set up | 21:05 |
josefwells | not sure if there is some assumed delay as gerrit gets completed before web would normally start | 21:06 |
*** jpena|off has quit IRC | 21:09 | |
*** pabelanger has quit IRC | 21:09 | |
*** jpena|off has joined #zuul | 21:10 | |
*** mhu has quit IRC | 21:10 | |
*** mhu has joined #zuul | 21:14 | |
*** mhu has quit IRC | 21:16 | |
*** mhu has joined #zuul | 21:16 | |
*** hashar has quit IRC | 21:17 | |
openstackgerrit | Ian Wienand proposed openstack-infra/nodepool master: [dnm] testing rhel8 images https://review.openstack.org/639013 | 21:28 |
*** sdake has joined #zuul | 21:28 | |
*** sdake has quit IRC | 21:48 | |
*** sdake has joined #zuul | 21:59 | |
*** sdake has quit IRC | 22:01 | |
*** sdake has joined #zuul | 22:03 | |
*** sdake has quit IRC | 22:05 | |
*** sdake has joined #zuul | 22:08 | |
*** sdake has quit IRC | 22:10 | |
*** sdake has joined #zuul | 22:12 | |
*** sdake has quit IRC | 22:13 | |
*** sshnaidm|afk has quit IRC | 22:24 | |
jkt | I think I might have hit one edge case related to multi-tenancy and changes to untrusted projects | 22:30 |
jkt | I've changed Zuul to use two connections to Gerrit, and some of my projects are present in two tenants | 22:31 |
jkt | the inventory at http://paste.openstack.org/show/746078/, especially lines 50 and 157, show that I got git repos which actually belong to the other tenant | 22:32 |
jkt | this is just for one project out of many in that job's required-projects, and that one project just happened to have an unmerged change (this is check pipeline), and that change had no configured jobs, just noop for both tenants | 22:33 |
clarkb | jkt: I think you have to use fully qualified names in that case | 22:34 |
clarkb | I want to say pabelanger has run into this as well | 22:34 |
jkt | I came across this because the dependant job behaves as if that change was not merged | 22:34 |
jkt | clarkb: fully qualified names? | 22:34 |
jkt | clarkb: I read https://zuul-ci.org/docs/zuul/admin/drivers/gerrit.html#attr-%3Cgerrit%20connection%3E.canonical_hostname, both connections are alive and I see the executor reading stuff via git+ssh | 22:36 |
clarkb | jkt: ya so instead of just foo/project as the required projectname you do something like server.name/foo/project (I forget the exact format, would have to look it up) | 22:38 |
jkt | all projects use a correct connection name -- all but this one called "ci/zuul-jobs-cesnet", the one which also has an unmerged change on which this whole chain Depends-on | 22:38 |
clarkb | then every project should be unique because each connection has a different canonical name | 22:38 |
*** sshnaidm has joined #zuul | 22:39 | |
jkt | interesting | 22:39 |
clarkb | I'm pretty sure pabelanger has experience with this exact situation | 22:39 |
jkt | there are other projects which are available in both tenants, but just this one comes up wrong | 22:39 |
jkt | clarkb: so I should include the canonical-name in tenant configuration, right? Or in job's required-projects? Both? | 22:40 |
clarkb | jkt: in the jobs required projects iirc. I'm not sure if it is also necessary in the tenant configuration | 22:41 |
clarkb | (it may be necessary there too) | 22:41 |
jkt | ack, tenant config is apparently explicitly scoped by connection | 22:42 |
jkt | so that cannot be it | 22:42 |
jkt | ...and I do not have any explicit reference to that project in job's required-projects | 22:43 |
jkt | let's see what happens when I merge that first change | 22:45 |
jkt | something is very very fishy -- the dependant change now passed in tenant-B's check pipeline, but it is stuck "queued" in tenant-A | 22:51 |
corvus | jkt: why do you have 2 connections to gerrit? | 22:51 |
jkt | corvus: because I need one project in two zuul tenants, and because it was rather confusing to see two votes on that project | 22:53 |
jkt | (form the same CI user, sorry, it's getting late) | 22:53 |
corvus | jkt: i suspect you have indeed found an area that is poorly tested | 22:59 |
jkt | do you need some log dump, etc, or can I just keep blindly using a hammer to get this to unwedge itself? | 23:01 |
corvus | jkt: can you paste your connection and tenant configurations (with credentials redacted)? | 23:08 |
jkt | corvus: tenants are at https://gerrit.cesnet.cz/plugins/gitiles/ci/project-config/+/master/zuul/tenants.yaml | 23:10 |
jkt | corvus: connections at https://gerrit.cesnet.cz/plugins/gitiles/ci/ansible-cesnet/+/master/files/zuul/zuul.conf | 23:11 |
*** pabelanger has joined #zuul | 23:14 | |
corvus | jkt: your canonical_hostname isn't a hostname | 23:15 |
corvus | jkt: when you say "depends-on: gerrit.cesnet.cz/1234" zuul uses the hostname to try to figure out which connection can supply that change | 23:15 |
jkt | ah! | 23:16 |
corvus | jkt: since the "public" one is the first one with the gerrit.cesnet.cz hostname, it's going to be the one it picks | 23:16 |
jkt | that's how I understood the docs, btw -- they quite indicate that it does not have to be a hostname | 23:16 |
corvus | if the docs say "canonical_hostname does not need to be a hostname" then they are definitely wrong :) | 23:16 |
jkt | what's my least evil path forward? Should I add some DNS aliases? | 23:17 |
*** jamesmcarthur_ has quit IRC | 23:17 | |
jkt | or should I go back to a single connection to gerrit, and live with a duplicate vote when building artifacts? | 23:18 |
*** jamesmcarthur has joined #zuul | 23:19 | |
corvus | jkt: i have to warn you first that i am not certain that this is going to work. i don't believe anyone has tried to do what you're attempting. it may work, but we have no design use-cases for this, so you may eventually hit an edge case that doesn't have a solution. | 23:19 |
openstackgerrit | Ian Wienand proposed openstack-infra/nodepool master: [dnm] testing rhel8 images https://review.openstack.org/639013 | 23:20 |
corvus | jkt: but basically, zuul is never going to understand that those projects are really the same. you can control which connection is used to supply the change by setting the canonical_hostname. then if someone says "depends-on: gerrit.cesnet.gz/1234", whichever connection has that canonical_hostname is the one it will use. | 23:21 |
corvus | that seems to me that it's only going to solve half the problem. | 23:21 |
corvus | if you're okay with the "private" projects always referring to the "public" versions of the projects with depends-on, maybe that will work. but i really can't say. | 23:23 |
jkt | I think I'm ok with duplicate Depends-on headers if that worked, but now that I'm thinking about this, it won't, I guess | 23:24 |
jkt | or what does Zuul do when it sees a depends-on that it cannot resolve? | 23:24 |
corvus | generally it ignores it | 23:26 |
*** josefwells_ has joined #zuul | 23:27 | |
*** jamesmcarthur has quit IRC | 23:30 | |
josefwells_ | anyone with experience using static nodepools? | 23:32 |
jkt | josefwells_: a bit | 23:32 |
josefwells_ | I set the "user", but I think that means it does a ssh user@host | 23:32 |
josefwells_ | not su user; ssh host | 23:32 |
josefwells_ | is there any way around that | 23:33 |
josefwells_ | I have a playbook add the user to the executor, but just having the .ssh info doesn't work unless we su to the user | 23:33 |
jkt | I thought that the executor was designed with quite some bubblewrapping, so I'm surprised that you need a different UID on a node which is "just supposed to run ansible" | 23:35 |
corvus | josefwells_: if you're using a static node from nodepool, you shouldn't need to add it to the executor | 23:35 |
corvus | josefwells_: the idea is that nodepool provides the node to zuul, which adds it to the ansible inventory automatically | 23:35 |
jkt | corvus: thanks, I'll play with it a bit (and thanks for identifying the root clause) | 23:36 |
*** jamesmcarthur has joined #zuul | 23:36 | |
corvus | josefwells_: if you set this value, then this is the user that zuul's ansible will use to log into the host: https://zuul-ci.org/docs/nodepool/configuration.html#attr-providers.[static].pools.nodes.username | 23:36 |
corvus | josefwells_: and yes, that's "ssh user@host" | 23:36 |
josefwells_ | hmm maybe if I put the ssh key in /root/.ssh on the executor | 23:37 |
josefwells_ | then ssh user@host will work | 23:37 |
corvus | josefwells_: it will use the ssh private key you've configured on the executor for zuul. you'll need to make sure that the public key is already added to authorized_keys on the static node | 23:37 |
corvus | josefwells_: ah, this is the ssh private key that the executor will use: https://zuul-ci.org/docs/zuul/admin/components.html#attr-executor.private_key_file | 23:38 |
josefwells_ | oh, better | 23:38 |
josefwells_ | and the default username there too I reckon | 23:38 |
josefwells_ | or is that what the ssh is run as | 23:38 |
corvus | josefwells_: nope, that's what it uses if nodepool doesn't tell it what to use. | 23:39 |
corvus | josefwells_: the zuul executor doesn't do any changing of users -- everything runs as the user that the executor is started under. | 23:39 |
josefwells_ | ok, thanks! | 23:39 |
SpamapS | I *think* I just noticed that the AWS driver doesn't actually respect max-servers | 23:40 |
tristanC | corvus: thanks for your prompt feedback on the Parameterized Build, but it seems like you only mention concern with job graph filter. Those does apply with custom job parameters too? | 23:41 |
tristanC | corvus: I mean, we can work around using the job graph defined in repo, but we need to set parameters from trigger | 23:41 |
tristanC | corvus: if we implement the points you mentioned, would it also let trigger set parameters? | 23:42 |
*** jamesmcarthur has quit IRC | 23:47 | |
mordred | tristanC: no - I believe the idea there is to allow a general trigger construct that can act similar to the child-jobs filter does - selecting a specific job out of the existing set of defined jobs | 23:49 |
josefwells_ | Ahh freaking sweet! static node is up and noding! | 23:51 |
josefwells_ | you guys, this is going to be so beautiful, can't wait for the next step | 23:52 |
josefwells_ | thanks for the help, catch you later | 23:52 |
tristanC | mordred: unfortunately, that's not what we need | 23:53 |
tristanC | mordred: we could create multiple pipeline to match different AMQP message, but if we can't tell what was in the message, then it's kind of useless | 23:54 |
SpamapS | josefwells_: ^5 | 23:55 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!