*** yolanda has quit IRC | 00:06 | |
*** tosky has quit IRC | 00:08 | |
*** yolanda has joined #zuul | 00:09 | |
*** jamesmcarthur has joined #zuul | 00:28 | |
*** jamesmcarthur has quit IRC | 00:38 | |
*** threestrands has joined #zuul | 00:50 | |
*** jamesmcarthur has joined #zuul | 01:14 | |
*** jamesmcarthur has quit IRC | 01:16 | |
*** jamesmcarthur has joined #zuul | 01:19 | |
*** jamesmcarthur has quit IRC | 01:21 | |
*** igordc has quit IRC | 01:23 | |
SpamapS | hrm, does zuul enqueue work to enqueue things in "post" pipelines? | 01:25 |
---|---|---|
SpamapS | It seems to want something with a , with change#/patch# and my github push trigger just gives a ref# | 01:26 |
SpamapS | (hash) | 01:26 |
clarkb | SpamapS: enqueue-ref | 01:45 |
*** jamesmcarthur has joined #zuul | 01:47 | |
*** jpena|off has quit IRC | 01:57 | |
*** pabelanger has quit IRC | 01:57 | |
*** nhicher has quit IRC | 01:57 | |
*** migi has quit IRC | 01:58 | |
fungi | yeah, zuul enqueue for change-oriented pipelines, zuul enqueue-ref for git-ref-oriented pipelines | 02:01 |
fungi | though if i found time i'd look into what it would take to make enqueue support the same options | 02:02 |
*** jamesmcarthur has quit IRC | 02:03 | |
*** jpena|off has joined #zuul | 02:05 | |
*** jamesmcarthur has joined #zuul | 02:14 | |
*** nhicher has joined #zuul | 02:20 | |
*** rfolco has joined #zuul | 02:31 | |
*** rfolco has quit IRC | 02:36 | |
*** jamesmcarthur has quit IRC | 02:53 | |
*** bhavikdbavishi has joined #zuul | 03:01 | |
*** bhavikdbavishi1 has joined #zuul | 03:04 | |
*** bhavikdbavishi has quit IRC | 03:05 | |
*** bhavikdbavishi1 is now known as bhavikdbavishi | 03:05 | |
*** rlandy|bbl is now known as rlandy | 03:29 | |
*** jamesmcarthur has joined #zuul | 03:29 | |
*** jamesmcarthur has quit IRC | 03:38 | |
*** rlandy has quit IRC | 03:42 | |
*** armstrongs has joined #zuul | 03:56 | |
*** armstrongs has quit IRC | 04:06 | |
*** zxiiro has quit IRC | 04:37 | |
*** raukadah is now known as chkumar|rover | 05:13 | |
*** saneax has joined #zuul | 05:19 | |
*** bhavikdbavishi has quit IRC | 07:39 | |
*** saneax has quit IRC | 07:55 | |
*** hashar has joined #zuul | 08:07 | |
*** bhavikdbavishi has joined #zuul | 08:12 | |
openstackgerrit | Antoine Musso proposed zuul/zuul master: gear: remove support for custom MASS_DO packet https://review.opendev.org/704742 | 08:34 |
*** tosky has joined #zuul | 08:35 | |
*** bolg has joined #zuul | 08:43 | |
bolg | hashar: I've commented on https://review.opendev.org/c/671674/ . I've tried using selectors there, but since it's a bit different api it did not seem to me worth the effort. | 08:45 |
hashar | bolg: hi :) | 08:45 |
hashar | bolg: yes sorry about my comment from yesterday, that 'selectors' suggestion I have made distracted everyone | 08:46 |
hashar | Shrews and I talked a bit about it yesterday and indeed introducing 'selectors' is a lot of changes | 08:47 |
hashar | and also I forgot to CR +1 on my first comment there! | 08:48 |
*** jpena|off is now known as jpena | 08:54 | |
bolg | hashar: (y) | 08:59 |
*** bhavikdbavishi has quit IRC | 09:28 | |
*** bhavikdbavishi has joined #zuul | 09:28 | |
openstackgerrit | Mohammed Naser proposed zuul/zuul master: Start ignoring certain Gerrit events https://review.opendev.org/704756 | 09:38 |
*** bhavikdbavishi has quit IRC | 09:40 | |
openstackgerrit | Simon Westphahl proposed zuul/zuul master: Allow skipping child jobs from paused job again https://review.opendev.org/704758 | 09:47 |
*** threestrands has quit IRC | 09:47 | |
reiterative | Hi fbo. I'm testing your WIP on the Gitlab driver, and would be grateful if you can give me some guidance. It reads branches from my Gitlab repo and picks up job definitions from a test branch, but jobs are not triggered when I add or update an MR. What might I be missing? | 10:02 |
mnaser | reiterative: did you setup your pipeline to have the appropriate triggers? | 10:20 |
*** hashar has quit IRC | 10:30 | |
fbo | reiterative: hi, please make sure the events are well received by zuul. With debug log level, you could see them in the zuul web or scheduler logs. | 10:43 |
fbo | it could also maybe due to the webhook token different between your zuul config and what is configured in the project settings. | 10:44 |
reiterative | mnaser I have a check: item in the project definition if that's what you mean (I'm relatively new to Zuul) | 10:51 |
reiterative | fbo Thanks for the suggestions. I've been trying to turn on debug logging (using the logging.conf-sample from zuul/zuul for reference), but haven't managed to get it working yet. | 10:54 |
fbo | reiterative: mnaser means about the pipeline defintion. Do you have this (line 1) https://review.opendev.org/#/c/698964/3/tests/fixtures/layouts/basic-gitlab.yaml in a trusted repo ? | 10:56 |
reiterative | Aha! No I hadn't found that. I'm sure that will help :-) | 10:57 |
*** pcaruana has quit IRC | 10:57 | |
fbo | yes it will :) | 10:59 |
*** bhavikdbavishi has joined #zuul | 11:03 | |
*** bhavikdbavishi has quit IRC | 11:09 | |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: JWT drivers: Deprecate RS256withJWKS, introduce OpenIDConnect https://review.opendev.org/701972 | 11:12 |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: OIDCAuthenticator: add capabilities, scope option https://review.opendev.org/702275 | 11:12 |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: admin REST API: zuul-web integration https://review.opendev.org/643536 | 11:12 |
*** saneax has joined #zuul | 11:18 | |
*** saneax has quit IRC | 11:19 | |
*** saneax has joined #zuul | 11:20 | |
*** saneax has quit IRC | 11:25 | |
*** pcaruana has joined #zuul | 11:40 | |
*** bolg has quit IRC | 11:58 | |
*** bolg has joined #zuul | 12:02 | |
*** bhavikdbavishi has joined #zuul | 12:08 | |
*** rfolco has joined #zuul | 12:10 | |
*** hashar has joined #zuul | 12:10 | |
*** bhavikdbavishi1 has joined #zuul | 12:11 | |
*** bhavikdbavishi has quit IRC | 12:12 | |
*** bhavikdbavishi1 is now known as bhavikdbavishi | 12:12 | |
*** sshnaidm is now known as sshnaidm|afk | 12:15 | |
*** bolg has quit IRC | 12:17 | |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Replace existing operator tasks with the new dhall function https://review.opendev.org/702106 | 12:29 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Generate TLS certificats for the gearman service https://review.opendev.org/702716 | 12:29 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Handle service restart when connections are changed https://review.opendev.org/703624 | 12:29 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Add tenant reconfiguration when main.yaml changed https://review.opendev.org/703631 | 12:29 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Add OpenShift SCC and functional test https://review.opendev.org/702758 | 12:30 |
*** jpena is now known as jpena|lunch | 12:31 | |
*** hashar has quit IRC | 12:34 | |
openstackgerrit | Mohammed Naser proposed zuul/zuul master: Start ignoring certain Gerrit events https://review.opendev.org/704756 | 12:44 |
*** avass has joined #zuul | 13:00 | |
*** rlandy has joined #zuul | 13:02 | |
*** avass has quit IRC | 13:05 | |
*** bolg has joined #zuul | 13:10 | |
*** avass has joined #zuul | 13:10 | |
*** jpena|lunch is now known as jpena | 13:29 | |
*** avass has quit IRC | 13:35 | |
*** saneax has joined #zuul | 13:44 | |
*** bolg has quit IRC | 13:49 | |
*** jamesmcarthur has joined #zuul | 13:49 | |
reiterative | fbo I tried adding that pipeline definition to my zuul.config, but I get an error: | 13:51 |
reiterative | extra keys not allowed @ data['trigger']['gitlab'] | 13:51 |
reiterative | (Note that I added it to an existing gerrit config) | 13:51 |
*** zxiiro has joined #zuul | 14:05 | |
fbo | reiterative: the gitlab connection must have been defined first. Then the pipeline definition must be stored in a .zuul.yaml in a config-project repository (tenants.yaml). | 14:08 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: fetch-output-openshift: initial role https://review.opendev.org/682044 | 14:11 |
reiterative | OK. I'm defining my gitlab connection in zuul.conf at the moment, not as part of a config repo. | 14:17 |
*** jamesmcarthur has quit IRC | 14:38 | |
*** jamesmcarthur has joined #zuul | 14:40 | |
*** saneax has quit IRC | 14:43 | |
*** jamesmcarthur has quit IRC | 14:45 | |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Add OpenShift SCC and functional test https://review.opendev.org/702758 | 14:53 |
*** sshnaidm|afk is now known as sshnaidm | 14:56 | |
*** swest has quit IRC | 15:03 | |
*** swest has joined #zuul | 15:05 | |
*** swest has quit IRC | 15:05 | |
*** pabelanger has joined #zuul | 15:07 | |
*** jamesmcarthur has joined #zuul | 15:09 | |
*** jamesmcarthur has quit IRC | 15:14 | |
fungi | i know this is probably a long-shot, but is anyone here interested in speaking about zuul at open infrastructure days turkey in istanbul on march 17? they only just told the osf they're organizing it or i'd have asked much sooner | 15:42 |
*** jamesmcarthur has joined #zuul | 15:47 | |
*** jamesmcarthur has quit IRC | 15:53 | |
*** bhavikdbavishi has quit IRC | 15:59 | |
*** bhavikdbavishi has joined #zuul | 15:59 | |
*** chkumar|rover is now known as raukadah | 16:04 | |
*** bhavikdbavishi has quit IRC | 16:36 | |
*** bhavikdbavishi has joined #zuul | 16:37 | |
*** jamesmcarthur has joined #zuul | 16:39 | |
dmsimard | noticed a small inconsistency issue with zuul's inventory variables in the post and periodic pipelines .. in check and gate there is both "zuul.change" and "zuul.change_url" -- in post there is no zuul.change, only zuul.change_url and in periodic, there is no zuul.change and zuul.change_url has a "None" in the URL (likely because zuul.change is | 17:14 |
dmsimard | None in periodic) | 17:14 |
fungi | what do you think the missing vars should contain in those cases? | 17:18 |
fungi | there isn't a "change" provided in ref-triggered gerrit stream events | 17:19 |
fungi | and the periodic trigger has no gerrit context at all, just project/branch | 17:19 |
fungi | if you have suggestions for reasonable dummy values, they're probably not hard to add | 17:20 |
corvus | dmsimard: most of that sounds correct and as documented (see https://zuul-ci.org/docs/zuul/reference/jobs.html#zuul-variables ) but the "None" in the url sounds like a bug | 17:20 |
fungi | and yeah, i suspect the intent was to not include change_url for those triggers | 17:21 |
fungi | but instead we provide it with invalid content | 17:21 |
corvus | fungi: yeah they are intentionally missing; i think it's better that way since it's easy to check whether it's defined in ansible. and if a playbook uses them, without a default, then it's probably better to fail. | 17:21 |
fungi | makes sense | 17:22 |
dmsimard | fungi: I think it'd expected that there's no change or change_url for periodic -- for post, there should be zuul.change which is currently missing | 17:22 |
corvus | but clearly a url that looks like "http://something/None" isn't good for anyone :) | 17:22 |
fungi | dmsimard: why would there be a change for post? | 17:22 |
corvus | dmsimard: actually, post is not a change-based pipeline, so it only gets a branch | 17:22 |
dmsimard | fungi: because it originates from a change ? | 17:22 |
fungi | it doesn't though | 17:22 |
corvus | promote otoh, is change-based, so it does get a change | 17:22 |
fungi | it originates from an event about a branch tip updating | 17:22 |
fungi | which gerrit doesn't map to an event | 17:23 |
fungi | hence the promote pipeline triggering on a change-merged event (which *does* map to a change) | 17:23 |
corvus | in gerrit, this is tricky: the ref-updated event (post) gets you the actual commit sha after the change merges, but no info about the change. the change-merged event (promote) tells you about the change, but not the actual commit sha that results from the merge. | 17:23 |
dmsimard | fungi: but there is a change_url though | 17:23 |
fungi | s/which gerrit doesn't map to an event/which gerrit doesn't map to a change/ | 17:23 |
corvus | ideally we would have an event with both, but we'd need a change to gerrit. | 17:23 |
dmsimard | fwiw, a periodic inventory (with None in change_url and no change): https://b711d185688da3b864bc-5593d50c131879f6a486eeedbad80e3c.ssl.cf2.rackcdn.com/periodic/opendev.org/openstack/oslo.log/master/requirements-check/91e1e33/zuul-info/inventory.yaml | 17:24 |
dmsimard | and a post inventory with a working change_url but no change: https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_aa0/57e5a31f3721a46ad4d9394c2efb4cbe58de10e1/post/publish-stx-releasenotes/aa0c6c4/zuul-info/inventory.yaml | 17:24 |
corvus | ah yep. that first url should probably point to the branch | 17:25 |
corvus | the post looks correct | 17:25 |
corvus | probably the closest thing there is that it says "change_url" and not "item_url" | 17:25 |
fungi | i would argue the change_url is misnamed in the post example because it points to a (often merge) commit not a change | 17:25 |
dmsimard | corvus: so we have a change_url but not a change ? the change_url is built using the change no ? | 17:25 |
fungi | the change_url is not built on a change | 17:25 |
fungi | it's the git ref provided in the gerrit event | 17:26 |
fungi | in the case of your post pipeline example anyway | 17:26 |
dmsimard | fungi: ah, you're correct it's a git link, not a gerrit link | 17:26 |
corvus | yeah, i think that's the crux of the confusion. i think change_url is an ancient variable we probably should have renamed in v3 | 17:26 |
fungi | https://opendev.org/starlingx/config/commit/57e5a31f3721a46ad4d9394c2efb4cbe58de10e1 | 17:26 |
fungi | is what it links to in your example | 17:26 |
fungi | not a change, it's a merge ref | 17:26 |
corvus | we could start the process of renaming it now | 17:26 |
dmsimard | correct, my bad | 17:26 |
corvus | but at this point, we'd have to keep both names around for a while | 17:26 |
fungi | also yes, thinking about it harder, we wouldn't want to include dummy values for information not provided by the trigger if for no other reason than that would be a massive number of possibly useless information if we made it a habit across every possible trigger zuul supports | 17:29 |
fungi | as zuul grows an every increasing number of connection drivers, i expect the number of driver-specific bits of information to increase | 17:30 |
dmsimard | makes sense, so then my understanding is that it is working as intended but the None issue should be looked at | 17:30 |
fungi | and maybe the change_url should be renamed or split | 17:30 |
fungi | (with a lengthy deprecation cycle) | 17:31 |
corvus | clarkb: do you have your link to the draft wiki etherpad handy? | 17:33 |
clarkb | corvus: https://etherpad.openstack.org/p/zuul-wikipedia | 17:34 |
corvus | thx; replying to jamesmcarthur | 17:34 |
jamesmcarthur | hello! | 17:35 |
corvus | jamesmcarthur: i have sent an email in reply to your email! | 17:42 |
corvus | to which you replied, and to which reply i shall subsequently reply | 17:42 |
jamesmcarthur | lol | 17:43 |
fungi | this meta-discussion is riveting | 17:48 |
*** jpena is now known as jpena|off | 17:58 | |
*** mattw4 has joined #zuul | 18:01 | |
*** jamesmcarthur has quit IRC | 18:09 | |
*** michael-beaver has joined #zuul | 18:10 | |
*** jamesmcarthur has joined #zuul | 18:18 | |
*** tosky has quit IRC | 18:22 | |
*** jamesmcarthur has quit IRC | 18:26 | |
*** bhavikdbavishi has quit IRC | 18:33 | |
*** jamesmcarthur has joined #zuul | 18:55 | |
*** igordc has joined #zuul | 19:02 | |
*** hashar has joined #zuul | 19:10 | |
zbr | sorry to bother, but can we deal with the last 4 CRs on gear? https://review.opendev.org/#/q/project:opendev/gear+status:open | 19:15 |
corvus | zbr: that's on my list but not at the top. i should be able to take a look next week. | 19:16 |
corvus | tobiash: (and bolg) i reviewed https://review.opendev.org/621479 -- i think there are a couple of things to clarify. one of them is directly applicable to mandatory sql, so we should agree on that before proceeding with that patch. | 19:18 |
corvus | tobiash: i think we're almost there! :) | 19:18 |
tobiash | \o/ | 19:19 |
zbr | i mentioned it because i faced these while trying to more intresting work on zuul. | 19:20 |
zbr | for example i am unable to install zuul_return module on macos in order lint zuul playbooks, the latest verison of ansible-lint checks for module presence. | 19:21 |
zbr | or maybe we need an alternative way to distribute the module, installing zuul package is a bit of a BFG kind of approach, as it brings a huge amount of uneeded depds by default. | 19:23 |
tristanC | corvus: would `mandatory sql` results in the reporter be automatically setup for every pipeline? | 19:24 |
corvus | tristanC: yes | 19:24 |
tristanC | nice, that's great to hear :) | 19:24 |
corvus | ++ | 19:25 |
tobiash | corvus: I agree with the sql comment, I also don't have such a use case | 19:26 |
*** hashar has quit IRC | 19:26 | |
corvus | tristanC: starts at line 202 of https://review.opendev.org/621479 -- maybe you want to take a look at that and see if you agree with my comment or have a use case for multiple dbs | 19:26 |
tobiash | However I think I remember that the current system was designed with this as a theoretical use case | 19:27 |
tobiash | But I doubt as well that anyone uses multiple sal connections | 19:27 |
tristanC | corvus: that's what i was reading, and that make sense to me, we have not seen such a use case | 19:27 |
corvus | tobiash: yeah, all the use cases i know of that drove the original design should be able to be handled by queries | 19:27 |
*** jamesmcarthur has quit IRC | 19:27 | |
corvus | (ie, just query for "status=failed and project=foo") | 19:28 |
tobiash | cool makes it easier | 19:28 |
corvus | we could ask jhesketh to take a look and see if he can think of any reasons too | 19:29 |
*** mattw4 has quit IRC | 19:29 | |
tristanC | actually one sql per zuul should be enough for most use-case, but since zuul already support multiple sql connection, one sql per tenant sounds good too | 19:29 |
tobiash | corvus: regarding multithreaded popeline processors, we thought that we habe them anyway and the according locking with multiple schedulers and adding more threads per scheduler would be easy then | 19:29 |
*** mattw4 has joined #zuul | 19:30 | |
tobiash | At least what I observe is that also today we face quite some slowdowns when a big tenant performs tenant reconfigs | 19:30 |
corvus | tobiash: well, with more threads, it won't run any faster, (it will actually just run slower) except while waiting for cat jobs during a reconfig | 19:31 |
corvus | tobiash: but to a user, it would appear that progress was being made | 19:31 |
tobiash | yes, it would slow down the reconfig while still allowing other tenants to procerd | 19:32 |
corvus | i'm not strongly opposed to multi-threaded scheduler if folks think it's worthwhile, because i agree, it's not going to add much complexity (but i don't) | 19:32 |
tobiash | but you're right, we can just add more schedulers then | 19:32 |
corvus | yeah, more scheduler processes are the only way to make the overall system to run faster (under normal, non-reconfigure) conditions | 19:33 |
tobiash | k let's stay single threaded and see how it works for us then | 19:33 |
corvus | this is also easy to change later :) | 19:33 |
tobiash | probably having like 4 schedulers will be enough for quite some tenants | 19:34 |
tobiash | most of our stalls are caused by our busiest tenant | 19:34 |
tobiash | Im that case there would still be three other processors left | 19:35 |
*** plaurin has joined #zuul | 19:35 | |
plaurin | hello irc people | 19:36 |
corvus | tobiash: we could add some metrics around how much time is spent reconfiguring a tenant, how much busy/idle time for each scheduler, etc, to be able to measure the effect of adding more scheds | 19:36 |
corvus | plaurin: hello | 19:36 |
tobiash | good idea | 19:36 |
*** jamesmcarthur has joined #zuul | 19:38 | |
plaurin | corvus, tristanC: Hey I have been fiddeling around with the prepare-workspace-openshift and general kubernetes integration in zuul | 19:38 |
tristanC | plaurin: hello | 19:39 |
plaurin | I have this issue where the prepare-workspace-openshift does not have the concept of "{{ zuul_workspace_root }}" like in the regular prepare-workspace. Basically, it always put the src directory into the /tmp of my container in kubernetes | 19:40 |
plaurin | I will try to add that variable to the workspace openshift locally | 19:41 |
tristanC | plaurin: iirc that depends on the image WORKDIR | 19:42 |
plaurin | yes, but in all cases it seems to fall into the /tmp dir anyways | 19:42 |
openstackgerrit | Merged zuul/zuul master: Change default Gerrit HTTP auth method https://review.opendev.org/704068 | 19:43 |
plaurin | but I will double check double test this | 19:43 |
pabelanger | in the case of non-voting jobs, how could be better enforce not allowing them for a pipeline? For example, gate. Historically, we've viewed the results in that pipeline useless however it usually requires humans to manage that policy. Could we enfore some sort of pipeline stanza setting to not allow them, and report error? | 19:47 |
mordred | corvus, tristanC: do we even have a usecase for sql-per-tenant vs one global (agree about not specifying a sql per tenant if a global default is present) - mostly thinking about dashboard. .... oh, maybe it would be valuable from a scaleout perspective? | 19:54 |
pabelanger | what is a tenant, doesn't want logs to be public (if global default exists)? | 19:56 |
pabelanger | s/log/results | 19:57 |
*** gmann is now known as gmann_afk | 19:57 | |
clarkb | pabelanger: you could acl that off at the application rather than the db | 19:58 |
tobiash | mordred: I could think about requirements in the enterprise context, but I don't have that use case myself (yet) | 19:58 |
clarkb | I think either way a zuul operator would be able to see all the results | 19:58 |
clarkb | pabelanger: for non voting jobs, another option might be to force voting when in a pipeline with $flag set | 19:59 |
clarkb | pabelanger: the job would then still run as instructed but with a vote | 19:59 |
mordred | tobiash: yeah - I could imagine that too - and also don't have it | 20:00 |
clarkb | operationally sql per tenant may make sense for scaling reasons? | 20:01 |
clarkb | we still don't expire old data right? | 20:01 |
mordred | yeah. that's the use case that seems most compelling in my brain | 20:01 |
pabelanger | clarkb: re: acl, yah an option. I am just thinking some people might not want that info into databae at all | 20:01 |
pabelanger | clarkb: re: non-voting, right I'm more looking for, if job is non-voting, don't equeue it | 20:02 |
pabelanger | but know that go against zuul config settings | 20:02 |
clarkb | pabelanger: I think its usually best to be conservative and run jobs if they are asked for | 20:02 |
clarkb | users can remove the job from the pipeline to stop running the job | 20:03 |
clarkb | but an implicit removal could be dangerous | 20:03 |
tobiash | pabelanger, clarkb: I think the best would be to make nonvoting jobs a config error if some flag is set on a pipeline | 20:04 |
pabelanger | clarkb: yah, I'm looking for a way to help monitor that, but agree removal shouldn't happen. Maybe raise config error if proposed | 20:04 |
clarkb | ya error would work too | 20:04 |
tobiash | that is the way of least surprise :) | 20:05 |
mordred | ++ | 20:05 |
tobiash | and with no implicit behavior | 20:05 |
*** hashar has joined #zuul | 20:05 | |
tobiash | But validation can get tricky | 20:06 |
tobiash | Because you only know if a job is voting after job freezing | 20:07 |
AJaeger | docker image build is broken in periodic pipeline, https://review.opendev.org/704680 is a fix - reviews welcome | 20:07 |
tobiash | So the easiest while still with little surprise would be a job frezing error returning a good error message | 20:08 |
pabelanger | tobiash:++ | 20:08 |
corvus | i agree with the consensus on both pabelanger and mordred's points | 20:17 |
*** mattw4 has quit IRC | 20:25 | |
openstackgerrit | Merged zuul/zuul-jobs master: Fix periodic image build jobs https://review.opendev.org/704680 | 20:34 |
plaurin | corvus, tristanC: I tested with a docker container that has WORKSPACE set to "/home/ubuntu", but everything that happens in zuul happens in the "/tmp" dir | 20:37 |
plaurin | however I have an ansible variable set to "ansible_remote_tmp: /tmp", because else I have permissions issue | 20:40 |
tristanC | plaurin: found the reason: https://opendev.org/zuul/nodepool/src/branch/master/nodepool/driver/kubernetes/provider.py#L277 , that should override the image WORKSPACE | 20:43 |
plaurin | ohhh that's hardcoded in the source | 20:44 |
plaurin | in your opinion should this be a 'bug' or should I adapt my jobs to work with this? | 20:44 |
tristanC | plaurin: hard to tell... perhaps the workingDir should be configurable per label, with a default to /tmp ? | 20:46 |
tristanC | plaurin: what's the issue when using /tmp ? | 20:47 |
plaurin | imho default /tmp is fine as long as it's configurable. Well, I need to migrate jobs from static nodes to k8s. Many of my jobs 'rely' on the ubuntu home directory right now | 20:47 |
plaurin | there's some 'hardcode' on our side too in that manner ... | 20:48 |
plaurin | but I guess an interesting discussion | 20:48 |
plaurin | I would definitely be comfortable with a providers.[kubernetes].pools.labels.workdir in nodepool | 20:52 |
corvus | that sounds like a reasonable option | 20:55 |
corvus | note also that many zuul-jobs jobs (and our jobs in opendev) use "ansible_user_dir" instead of assuming cwd or hardcoding a path. i wonder if adapting your jobs to use that, and then setting that for the k8s jobs explicitly would work too? | 20:55 |
plaurin | a bit similar to "zuul_workspace_root:" in the prepare-workspace module, yeah | 20:58 |
*** jamesmcarthur has quit IRC | 21:05 | |
fungi | pabelanger: clarkb: i've had a lingering item on my to do list to file a story for a pipeline option to automatically exclude non-voting jobs | 21:11 |
fungi | "write story about option to strip non-voting jobs from a zuul pipeline" | 21:11 |
fungi | i'm happy to cross that off if someone's on it | 21:11 |
fungi | there were some arguments in favor of that around being able to do things like define a list of job names in a yaml anchor and then reuse a pointer to that in other pipelines | 21:13 |
fungi | and also situations where a project may apply a project-template but then want to switch a single job to non-voting without having to duplicate the contents of the template minus one entry in another pipeline | 21:14 |
*** gmann_afk is now known as gmann | 21:17 | |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: fetch-output-openshift: initial role https://review.opendev.org/682044 | 21:25 |
*** jamesmcarthur has joined #zuul | 21:32 | |
*** mattw4 has joined #zuul | 21:40 | |
pabelanger | fungi: ack, thanks! | 21:43 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: fetch-output-openshift: initial role https://review.opendev.org/682044 | 21:43 |
pabelanger | also, https://dashboard.zuul.ansible.com/t/ansible/build/48a8693d652e4de090bd8cfd46197ef2 is our pypi release job for zuul.a.c | 21:44 |
*** tosky has joined #zuul | 22:10 | |
*** jamesmcarthur has quit IRC | 22:18 | |
*** jamesmcarthur has joined #zuul | 22:19 | |
*** hashar has quit IRC | 22:25 | |
openstackgerrit | James E. Blair proposed zuul/zuul master: Add gcloud_service auth option for Gerrit driver https://review.opendev.org/704904 | 22:26 |
*** rfolco has quit IRC | 22:33 | |
openstackgerrit | James E. Blair proposed zuul/zuul master: Add gcloud_service auth option for Gerrit driver https://review.opendev.org/704904 | 23:12 |
*** rlandy is now known as rlandy|bbl | 23:14 | |
*** plaurin has quit IRC | 23:31 | |
*** sshnaidm is now known as sshnaidm|afk | 23:45 | |
*** tosky has quit IRC | 23:52 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!