| *** armstrongs has joined #zuul | 00:02 | |
| *** armstrongs has quit IRC | 00:12 | |
| mordred | tobiash: I think that's nicer to read | 00:19 |
|---|---|---|
| *** smcginnis|PTO has quit IRC | 01:51 | |
| *** smcginnis|PTO has joined #zuul | 01:52 | |
| *** bhavikdbavishi has joined #zuul | 03:31 | |
| *** bhavikdbavishi1 has joined #zuul | 03:36 | |
| *** bhavikdbavishi has quit IRC | 03:38 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 03:38 | |
| *** saneax has joined #zuul | 04:26 | |
| *** raukadah is now known as chandankumar | 04:51 | |
| *** evrardjp has quit IRC | 05:34 | |
| *** evrardjp has joined #zuul | 05:34 | |
| openstackgerrit | Simon Westphahl proposed zuul/nodepool master: Cleanup exception logging in static provider https://review.opendev.org/702828 | 06:14 |
| *** themroc has joined #zuul | 06:46 | |
| *** tosky has joined #zuul | 08:17 | |
| *** jpena|off is now known as jpena | 08:50 | |
| *** arxcruz|off is now known as arxcruz | 09:22 | |
| *** jhesketh has quit IRC | 09:32 | |
| *** jhesketh has joined #zuul | 09:34 | |
| *** sgw has quit IRC | 09:40 | |
| *** sgw has joined #zuul | 09:53 | |
| *** AJaeger has quit IRC | 10:05 | |
| openstackgerrit | Antoine Musso proposed zuul/zuul master: doc: add links to components documentation https://review.opendev.org/703105 | 10:40 |
| arxcruz | hello guys, I need to run an ansible-role in the post | 10:54 |
| arxcruz | what's the best way to add the role in zuul ansible path? | 10:55 |
| arxcruz | if i add roles: zuul: openstack/myrole in job definition will it work ? | 10:55 |
| zbr|drover | arxcruz: has a valid question, i wondered this myself because "roles" in job config make zuul run the roles, so you cannot use it make a role available for later using in post-run | 10:58 |
| zbr|drover | i also got a weird error trying to build zuul docs locally, http://paste.openstack.org/show/788593/ | 11:09 |
| arxcruz | corvus: ^ | 11:10 |
| arxcruz | fungi: ^ | 11:10 |
| reiterative | I'm trying to get a basic zuul setup working on AWS, using the quick start tutorial example as a reference, but my jobs are failing to load the general roles (e.g. prepare-workspace, upload-logs) from zuul/zuul-jobs. I can see via the web interface that the zuul-jobs repo from opendev has been loaded, and confirmed this by running zuul-scheduler with debug on. I've also tried running zuul-executor in debug mode, but could not see any clues as to why | 11:38 |
| reiterative | it isn't working. Can anyone suggest what else I can do to debug this? | 11:38 |
| openstackgerrit | Sorin Sbarnea proposed zuul/zuul master: WIP: docs: improve job.role documentation https://review.opendev.org/703372 | 11:39 |
| *** AJaeger has joined #zuul | 11:56 | |
| openstackgerrit | Sorin Sbarnea proposed zuul/zuul master: docs: improve job.role documentation https://review.opendev.org/703372 | 12:00 |
| *** mnaser has quit IRC | 12:27 | |
| *** adam_g has quit IRC | 12:27 | |
| *** mnaser has joined #zuul | 12:27 | |
| *** adam_g has joined #zuul | 12:28 | |
| *** rfolco has joined #zuul | 12:29 | |
| zbr|drover | arxcruz: added your question at https://stackoverflow.com/q/59822978/99834 as it seems to be of general interest | 12:29 |
| *** jpena is now known as jpena|lunch | 12:35 | |
| arxcruz | zbr|drover: thanks | 12:39 |
| arxcruz | perhaps jpena|lunch knows | 12:39 |
| *** fbo|off is now known as fbo | 12:56 | |
| *** rfolco is now known as rfolco|bbl | 12:56 | |
| *** avass has joined #zuul | 12:58 | |
| *** rlandy has joined #zuul | 13:00 | |
| *** electrofelix has joined #zuul | 13:01 | |
| *** electrofelix has quit IRC | 13:01 | |
| *** smcginnis|PTO is now known as smcginnis | 13:09 | |
| *** jpena|lunch is now known as jpena | 13:30 | |
| jpena | arxcruz: I see https://zuul-ci.org/docs/zuul/reference/job_def.html#attr-job.roles which should match your need, but I'm not sure if I understood the question | 13:59 |
| zbr|drover | jpena: ins't https://stackoverflow.com/q/59822978/99834 clear enough? | 14:06 |
| jpena | zbr|drover: I didn't see the example when I first checked | 14:06 |
| zbr|drover | i added it few seconds ago | 14:07 |
| jpena | that's weird, the zuul docs do not imply that the role will be auto-run | 14:07 |
| zbr|drover | i think we should start using examples in the docs, lots of them. | 14:07 |
| jpena | agreed | 14:07 |
| zbr|drover | first sentence from https://zuul-ci.org/docs/zuul/reference/job_def.html?highlight=job#attr-job.roles makes me believe zuul will run the role | 14:08 |
| zbr|drover | if adding roles there only makes them available, is ok. arx will know what to do. | 14:09 |
| zbr|drover | and I have to update my doc patch to make this clear. | 14:09 |
| zbr|drover | i wonder what "prepared and installed" really means | 14:10 |
| zbr|drover | use of prepare there is really confusing, especially because there is a pre-run.. which translated to "prepare-run" | 14:10 |
| zbr|drover | please review https://review.opendev.org/#/c/703372/ | 14:15 |
| *** rfolco|bbl is now known as rfolco | 14:16 | |
| zbr|drover | i was also not able to run "tox -e docs" on zuul, tried macos and centos-8, choked on both with http://paste.openstack.org/show/788593/ | 14:20 |
| openstackgerrit | Sorin Sbarnea proposed zuul/zuul master: bindep: fixed wrong dep names on rpm platform https://review.opendev.org/703403 | 14:30 |
| tobiash | adding the roles there exactly makes them available to ansible, no role is automatically run | 14:31 |
| tobiash | zuul executes exactly the pre, run, post and cleanup playbooks | 14:31 |
| tobiash | if those playbooks don't use a role, it's not executed | 14:31 |
| zbr|drover | so cool, https://pypi.org/project/gear/#files does not even have a link to the source code, lucky that I know where it should be. | 14:34 |
| zbr|drover | project homepage links to the pypa itself, not really useful :D | 14:35 |
| *** zxiiro has joined #zuul | 14:36 | |
| zbr|drover | tobiash: thanks for the confirmation, I will update the doc. | 14:39 |
| fungi | zbr|drover: are you able to run `zuul-manage-ansible -h` yourself from the venv? does it give an error when you do that (in addition to a nonzero exit code)? | 14:42 |
| fungi | (sphinx is configured to capture the output of that command to incorporate into the generated documentation) | 14:43 |
| fungi | like `/Users/ssbarnea/c/rdo/zuul/.tox/docs/bin/zuul-manage-ansible -h` maybe | 14:43 |
| zbr|drover | fungi: i managed to narrow down to https://opendev.org/opendev/gear/src/branch/master/gear/__init__.py#L2732-L2735 | 14:44 |
| zbr|drover | none of these are defined on macos, and at least first one neither on centos. | 14:45 |
| zbr|drover | and this code runs even when trying to build the docs.... | 14:45 |
| zbr|drover | sadly i have no knowledge of gear, so not sure with what it would be acceptable to replace them wiht | 14:45 |
| openstackgerrit | Simon Westphahl proposed zuul/nodepool master: Handle event id in node requests https://review.opendev.org/703406 | 14:46 |
| openstackgerrit | Simon Westphahl proposed zuul/nodepool master: Centralize logging adapters https://review.opendev.org/703407 | 14:46 |
| fungi | yeah, sounds like sockets on the macos mach kernel lack epoll? | 14:46 |
| Shrews | os x has poll and kqueue | 14:46 |
| fungi | we might be able to improve zuul-ansible-manage so that it doesn't result in gear being force-imported in that code path | 14:46 |
| fungi | i can't imagine gear itself being needed for that utility | 14:47 |
| fungi | alternatively, maybe someone wants to make gear work on macos | 14:47 |
| zbr|drover | yeah, i wonder what happens if put a fallback to set all of them to zero | 14:47 |
| zbr|drover | i have no plans to write services for macos, i only want to build zuul docs, and hopfully running some unittests. | 14:48 |
| zbr|drover | funny part that i get the same error on centos, too. | 14:48 |
| Shrews | fungi: https://review.opendev.org/671674 | 14:48 |
| zbr|drover | Shrews: super! testing locally now. | 14:51 |
| zbr|drover | can we merge ^ and release it? | 14:56 |
| fungi | zbr|drover: as in `zuul-ansible-manage -h` exits 1 on centos too? | 14:56 |
| fungi | that i find more surprising | 14:56 |
| openstackgerrit | Simon Westphahl proposed zuul/nodepool master: Make flake8 config compatible with latest version https://review.opendev.org/703410 | 14:58 |
| tristanC | corvus: mnaser: mordred: pabelanger: clarkb: tobiash: Shrews: here are my notes about how I implemented the zuul-operator and how it can be extended by our sf-operator: https://etherpad.openstack.org/p/zuul-operator-dhall | 14:59 |
| zbr|drover | fungi: i think i seen it failing too there but probably for different reason. | 14:59 |
| zbr|drover | but on macos that patch is fixing the problem | 14:59 |
| zbr|drover | we need to make the stderr visible because when it fails now, you do not see any error. | 15:00 |
| zbr|drover | i had to enter the venv and run the command manually to see what it was producing | 15:00 |
| tristanC | fungi: ^ (sorry i forgot you were in the call too) | 15:01 |
| fungi | zbr|drover: well, the error says what command failed, so presumably it can be executed directly to get the stdout/stderr if needed, but i don't see any problem with echoing it if there's some way to get that sphinx extension to do so | 15:02 |
| zbr|drover | centos error is unrelated, pip._vendor.pkg_resources.ContextualVersionConflict: (urllib3 1.25.7 (/home/ssbarnea/rmux/zuul/.tox/docs/lib/python3.6/site-packages), Requirement.parse('urllib3<=1.25.3'), {'zuul'} | 15:02 |
| *** johanssone has quit IRC | 15:03 | |
| zbr|drover | i will change the reqs | 15:04 |
| fungi | ahh, pip is embedding a newer urllib3 than zuul is pinned to | 15:04 |
| fungi | note in requirements.txt refers to that pin being a workaround for https://github.com/urllib3/urllib3/pull/1684 | 15:04 |
| zbr|drover | correct it would be >=1.25.5 | 15:04 |
| fungi | or at least !=1.25.4 | 15:06 |
| fungi | are you sure 1.25.5 included the fix? | 15:07 |
| openstackgerrit | Sorin Sbarnea proposed zuul/zuul master: Unlock urllib pinning https://review.opendev.org/703414 | 15:07 |
| fungi | zbr|drover: it doesn't | 15:09 |
| fungi | git tag --contains 9167b58128dbfe3ddcbab253166697348d8d364c | 15:09 |
| fungi | we need !=1.25.4,!=1.25.5 | 15:09 |
| fungi | i'll comment in the review | 15:09 |
| *** johanssone has joined #zuul | 15:09 | |
| zbr|drover | fungi: you preffer not instead of >= ? | 15:09 |
| fungi | yes, because zuul still works on platforms with older urllib3 | 15:11 |
| openstackgerrit | Sorin Sbarnea proposed zuul/zuul master: Unpin urllib https://review.opendev.org/703414 | 15:11 |
| *** armstrongs has joined #zuul | 15:14 | |
| *** chandankumar is now known as raukadah | 15:15 | |
| zbr|drover | my impression is that gear does not work with newer pythons, i got timeout errors running tests. i am going to enable nv jobs. | 15:21 |
| *** armstrongs has quit IRC | 15:26 | |
| *** bhavikdbavishi has quit IRC | 15:37 | |
| arxcruz | zbr|drover: jpena just tested, zuul doesn't run the role, it just install on /var/lib/zuul/build and so be available in pre/post/run | 15:37 |
| jpena | aha, that makes sense then | 15:38 |
| *** avass has quit IRC | 15:53 | |
| clarkb | yes it is a dependency specification | 15:54 |
| clarkb | it makes the role available to the job | 15:54 |
| clarkb | reiterative: ^ that may actually be what your job needs too | 15:54 |
| clarkb | reiterative: update the base job to include roles from zuul-jobs to make them available in the job context | 15:54 |
| *** openstackgerrit has quit IRC | 16:13 | |
| Shrews | ugh. i did not notice, but we lost our links to the yaml definition files in the doc reference section | 16:16 |
| Shrews | corvus: i don't think that was intentional, was it? should be easy to add back | 16:17 |
| corvus | Shrews: which links? | 16:17 |
| Shrews | to the new *_def.rst files | 16:18 |
| Shrews | missing from the reference/user.rst toc | 16:18 |
| corvus | Shrews: i see them at https://zuul-ci.org/docs/zuul/reference/user.html | 16:18 |
| corvus | also https://zuul-ci.org/docs/zuul/reference/config.html#configuration-items | 16:18 |
| Shrews | right, but i mean from the root doc page | 16:18 |
| corvus | Shrews: i don't think we ever had that. we agreed it would be nice, but there are complications | 16:19 |
| corvus | oh nope i'm wrong | 16:19 |
| Shrews | corvus: we had that when I initially added them under the common Reference section | 16:19 |
| corvus | they are here https://zuul-ci.org/docs/zuul/3.15.0/ | 16:19 |
| Shrews | yeah. got a fix coming | 16:20 |
| corvus | the tricky thing is that they should be under "user reference > project configuration" | 16:21 |
| *** rishabhhpe has joined #zuul | 16:22 | |
| Shrews | corvus: yeah, that we can't do as far as i've been able to find | 16:22 |
| *** tosky has quit IRC | 16:23 | |
| Shrews | but without them on the root level page, they are hidden yet again :( | 16:24 |
| corvus | Shrews: we could manually create the user reference TOC | 16:24 |
| Shrews | corvus: how? | 16:25 |
| corvus | Shrews: create a hidden tocree, then just make some bullet lists | 16:26 |
| rishabhhpe | Hi All , Can anyone help in resolving this issue -: http://paste.openstack.org/show/788608/ during building the image | 16:26 |
| Shrews | corvus: is there an example of how to do that? | 16:27 |
| corvus | Shrews: not that i'm aware of | 16:28 |
| corvus | Shrews: the :hidden: flag is doc'd here https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html | 16:30 |
| corvus | Shrews: we should think really hard about whether that should be on this index though. i agree it's really useful, but otoh, if this is supposed to be an effective index of many kinds of documentation, having too much detail may not be best. it might be better to figure out a section title other than "project configuration" that tells people that's what they're looking for. | 16:35 |
| corvus | sort of like how i know to go to the library reference to see all the python modules: https://docs.python.org/3/ | 16:35 |
| rishabhhpe | clarkb: fungi: can you please help me with this -: http://paste.openstack.org/show/788608/ | 16:45 |
| tristanC | corvus: Shrews: actually, the django doc doesn't even list the tutorials or howtos from the main toc, perhaps the main index.rst should only contains the 4 categories links (tutorial/howto/discussion/reference) ? | 16:53 |
| tristanC | and within each category, we could increase the toc depth to include nested elements like the project configuration | 16:54 |
| corvus | tristanC: zuul is a different kind of application than dango. it has distinct audiences of end-users and administrators, so our top-level has to accomodate that. | 16:54 |
| corvus | so we currently have 6 sections | 16:54 |
| corvus | (we might have 8, if we end up just doubling the 4 for both audiences) | 16:55 |
| corvus | but yeah | 16:55 |
| tristanC | corvus: so just 6 links from the main index.rst (user|admin)-tutorials and (user|admin)-howtos | 16:55 |
| corvus | yeah, that's probably worth a look | 16:55 |
| corvus | because if we can get someone to click on "user reference" then they get this, which is great: https://zuul-ci.org/docs/zuul/reference/user.html | 16:56 |
| corvus | Shrews: ^ the "less is more" approach | 16:56 |
| tristanC | Shrews: i can propose a draft for above approach if you want | 16:57 |
| corvus | (meanwhile, i'm working on updating the redirects) | 16:58 |
| fungi | rishabhhpe: sorry, i was in a meeting (so was clarkb). looking at your paste, diskimage-builder is complaining about being unable to deploy the root element, but i don't see any details there as to why | 17:01 |
| fungi | corvus: i wonder if the shell script i embedded in my .htaccess change to parse git's file list could also work on a git diff between then and master tip? | 17:02 |
| corvus | fungi: i dunno... i just did this vvv semi-manually | 17:02 |
| fungi | er, shell script i used in my .htaccess change, noted in a review comment | 17:02 |
| *** openstackgerrit has joined #zuul | 17:03 | |
| openstackgerrit | James E. Blair proposed zuul/zuul-website master: Update redirects https://review.opendev.org/703454 | 17:03 |
| fungi | cool, reviewing now | 17:03 |
| corvus | the shell script did end up adding more redirects than we really need (but the extras are easy to remove now that i've noticed them) | 17:04 |
| Shrews | tristanC: sure, if you want. I’m at lunch now | 17:04 |
| corvus | the changes are mostly paired -- i wonder if it would be more readable if i organized that differently | 17:04 |
| rishabhhpe | fungi: only this much information is published in the log | 17:06 |
| openstackgerrit | James E. Blair proposed zuul/zuul-website master: Update redirects https://review.opendev.org/703456 | 17:09 |
| openstackgerrit | James E. Blair proposed zuul/zuul-website master: Update redirects https://review.opendev.org/703456 | 17:13 |
| openstackgerrit | James E. Blair proposed zuul/zuul-website master: Remove some redirects https://review.opendev.org/703457 | 17:13 |
| *** tobiash has quit IRC | 17:14 | |
| corvus | fungi: there we go. i like this better ignore the first change in favor of 457 and 456 | 17:14 |
| corvus | i think that's in a much more reviewable form | 17:14 |
| pabelanger | Did we land the logging of retry_failures into builds UI? IIRC, we only report the last failure, not the previous 2 (if 3 is max times) | 17:21 |
| clarkb | pabelanger: not in the UI, but it is in the job info and can be indexed now | 17:23 |
| *** tobiash has joined #zuul | 17:23 | |
| clarkb | pabelanger: because ya the db only gets the last one | 17:23 |
| pabelanger | clarkb: indexed from where? | 17:24 |
| clarkb | pabelanger: in opendev's case elasticsearch | 17:25 |
| rishabhhpe | clarkb: fungi: did u get any updates over that config-drive issue in which my disk-image-builder was not able to attach config-drive to the spawned VM | 17:26 |
| clarkb | (basically its in your job inventory data so however you get at that historical info) | 17:26 |
| pabelanger | clarkb: ah, yah. That is our issue today, we 100% rely on zuul UI for that info | 17:27 |
| fungi | rishabhhpe: it's working for us, so no i honestly have no idea why it's not working for you | 17:27 |
| clarkb | pabelanger: I believe tobiash and crew have a change up to record intermediate builds in the buildsets | 17:27 |
| clarkb | pabelanger: I don't remember where it was in review though. I recall corvus explaining that it is complicated or something | 17:27 |
| rishabhhpe | ok | 17:28 |
| fungi | rishabhhpe: we suggested configuring openstacksdk to perform debug logging so that the log will include the exact api call parameters it's making to nova so you can see whether nodepool is failing to pass the config-drive option vs whether nova is ignoring it for some reason | 17:28 |
| rishabhhpe | can you share your nodepool.yaml and the changes which you did in your disk-builder so that i can also try with same setup | 17:29 |
| rishabhhpe | fungi: i am not sure how i can enable the debug logging if you can guide surely i will move forward | 17:29 |
| pabelanger | clarkb: k, will see what others say. Thanks! | 17:29 |
| tobiash | clarkb, pabelanger: https://review.opendev.org/#/c/633501 and related change | 17:31 |
| pabelanger | ++ | 17:34 |
| *** evrardjp has quit IRC | 17:34 | |
| fungi | rishabhhpe: our nodepool configuration is here: https://opendev.org/openstack/project-config/src/branch/master/nodepool | 17:34 |
| *** evrardjp has joined #zuul | 17:34 | |
| fungi | rishabhhpe: https://opendev.org/openstack/project-config/src/branch/master/nodepool/nl01.openstack.org.yaml is a good example of the nodepool.yaml on one of our launchers | 17:35 |
| fungi | rishabhhpe: https://opendev.org/openstack/project-config/src/branch/master/nodepool/nodepool.yaml is what we use on our builders | 17:35 |
| fungi | rishabhhpe: and https://opendev.org/openstack/project-config/src/branch/master/nodepool/elements is where we put additional dib elements we use | 17:36 |
| tristanC | i've proposed to add zuul to https://github.com/ligurio/awesome-ci/pull/91 | 17:36 |
| fungi | thanks tristanC! | 17:38 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: docs: remove generated toc from the main index https://review.opendev.org/703468 | 17:40 |
| tristanC | corvus: Shrews: here is the lighter main toc we discussed earlier ^ | 17:41 |
| *** Goneri has quit IRC | 17:47 | |
| *** gouthamr_ has joined #zuul | 17:47 | |
| *** jpena is now known as jpena|off | 17:48 | |
| openstackgerrit | James E. Blair proposed zuul/zuul master: Docs: change "config" title https://review.opendev.org/703471 | 17:51 |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: docs: remove generated toc from the main index https://review.opendev.org/703468 | 17:58 |
| *** jamesmcarthur has joined #zuul | 18:03 | |
| corvus | tristanC: would your sf operator basically include a copy of the zuul operator in order to extend it? would your plan be to copy changes from zuul-operator into sf-operator? | 18:08 |
| corvus | tristanC: (that's what https://softwarefactory-project.io/r/#/c/17346/2/conf/zuul/applications/Zuul.dhall looks like to me) | 18:09 |
| *** gouthamr_ has quit IRC | 18:10 | |
| *** Shrews has quit IRC | 18:11 | |
| *** gundalow has quit IRC | 18:11 | |
| *** tributarian has quit IRC | 18:11 | |
| *** Shrews has joined #zuul | 18:11 | |
| *** gundalow has joined #zuul | 18:12 | |
| *** tributarian has joined #zuul | 18:12 | |
| tristanC | corvus: i only included a copy because it is not merged yet upstream, otherwise we would import it like a regular package | 18:22 |
| tristanC | corvus: the conf/zuul is a copy of https://review.opendev.org/#/c/702105/ | 18:23 |
| corvus | tristanC: okay, so there is an import mechanism | 18:23 |
| corvus | tristanC: would you be able to add mqtt using that? | 18:24 |
| tristanC | corvus: here is how import works: https://review.opendev.org/#/c/702104/6/conf/operator/Prelude.dhall | 18:24 |
| corvus | (i guess it was just easier to modify the local copy rather than making a new mqtt file that imports zuul?) | 18:24 |
| corvus | tristanC: is the sha256 required? | 18:25 |
| tristanC | corvus: right, it was just easier like that, this https://softwarefactory-project.io/r/#/c/17346/2/conf/zuul/applications/Zuul.dhall needs to be proposed in zuul/zuul-operator | 18:25 |
| corvus | yeah, you're right, mqtt belongs there anyway | 18:26 |
| tristanC | corvus: the sha256 is a semantic hash, see https://github.com/dhall-lang/dhall-lang/wiki/Safety-guarantees#code-injection | 18:26 |
| tristanC | and if the hash is already in the cache, then it's used without network lookup | 18:27 |
| tristanC | corvus: more generally, any dhall expression can be a path or an url, and in that case, the content is loaded as if it was defined locally | 18:29 |
| tristanC | corvus: that can also be used to load text file, here i'm doing that to fetch the uid_entrypoint script: https://softwarefactory-project.io/r/#/c/17345/3/conf/sf/applications/helpers.dhall@230 | 18:29 |
| corvus | that is very powerful indeed; i understand the sha256 reasoning now | 18:30 |
| rishabhhpe | fungi: i am following the nodepool.yaml file recommend by you .. and also while cloning the elements from opendev.org for nodepool image building i am getting duplicate entries for control-plane-minimal and in infra-package-needs packages .. last time also i faced same thing i deleted the duplicate items from infra-package-needs elements can that cause the issue for glean not getting the ip info from nodepool ? | 18:31 |
| corvus | tristanC: do you think kopf would support the extension mechanisms you'd need? i imagine it could be published to pypi and imported... | 18:31 |
| tristanC | corvus: i can't see why it wouldn't let you import and use functions defined in another project | 18:31 |
| *** jamesmcarthur has quit IRC | 18:36 | |
| tristanC | i'm not using any special mechanisms, the dhall code could be simply rewritten using python lambda or pure functions | 18:37 |
| *** tosky has joined #zuul | 18:50 | |
| *** rishabhhpe has quit IRC | 19:04 | |
| mnaser | could I get reviews for https://review.opendev.org/#/c/702963/ and https://review.opendev.org/#/c/702965/ ? :> | 19:08 |
| tristanC | corvus: mnaser: my worries with helm is that the template configuration might end up like this one: https://github.com/helm/charts/blob/master/stable/prometheus/values.yaml | 19:16 |
| mnaser | tristanC: In my experience that’s just a part of doing helm and one of the more poor experiences about it | 19:18 |
| mnaser | For all the good stuff there is a few annoying issues like these | 19:18 |
| *** themroc has quit IRC | 19:19 | |
| corvus | i wonder if we can automatically pass some things through | 19:21 |
| corvus | like this: executor: {replicas: 3, args: {disk_limit_per_job: 250}} | 19:22 |
| corvus | and just add args to the template | 19:22 |
| *** igordc has joined #zuul | 19:23 | |
| pabelanger | yes, I would like to see that too | 19:24 |
| pabelanger | the link tristanC shared is very much like how we did it in puppet, which was painful to me | 19:24 |
| tristanC | if zuul-helm just implements the spec defined in https://zuul-ci.org/docs/zuul/reference/developer/specs/kubernetes-operator.html#custom-resource-definitions , then the values.yaml shouldn't grow out of control | 19:28 |
| *** adam_g has quit IRC | 19:28 | |
| tristanC | but i found that as you add more services, such as elasticsearch or mqtt, then it becomes difficult to manage the resources using values and template only. | 19:29 |
| pabelanger | can the zuul.conf template file be read from file or does it need to exist in the crd yaml (sorry, not sure if the correct term). | 19:32 |
| corvus | crd is an operator term | 19:32 |
| corvus | probably best not to confuse helm and operator here | 19:32 |
| tristanC | pabelanger: because the zuul-operator may manage the database connection, then we decided that the zuul.conf would be managed by the operator | 19:33 |
| tristanC | corvus: actually, iiuc the operator-sdk support helm, thus it might be possible to implement the crd using the zuul-helm charts | 19:34 |
| corvus | a fifth option | 19:34 |
| pabelanger | so, as an example, with ansible-role-zuul, there is a default template use to populate zuul.conf: https://opendev.org/windmill/ansible-role-zuul/src/branch/master/defaults/main.yaml#L102 but, if it needs to be more complex, that is exposed as ansible variable for user to provide own. From what I understand, you might not be able to do that in helm? | 19:34 |
| tristanC | https://github.com/operator-framework/operator-sdk/blob/master/doc/helm/user-guide.md | 19:35 |
| tristanC | pabelanger: you could do that with helm or any operator language, but then if the system creates the database connection for you, then you would have to concat ini files. that works, but that is also error prone | 19:36 |
| pabelanger | tristanC: right, you'd do that or leave database bits to human. Or, maybe look to support zuul.d folder for zuul.conf? | 19:37 |
| pabelanger | I want to say, maybe there was a patch up to support that | 19:37 |
| pabelanger | I think it was flaper87 that added a patch | 19:37 |
| tristanC | pabelanger: agreed, perhaps the operator (or the chart) shouldn't bother with db or zk. I find that a bit arbritary that the operator would manage the database but not the monitoring for example | 19:38 |
| corvus | the database is required | 19:38 |
| corvus | this is what we wrote about that: https://zuul-ci.org/docs/zuul/reference/developer/specs/kubernetes-operator.html#external-dependencies | 19:39 |
| pabelanger | https://review.opendev.org/660977/ was PR I was thinking of | 19:42 |
| corvus | even without that, combining ini files should not be difficult | 19:42 |
| pabelanger | yup, puppet had a module that would do that, seemed to work okay | 19:43 |
| pabelanger | looking at spec, I see spec.database and spec.connections but not a way to handle disk_limit_per_job or maybe read/write bindmounts | 19:45 |
| tristanC | pabelanger: zuul can template zuul.conf from environment since https://review.opendev.org/#/c/612824/ , which i think render https://review.opendev.org/660977/ less useful . I'm already using env templating to implement the zuul-operator external zookeeper or db-uri | 19:46 |
| pabelanger | merger might need git_user_email and git_user_name also | 19:46 |
| pabelanger | just looking at our zuul.conf file | 19:46 |
| corvus | yeah, i think we didn't consider that case well. adding explicit options, an args dict, or just passing through unrecognized options all seem like valid approaches. | 19:46 |
| tristanC | pabelanger: https://review.opendev.org/#/c/702105/6/conf/zuul/applications/Zuul.dhall@584 implements the spec.database and spec.connections option | 19:46 |
| pabelanger | I like args dict, that would be less churn on operator for exposing config settings over explicit options | 19:47 |
| tristanC | pabelanger: and merger git_user_email / name is already implemented here too: https://review.opendev.org/#/c/702105/6/conf/zuul/applications/Zuul.dhall@215 | 19:47 |
| pabelanger | tristanC: ack, I could see that approach being more work, to keep in sync with zuul.conf changes, but is something we've done before | 19:48 |
| openstackgerrit | Merged zuul/zuul-helm master: Added support for configuring disk_limit_per_job https://review.opendev.org/702963 | 19:48 |
| tristanC | corvus: should we replace the spec.connections by a scheduler.raw_config option? And when no db or zookeeper are provided, then the operator "inject" the setting in zuul.conf | 19:48 |
| openstackgerrit | Merged zuul/zuul-helm master: Add extra files for secret https://review.opendev.org/702965 | 19:48 |
| corvus | tristanC: it looks like it's already meant to be a pass-through. | 19:50 |
| tristanC | corvus: the spec does mention "Zuul files like /etc/nodepool/secure.conf and /etc/zuul/zuul.conf should be managed by the Operator and their options should be represented in the CRD." | 19:50 |
| corvus | also "Connections should each have a stanza that is mostly a passthrough representation of what would go in the corresponding section of zuul.conf." | 19:51 |
| tristanC | pabelanger: i don't mind either way, i would prefer we hide the zuul.conf details from the user, but it is more work indeed | 19:51 |
| pabelanger | tristanC: as example, reading change relative_priority is missing for scheduler, which we enable. | 19:51 |
| pabelanger | I think you have SSL change up for gearman? | 19:52 |
| tristanC | pabelanger: yes, it is: https://review.opendev.org/#/c/702716/4 | 19:52 |
| corvus | it's certainly possible for an operator to inspect and manipulate the options it needs (like the secrets) and just pass-through anything else unknown. we could also add each option explicitly. they don't change *that* often. | 19:53 |
| corvus | let's see if we can have another meeting on wednesday, come to some kind of agreement on the underlying technology, then dig into these problems :) | 19:54 |
| tristanC | corvus: right, so if we do that, then the spec needs a 'zuul_conf' secret config to enable the user to provide the zuul.conf content' | 19:55 |
| corvus | oh no no no | 19:55 |
| corvus | i outlined 3 options and none of them needed that | 19:55 |
| corvus | option 1: add each option explicitly to the zuul crd and copy it over (like mnaser just did in helm). option 2: add an args dict and copy its contents as the values (what i suggested for the helm charts earlier; i don't like this for the operator). option 3: just have the operator pass-through any options it doesn't recognize. | 19:57 |
| *** hashar has joined #zuul | 19:58 | |
| tristanC | for what it worth, i find that using a strict language like dhall or go, it's not too difficult to express the zuul.conf content structure, then it is easy to expose any settings (such as relative_priority) and let the user tune them safely. | 19:59 |
| corvus | yeah, that has advantages in validation too. | 20:00 |
| mnaser | btw, we can get away with templating all of the configuration variables in helm. You can see how I did it for “connections” | 20:00 |
| mnaser | The reason I did it for connections only was that it was predictable. I worried that reimplementing the entire config in ini and doing go trmplating for the whole file might introduce some weird things | 20:01 |
| corvus | is wednesday at 1600utc an okay time to have another call? | 20:01 |
| pabelanger | mnaser: where can one see that? | 20:01 |
| mnaser | It might totally be ok too. But again this is a fast moving target so none of the stuff we’re doing is something that I’d consider stable in terms of choices in helm implementation until we decide we have a “1.0.0” | 20:01 |
| mnaser | which means now is a good time to experiment and see if we wanna have the entire file in yaml converted to ini.. I think that’s cleaner than having a ini string blob | 20:02 |
| pabelanger | mnaser: I'm guessing you'd inspect driver value, then template based on that? | 20:02 |
| mnaser | pabelanger: mot really even more trivial | 20:03 |
| mnaser | https://opendev.org/zuul/zuul-helm/src/branch/master/charts/zuul/templates/secret.yaml#L28 | 20:03 |
| tristanC | corvus: i'd rather do that tuesday or later on wednesday please | 20:03 |
| corvus | mnaser, pabelanger: tuesday (tomorrow) 1600 utc okay? | 20:04 |
| pabelanger | I think I have a conflict, but should be able to join | 20:04 |
| mnaser | I don’t mind day but personally it would have to be after 1700 utc | 20:04 |
| mnaser | (I’m in Europe right now and I have stuff that pretty much goes all day) | 20:05 |
| tristanC | mnaser: how one is supposed to set the ssh key for a gerrit connection with that secret.yaml#L28 template? | 20:05 |
| corvus | mnaser: heh, i was going earlier to try to accomodate europe :) | 20:05 |
| corvus | tristanC: what's your earliest time on wednesday? | 20:05 |
| mnaser | tristanC: define extra files which would then mean they would appear in /etc/nodepool | 20:06 |
| mnaser | Yeah outside Europe business hours works better for me | 20:06 |
| pabelanger | mnaser: yah, that is kinda what corvus said for config options, just pass straigh through, no validation | 20:06 |
| pabelanger | I don't mind that approach | 20:07 |
| pabelanger | for us, rather then loop, we just did it directly in tempalte file: https://github.com/ansible-network/windmill-config/blob/master/zuul/zuul.conf.j2#L80 because older I get, harder to loop all the template stuff in brain :) | 20:07 |
| tristanC | corvus: i can do utc noon up to 1400 utc, then i have sprint review the whole morning | 20:07 |
| mnaser | ya I’m ok with doing that got the charts, but I’d want the config to be yaml rather than an ini you plop down | 20:08 |
| corvus | tristanC: oh i thought you said later on wed was ok | 20:08 |
| corvus | tristanC: so wed is completely out? | 20:09 |
| tristanC | corvus: up-to 1400 utc on wednesday, isn't that earlier than 1600 ? :) | 20:09 |
| corvus | tristanC: " corvus: i'd rather do that tuesday or later on wednesday please" is why i am confused | 20:09 |
| tristanC | mnaser: the issue with that secrets.yaml template is you have sync the secret mount path (or the file name) along with the zuul.conf entry | 20:10 |
| pabelanger | however, https://github.com/ansible-network/windmill-config/blob/master/ansible/group_vars/zuul-connections.yaml is how we added content to disk | 20:10 |
| pabelanger | which was loop'd | 20:10 |
| pabelanger | for SSH keys | 20:10 |
| tristanC | corvus: oops, later, or earlier on wednesay, i opt for earlier because of mnaser tz | 20:10 |
| corvus | mnaser requests > 1700 utc, so wed is incompatible | 20:11 |
| mnaser | yeah except it’s better for me to meet outside business hours, so the later for me, the better :p | 20:11 |
| corvus | so, tues 1700 or thurs 1700? | 20:11 |
| tristanC | pabelanger: that strategy has the same issue where you have to keep the zuul.conf content in sync with the secret definition | 20:11 |
| tristanC | corvus: tues and thurs both works for me | 20:11 |
| mnaser | tristanC: yeah but I’m mounting the secret as a directory, not a file. | 20:11 |
| mnaser | So any secrets within it appear inside the directory | 20:12 |
| corvus | mnaser: tues 1700 or thurs 1700? | 20:12 |
| mnaser | So it will always be in /etc/zuul | 20:12 |
| mnaser | corvus: let’s do Thursday 1700 | 20:12 |
| pabelanger | tristanC: yup, but that is limited to my local install. So, I am happy to break that if needed. I also find if easier now to look at final produced config file in git, over templated out onto running system | 20:13 |
| tristanC | mnaser: because we support multiple gerrits or githubs, then it's tricky to avoid file collision. For the operator spec, I used a directory per connection like so: https://review.opendev.org/#/c/702105/6/conf/zuul/applications/Zuul.dhall@343 | 20:13 |
| tristanC | where the key name defaults to `id_rsa`, but that can be overriden by the user | 20:13 |
| mnaser | tristanC: you could just have multiple files too? I tried not to make a lot of assumptions and let the user wire up things to their will | 20:13 |
| tristanC | mnaser: well yes, any secret can contains multiple files | 20:14 |
| mnaser | also the chart doesn’t actually have an understanding of a connection natively | 20:14 |
| mnaser | It’s just taking things pass through right now | 20:14 |
| mnaser | So In my case I have extra files defined with the private key, and then point the connection config to it | 20:15 |
| tristanC | what i meant is that the operator implementation doesn't expose to the user where the secrets are mounted on the container, thus the user can't mess with file name colission or bad file path | 20:15 |
| tristanC | which seems like a good thing to have, at the cost of a structured zuul.conf | 20:16 |
| pabelanger | we do it more like mnaser today, define where we want to ssh stored, and ansible creates it. Then we update zuul.conf data, to point to it | 20:23 |
| *** adam_g has joined #zuul | 20:23 | |
| mnaser | yeah, I agree on that. But the connection stuff are different from github to gerrit and I didn’t want to build the charts with certain baked in assumptions of the connection they use | 20:24 |
| mnaser | So yeah, took the more piped path | 20:24 |
| tristanC | that is simpler to manage for the confmgmt implementation, but that is not has been specified in the zuul-operator crd. | 20:24 |
| pabelanger | that's what I did with roles, I didn't want to manage that. Expose enough knobs for the user to do that, and if they wanted something finer, they could build atop of the role | 20:25 |
| tristanC | pabelanger: that way it's easier to implement but it also seems harder to use. iirc the goal of that operator is to make it easier to use zuul. | 20:30 |
| tristanC | i don't mind making the operator simpler, but we should update the spec to remove the 'secretName' attributes from the connections | 20:36 |
| pabelanger | tristanC: it pushes more work to operator (or next level up operator), and less to community to manage, for sure. Historically, I've found it easier myself to point to know file I create, then update config for it. I'm not sure what the right way moving forward is. | 20:37 |
| pabelanger | We are also at a point with zuul.a.c, were we don't really have to make many operations changes, so also kinda a step back on recent operations discussions. Mostly focused on onboarding new projects / users to zuul workflow, which is an effort in itself. :) | 20:38 |
| tristanC | pabelanger: i like how easy you can use the zuul cr as it is defined, but i get your need for fine-tuning, thus i don't mind either way. | 20:40 |
| tristanC | though i think the fear of having the same issues we had in the past with puppet or ansible templating does not applies where the config generator is using strict type. It can be safe to derive complex schemas and implement as many knobs as needed. | 20:43 |
| pabelanger | tristanC: for me, if we end up with something like https://opendev.org/opendev/puppet-zuul/src/branch/master/manifests/init.pp#L20 we've repeated history. https://opendev.org/opendev/puppet-openstackci was help help hide the interface to 3pci users, for most part worked, but was always a balance act between everybody | 20:46 |
| pabelanger | that's mostly why I like the args dict approach | 20:46 |
| pabelanger | not much business logic by default | 20:46 |
| tristanC | pabelanger: then i think we should drop the `secretName` attribute from the zuul cr spec, as it seems like it is what prevents the args dict approach. | 20:48 |
| corvus | i don't think that's necessary | 20:49 |
| pabelanger | I'm not familiar enough with CRDs honestly, so would defer to others | 20:49 |
| corvus | if we don't want to explicitly name every option, then i think the partial pass-through approach is fine | 20:50 |
| tristanC | corvus: how would you know user secrets needs to be mounted inside the zuul container? | 20:50 |
| tristanC | what* user secrets | 20:50 |
| corvus | tristanC: last paragraph of https://zuul-ci.org/docs/zuul/reference/developer/specs/kubernetes-operator.html#zuul-config | 20:52 |
| corvus | basically, the operator handles secrets. users never see a filename. | 20:53 |
| corvus | (that's an important part of how the operator takes care of administering the system) | 20:54 |
| tristanC | corvus: right, so if the operator handles secrets and manage their mount path, then I don't understand how the user can provide a raw zuul.conf, or args dict? | 20:55 |
| tristanC | unless the operator knows the structure of each connection, and be able to set the right sshkey path value | 20:56 |
| corvus | tristanC: right, which is why the spec does not have a facility for a user-supplied zuul.conf | 20:56 |
| corvus | and like i said earlier, i don't think we should have an args dict for the operator | 20:57 |
| tristanC | corvus: yes, and that's how i implemented the zuul-operator in topic:zuul-crd :) | 20:57 |
| corvus | yes, i'm pretty sure we agree here | 20:57 |
| corvus | i mean, that's the point of a spec, to get agreement on stuff like this | 20:58 |
| tristanC | corvus: oh, well i suggested to drop that secret management part of the spec based on pabelanger and mnaser feedback | 20:58 |
| corvus | i think pabelanger raises a good point that adding each option is annoying, but if we find that's the case, i think we can implement that via pass-through of unknown options | 20:59 |
| mnaser | fwiw I am not following the zuul operator in the charts | 20:59 |
| corvus | no change to the spec is required either way | 20:59 |
| mnaser | I think the operator and the charts are two different things imho | 20:59 |
| mnaser | One is just kubernetes application “packaging”, the other is fully fledged operator | 21:00 |
| mnaser | One strictly gets the application installed, the other one helps with the actual lifecycle and operations of it | 21:01 |
| tristanC | mnaser: the operator can also helps with the installation too, how would you create the gearman tls certs with helm? | 21:03 |
| mnaser | You don’t, you generate them elsewhere and point to them | 21:03 |
| mnaser | Helm isn’t supposed to make life “easier” but more of help package the common bits to get an app running. It’s far more “low level” | 21:04 |
| tristanC | mnaser: another big difference is that you can use operator by just applying kubernetes resources, for helm you need a cli and a place to generate runtime secrets | 21:04 |
| pabelanger | I figure, take my feedback with grain of salt, I don't really have too much time to help drive operator stuff. So deferring to others to drive it. :) Most of the stuff so far, is based on how I did it on zuul.a.c with playbooks and roles, which was heavily inspired based on how puppet-zuul and openstack-infra grew over the years. So far, the roles I created have had minimal (to none) changes to them related to | 21:04 |
| pabelanger | cfg settings, but they are also not the most user friendly. You do need to understand how ansible works. And like I mentioned, I'm really not a fan of having something do log of magic related to configuration, as each time I learn how it works and step away, I end up forgetting stuff each time. That's mostly why I like static cfg files these days | 21:04 |
| mnaser | For my use case, I prefer helm. I use Argo which templates and applies it | 21:05 |
| mnaser | I am not against an operator, but in my case, and probably some other users, that’s enough | 21:06 |
| mnaser | I think we should have both an operator and helm charts which are two distinct ways of deployment | 21:06 |
| mnaser | Just like how you can deploy Prometheus using an operator or simply use helm charts | 21:06 |
| corvus | i've been setting up these meetings in the hope of getting us all to agree on how to move the operator forward -- is everyone here actually willing to participate in that? | 21:08 |
| corvus | because i think i just say pabelanger and mnaser both say they aren't particularly interested in the operator | 21:08 |
| corvus | s/just say/just saw/ | 21:08 |
| pabelanger | I am intersted, I have zero time to help right now | 21:09 |
| corvus | pabelanger: you just spent 2 hours talking about it, are you sure "zero" is the right value? perhaps it's just "less than you would like"? | 21:10 |
| mnaser | corvus: I don’t presently have time to drive an operator, unfortunately given my huge time constraint, the charts are a reasonable stop gap to actually get zuul on kubernetes | 21:10 |
| mnaser | And even if I end up investing time into the operator eventually, I think I would still be happy to maintain the charts too for users who want them | 21:11 |
| mnaser | I think it is good for zuul to have two deployment options | 21:11 |
| corvus | i'm just trying to figure out if we're doing something productive here, or are we all wasting our time? | 21:11 |
| corvus | mnaser: i don't think you'd need to drive it | 21:11 |
| mnaser | I would love to migrate to an operator eventually personally | 21:12 |
| pabelanger | corvus: well, I am happy to talk while things compile, but I really haven't reviews any patches or tried the dhall or helm patches. So, happy to share POV, but taking a task item and completing, I really am tight on time. it would have to be after hours / weekends for me | 21:12 |
| mnaser | I just don’t think it would be operator vs helm | 21:12 |
| tristanC | mnaser: fwiw the current operator already get zuul on kubernetes | 21:12 |
| corvus | mnaser: okay, cool, that level of commitment is great. :) | 21:12 |
| pabelanger | corvus: however, with zuul.a.c working, migrating to new operator is lower priority, if I am being honest. | 21:12 |
| tristanC | mnaser: once the image is published, you could get a zuul by applying https://review.opendev.org/#/c/702106/15/deploy/crds/zuul-ci_v1alpha1_zuul_cr.yaml | 21:13 |
| mnaser | tristanC: that’s awesome, honestly, I haven’t had too much time to look into it. I’m sure a migration would be relatively trivial | 21:13 |
| mnaser | It’s just the time investment of moving to it right now is a lot for not much value right now. Once we have some of the really useful things we discussed, say like dumping and restoring queues on upgrade for example | 21:14 |
| mnaser | It starts to be far more valuable | 21:14 |
| corvus | pabelanger: your input is very welcome, including feedback on how much you would be able to contribute to each of the various options. | 21:15 |
| mnaser | But the time investment to pay right now based on how little I can find doesn’t drive huge benefit :( | 21:15 |
| tristanC | mnaser: alright, but that's a minor change, a task to dump before apply, then a a task to reload if the scheduler got restarted... | 21:15 |
| corvus | the main thing i just wanted to avoid is spending a bunch of time talking about operators, and ending up, once again, with a repo collecting dust. :) | 21:15 |
| tristanC | mnaser: there is also got to make it scale executor and merger on demand too, just need a bit of wiring up | 21:15 |
| mnaser | Yes, I don’t want that either. Something is better than nothing | 21:15 |
| tristanC | code* | 21:15 |
| mnaser | I spent a sizeable investment of time to get those helm charts up and running, so In terms of time | 21:17 |
| mnaser | Time planning, it would be a bit unproductive to spend a bunch more refactoring into the operator | 21:17 |
| mnaser | Given my current time constraints anyways | 21:18 |
| corvus | i also think the helm charts are valuable -- i think one of the ways to keep them so is to make them as "thin" as possible. i think pabelanger raised a good point earlier that adding options like the executor storage size is hard to manage/scale, so as we work on it, we may want to try to think about the best ways to minimize that. | 21:18 |
| mnaser | Ideally I would have spent that time on the operator, but writing one is far more complex and I believe at the time tristanC wasn’t working on it yet | 21:19 |
| corvus | and that plays to their strong point: just getting the app up and running like mnaser said, with the user supplying most everything it needs. | 21:19 |
| mnaser | I agree. As I started adding more values I realized just how this can become a pain over time | 21:19 |
| mnaser | So I’m actually in favour of refactoring it in order to actually have the config all yaml and templated into ini | 21:20 |
| mnaser | And I can work on that.. probably the next time I have to change a zuul config, I’ll probably just change it to take a config only | 21:20 |
| mnaser | Rather than implement the one thing I want to use | 21:21 |
| tristanC | corvus: we are very much interested in getting a zuul operator available, and i think the spec is almost completed now (beside things like the mqtt or pagure connections). | 21:25 |
| corvus | ++ | 21:25 |
| tristanC | i would be happy to investigate another framework such as kopf or golang, but if i'll be in the charge of the implementation, then i'd rather stick to what is known to work for the problem i explained previously | 21:27 |
| tristanC | (e.g. use dhall to generate the resources, and ansible to change the state) | 21:29 |
| corvus | tristanC: i'm worried that if we use dhall, you will be the only one able to either write or review changes. but if we go with kopf, then everyone working on zuul should be able to understand it. that seems like a big win to me, so i hope you'd be willing to consider that. | 21:30 |
| tristanC | corvus: kopf looks interesting, but i couldn't find any success stories, like not even one complete operator. | 21:35 |
| corvus | tristanC: didn't you invent the dhall operator? :) | 21:38 |
| tristanC | corvus: that's just a minor abstraction, the core come from the ansible operator-sdk and the https://github.com/dhall-lang/dhall-kubernetes | 21:39 |
| tristanC | which are both used successfully in other projects, to solve the same problem we are facing with zuul | 21:40 |
| tristanC | what i named `dhall operator`, is mostly that function: https://review.opendev.org/#/c/702104/6/conf/operator/deploy/Kubernetes.dhall , which i also implemented for pure ansible or podman compose script. but that's just using the kubernetes binding | 21:43 |
| zbr|drover | i have a set of simple fixes for zuul https://review.opendev.org//#/q/topic:zuuly+(status:open+OR+status:merged) -- lets merge them and move on. thanks. | 21:48 |
| hashar | zbr|drover: I was just about to wonder how to add support for py37 and others ;) | 21:50 |
| zbr|drover | not sure where my extra slash came from but underlined an interesting bug in zuul | 21:51 |
| zbr|drover | page loads but you cannot click any link. | 21:52 |
| zbr|drover | with correct number of slashes, it works https://review.opendev.org/#/q/topic:zuuly+(status:open+OR+status:merged) | 21:52 |
| fungi | bug in zuul? | 21:52 |
| zbr|drover | fungi: more or less | 21:53 |
| fungi | presumably you meant bug in (opendev's ancient) gerrit | 21:53 |
| mnaser | I agree regarding the sustainability factor of kopf fwiw | 21:53 |
| zbr|drover | aahh, right. | 21:53 |
| mnaser | But it seems pretty active and it seems to | 21:53 |
| zbr|drover | fungi: i would be very happy to see gerrit bumped | 21:53 |
| mnaser | Be maintained by a popular Swedish e-commerce which has been known to its open source work | 21:54 |
| mnaser | https://github.com/zalando is their main repo | 21:55 |
| tristanC | mnaser: and it seems like they are also using golang for https://github.com/zalando/postgres-operator | 21:58 |
| mnaser | Interesting | 21:59 |
| fungi | zbr|drover: yep, step 1 is our upcoming maintenance to swap out to container-deployed gerrit, then we can more easily migrate to newer builds (so... rsn) | 22:00 |
| *** jamesmcarthur has joined #zuul | 22:16 | |
| *** adam_g has quit IRC | 22:40 | |
| *** adam_g has joined #zuul | 22:43 | |
| *** hashar has quit IRC | 23:14 | |
| *** tosky has quit IRC | 23:51 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!