| opendevreview | Merged openstack/openstack-zuul-jobs master: Install fakeroot for openafs packaeg builds https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/935028 | 00:14 |
|---|---|---|
| cardoe | So fungi, I'm being told that dealing with tags is hard in gerrit? https://review.opendev.org/c/openstack/openstack-helm/+/934013 the convo there around versioning the tarballs. I want them to be immutable for each version while today they get rebuilt and the contents changes which magically breaks. | 00:50 |
| fungi | cardoe: that looks like a very long conversation. can you summarize what you mean by 1. "dealing with tags" and 2. "is hard in gerrit" | 01:01 |
| fungi | tags are quite easy in gerrit. create a signed tag in git, push it to gerrit, it replicates to all the git mirrors instantaneously | 01:03 |
| fungi | but maybe "dealing with tags" has some additional context i'm missing, and "is hard in gerrit" actually means "is hard in something else that's not gerrit but gerrit is the closest word i have for it"? | 01:04 |
| cardoe | So can I have one part push a tag and then trigger a job with that tag as the ref? | 01:05 |
| cardoe | I'm honestly learning zuul as I go right now. | 01:05 |
| fungi | yes, we have a "tag" pipeline in zuul which reacts to any tag that appears on a project | 01:06 |
| cardoe | I wanna actually setup something similar to what mnaser has done with vexxhost and atmosphere in zuul. | 01:06 |
| cardoe | But that's a different effort. | 01:06 |
| cardoe | Got a link handy for the tag pipeline? | 01:07 |
| fungi | what kind of link? a link to where it's defined in the openstack zuul tenant's configuration? | 01:07 |
| fungi | https://opendev.org/openstack/project-config/src/branch/master/zuul.d/pipelines.yaml#L306-L320 | 01:08 |
| fungi | the openstack tenant's pipelines are all defined in that file, for future reference | 01:09 |
| cardoe | Thank you. | 01:12 |
| fungi | the tag pipeline mainly gets used to run release notes jobs: https://zuul.opendev.org/t/openstack/builds?pipeline=tag&skip=0 | 01:12 |
| cardoe | While I've got ya... another thing I'm trying to do. | 01:12 |
| fungi | but could run basically anything that a project needs to trigger on arbitrary tags | 01:12 |
| cardoe | Yeah that'd be perfect. | 01:13 |
| cardoe | I'm trying to get some things into upstream without having a fork. | 01:13 |
| cardoe | Today we make a tag like "ironic-0.2.20" and it builds the ironic chart at version 0.2.20 and that's an immutable build. | 01:14 |
| cardoe | But the upstream repo would rebuild whatever version is in the Chart.yml, which everyone's patchset today must bump the version manually in Chart.yml which results in every patchset being a merge conflict with any other one submitted. | 01:15 |
| sean-k-mooney | out side fo the tarbars created for the tip of a git branch the tarbars on tarbars.openstack.org should not change content once they are created | 01:15 |
| cardoe | sean-k-mooney: that's absolutely my feeling and what I'm pushing for. | 01:16 |
| sean-k-mooney | no im saying that how it already works | 01:16 |
| sean-k-mooney | for brnahces we repalce the branch tarball when a commit meges | 01:16 |
| sean-k-mooney | for release tarbars created when we tag a branch its fixed | 01:16 |
| cardoe | So these tarballs are created by "helm package" | 01:16 |
| sean-k-mooney | you can have a job upload them as a side effect fo tagging a branch | 01:17 |
| sean-k-mooney | so normally we manage releases in genera via the release repo by specifying a git sha and a new verions number | 01:17 |
| cardoe | publish-openstack-helm-charts is the job | 01:18 |
| sean-k-mooney | for example https://github.com/openstack/releases/blob/master/deliverables/caracal/nova.yaml#L59-L84 | 01:19 |
| sean-k-mooney | those are all the release form the caral branch of nova | 01:19 |
| sean-k-mooney | taking the 29.2.0 tag this is the tarbal form that sha https://tarballs.opendev.org/openstack/nova/nova-29.2.0.tar.gz | 01:20 |
| fungi | yeah, basically don't increment values in a file in the git worktree because that is indeed a recipe for merge conflicts. instead increment values in the artifact (tarball or whatever) build | 01:20 |
| cardoe | Yeah that's what I'm trying to advocate for. | 01:21 |
| sean-k-mooney | from a git stcuture point of view we typically have a barnch per stable relase but then all version beyond that is done externally by selecting specific commits to be tagged releases | 01:22 |
| fungi | for similar reasons, we created pbr to allow us to manage python package versioning with git tags, so we stopped putting a hard-coded version string in a file in the git repo, and instead when packages (sdist tarballs, wheels) are built pbr grabs version info from the git tag and embeds it | 01:22 |
| cardoe | We're using GitHub right now and someone puts a label on the PR with either "Major" or "Minor" and if no label is applied then the default is "Patch". And we'll automatically tag the merge commit with the next number for that component and trigger building the helm chart | 01:22 |
| cardoe | I'm trying to convince OpenStack Helm PTL to adopt a similar approach. | 01:23 |
| cardoe | Because it gets rid of this conflict problem | 01:23 |
| cardoe | AND people will stop complaining about changing tarballs. | 01:23 |
| sean-k-mooney | it sound like the charts are not beeing versioned/released today | 01:23 |
| sean-k-mooney | in general you dont want every commit to be a release | 01:24 |
| fungi | yeah, pbr actually checks for footers in commit messages that indicate whether the next version should be a major or minor increment | 01:24 |
| sean-k-mooney | fungi: i tought that was reno | 01:24 |
| fungi | nope | 01:24 |
| fungi | reno doesn't choose versions, it just figures out what release notes go with them | 01:24 |
| cardoe | sean-k-mooney: so yeah... today OSH (OpenStack Helm) "releases" every change to every chart. | 01:25 |
| sean-k-mooney | huh ok we rarelly need to use it but we have used that ocationally in the past | 01:25 |
| cardoe | https://opendev.org/openstack/openstack-helm-infra/src/commit/6d7fba0c435e1299330b1c819854ca5f01b2f34f/zuul.d/jobs.yaml#L56 that's the job. | 01:25 |
| fungi | i'm specifically talking about pbr's pre-versioning functionality, where it guesses what the next version number is likely to be when creating dev version strings | 01:25 |
| sean-k-mooney | cardoe: ok then it does not have relase then | 01:25 |
| cardoe | The tarballs are a relatively new thing. | 01:25 |
| sean-k-mooney | at least not cordianted or planned release as would be done in most other projects | 01:25 |
| cardoe | Before that you were suppose to git clone openstack-helm and openstack-helm-infra next to each other. | 01:26 |
| cardoe | run "make" inside of -infra and then in the main project. | 01:26 |
| cardoe | which built the charts for you locally and then you could install from that. | 01:26 |
| sean-k-mooney | it sound like that may have been better | 01:27 |
| sean-k-mooney | because then you coudl pin via sha deterministically | 01:27 |
| sean-k-mooney | cardoe: in anycase it shoudl be possibel to do what you want to do | 01:28 |
| fungi | sean-k-mooney: https://docs.openstack.org/pbr/latest/user/features.html#version | 01:28 |
| cardoe | True. But I'll just say that's not a pattern that any helm user would expect. | 01:28 |
| sean-k-mooney | if you really want to release every commit and have ti be stabel the main limitation i see is storage. the only reasonable way to od that is relaly git and generate the tar on demand | 01:28 |
| cardoe | The built charts also had the paths embedded unfortunately. | 01:28 |
| cardoe | I don't wanna release every commit | 01:28 |
| cardoe | I think we should have releases and tests. | 01:29 |
| cardoe | Which is the other thing I wanna do with Zuul. | 01:29 |
| cardoe | Start testing Flex deployment stuff. | 01:29 |
| sean-k-mooney | fungi: yep im famiarl with that feature | 01:29 |
| sean-k-mooney | fungi: we use it rarely but i have seen it used in the past | 01:30 |
| fungi | right, just putting it in context as to what's actually using it | 01:30 |
| sean-k-mooney | cardoe: so zuul is certelly capable of helping you achive that testing goal | 01:30 |
| sean-k-mooney | but kep in mind its really just an ansible executor copuled with a test host provider manager | 01:30 |
| cardoe | Right now I'm trying to help the OSH project achieve regular helm releases. | 01:31 |
| sean-k-mooney | i.e. zuul helps you find a place to execute your ansible drven testing | 01:31 |
| sean-k-mooney | how you use that and what you have it do is really up to you | 01:31 |
| cardoe | yeah which makes sense. Just need to educate myself on it. | 01:31 |
| sean-k-mooney | cardoe: it sound like your problems are more social then technialcal | 01:32 |
| cardoe | I won't disagree | 01:32 |
| sean-k-mooney | my personally suggestion would be to try moving to a release with intermedary model | 01:33 |
| sean-k-mooney | i.e. do at least one release per openstack release with intermediary releasas at a regular cadnace | 01:33 |
| cardoe | That would be reasonable. | 01:34 |
| fungi | though whether or not the project wants to maintain stable branches and make separate stable point releases should probably also factor into the release model choice | 01:34 |
| cardoe | They don't want any branches. | 01:34 |
| sean-k-mooney | you dont need to have them | 01:35 |
| * fungi double-checks whether cycle-with-intermediary comes with a stable branch expectation | 01:36 | |
| sean-k-mooney | but without them you do need to comunicate and manager the versions of opentack that a given helm chart can deploy | 01:36 |
| cardoe | https://opendev.org/openstack/openstack-helm/src/branch/master/keystone/values_overrides so like that has the different OpenStack releases with their configs. | 01:36 |
| sean-k-mooney | fungi: i belive you can confirue that sepreatly | 01:36 |
| cardoe | That's not really normal in the helm world. | 01:36 |
| sean-k-mooney | fungi: many of the tempest plugins use that but set branch none | 01:36 |
| cardoe | The project has its own helm wrapper | 01:36 |
| cardoe | Ultimately looking to make it possible to consume the project from normal helm tooling. | 01:37 |
| sean-k-mooney | cardoe: in case your unfamilar with the terms we are refering to https://github.com/openstack/releases/blob/7eabe5c2e6e9d8a50d970e52c49bd3866464adbb/doc/source/reference/release_models.rst#cycle-with-intermediary | 01:37 |
| fungi | sean-k-mooney: ah, cool, i didn't realize release model and stable branch creation were decoupled. good to know | 01:37 |
| cardoe | Yeah that would make sense. | 01:37 |
| fungi | https://releases.openstack.org/reference/release_models.html | 01:39 |
| sean-k-mooney | https://github.com/openstack/releases/blob/7eabe5c2e6e9d8a50d970e52c49bd3866464adbb/deliverables/epoxy/tempest.yaml#L4-L7 | 01:39 |
| fungi | for the published version | 01:39 |
| cardoe | So another thing I'm trying to do. Hook into the openstack-docs job and generate some rst files before hand. | 01:39 |
| fungi | cardoe: you can do that by creating sphinx extensions | 01:39 |
| sean-k-mooney | tempest is the exmaple i normally poitn to for cycle-with-intermediary but no stable branch | 01:39 |
| cardoe | I've started to make a change to zuul/zuul-jobs to install "helm-docs" | 01:39 |
| fungi | we have several examples of projects that generate rst files from yaml during docs builds | 01:39 |
| sean-k-mooney | the release notes jobs are a prime example but all of our docs are in rst format built with sphinx | 01:40 |
| fungi | https://opendev.org/openstack/ossa/src/branch/master/doc/source/_exts is what generates the rst files for our security advisories on security.openstack.org, for example | 01:40 |
| sean-k-mooney | we normlay get lazy and jus tuse tox to run them using it as a glorifed make | 01:40 |
| sean-k-mooney | oh your talki8ng about custom generation | 01:41 |
| sean-k-mooney | ya many repos have custom extenions like https://github.com/openstack/nova/tree/master/doc/ext | 01:41 |
| fungi | yeah, we do similar things in the governance and election repos too | 01:41 |
| cardoe | so like https://review.opendev.org/c/openstack/openstack-helm/+/934698 | 01:42 |
| cardoe | If you ran "helm-docs --output-file=doc/source/chart/ironic.rst --template-files=ironic/helm.rst.gotmpl ironic" at the top-level it would generate that ironic.rst | 01:42 |
| sean-k-mooney | like this https://github.com/openstack/nova/blob/master/tox.ini#L209-L222 | 01:43 |
| sean-k-mooney | we have a standard project testing interface that specifys we shoudl provide a tox docs target that will generate html documenation | 01:44 |
| cardoe | oh. I didn't realize that tox was called to generate the docs. | 01:44 |
| sean-k-mooney | then a standard shared job that runs on each commit to generate the docs an make them avialbe to review in a docs preview site | 01:44 |
| cardoe | That makes this easier. | 01:45 |
| cardoe | So should I add the install of helm-docs to zuul/zuul-jobs? | 01:45 |
| sean-k-mooney | cardoe: you can generate them with out it but we use tox so that we can code it once and run it locally or in the ci | 01:45 |
| cardoe | And then somehow depend on that? | 01:45 |
| sean-k-mooney | is helm-docs a python package or is it installed some other way | 01:45 |
| sean-k-mooney | ah go | 01:46 |
| sean-k-mooney | https://github.com/norwoodj/helm-docs | 01:46 |
| cardoe | It's a Go thing | 01:46 |
| cardoe | Yeah | 01:46 |
| fungi | add it to a docs profile in bindep.txt then | 01:46 |
| fungi | assuming there's a distro package of it | 01:46 |
| sean-k-mooney | https://github.com/openstack/nova/blob/master/bindep.txt#L13-L14 | 01:46 |
| sean-k-mooney | is an example of that | 01:46 |
| cardoe | I copied how chart-testing was being installed in zuul/zuul-jobs | 01:46 |
| sean-k-mooney | so with go you would often use make files | 01:47 |
| sean-k-mooney | so what i would do if that is what you are usign is create a make file to download and isntall the deps using go get and buidl the docs | 01:47 |
| sean-k-mooney | then write a zuul job that just calls that make target | 01:48 |
| cardoe | https://opendev.org/zuul/zuul-jobs/src/commit/d2d25cd9ec807d62b1bb4eb3395983b8b2eaea41/roles/ensure-chart-testing/tasks/main.yaml#L13-L18 | 01:48 |
| cardoe | That's what I copied | 01:48 |
| sean-k-mooney | do you have a link to the chart repo | 01:48 |
| sean-k-mooney | i guess https://github.com/openstack/openstack-helm/blob/master/nova/Chart.yaml | 01:49 |
| sean-k-mooney | ok ya https://github.com/openstack/openstack-helm/blob/master/Makefile | 01:49 |
| sean-k-mooney | and htat has tox too https://github.com/openstack/openstack-helm/blob/master/tox.ini | 01:49 |
| sean-k-mooney | with some docs suport https://github.com/openstack/openstack-helm/blob/master/tox.ini#L16-L24 | 01:49 |
| cardoe | https://review.opendev.org/c/zuul/zuul-jobs/+/935030 | 01:50 |
| sean-k-mooney | cardoe: so that works but the disadvantage to that approch si repoducing it locally is harder | 01:50 |
| cardoe | I can go the bindeps route. | 01:51 |
| cardoe | I was just sharing what I had already started. | 01:51 |
| sean-k-mooney | also cloning (donwloading in this case) in a ci job is kind of an antipattern | 01:51 |
| cardoe | It's not cloning. It's downloading a pre-built binary. | 01:51 |
| sean-k-mooney | yes but that is going out onto the internet | 01:52 |
| sean-k-mooney | whic for an active project will fail randomly | 01:52 |
| sean-k-mooney | so while that works without caching proxies | 01:52 |
| sean-k-mooney | you need to be carful | 01:52 |
| cardoe | So there's no dep on "helm" in the openstack-helm project | 01:52 |
| cardoe | So that's how I came to where they're getting the binary | 01:53 |
| cardoe | Happy to do it better. | 01:53 |
| sean-k-mooney | well we have some caching proxies | 01:53 |
| sean-k-mooney | at the provider clouds | 01:53 |
| cardoe | I mean tests fail today cause they hit docker hub rate limits too | 01:53 |
| sean-k-mooney | but if this is somehting needed in every patch it might be worth including it in the base image we boot | 01:53 |
| sean-k-mooney | and only donwloading it if its not present | 01:54 |
| sean-k-mooney | right there are solution to that too | 01:54 |
| sean-k-mooney | cardoe: in what casses are you hitting the ratelimit? | 01:54 |
| sean-k-mooney | kolla had similar problems | 01:54 |
| sean-k-mooney | infra also have playbooks to provide tempory registries for the jobs | 01:55 |
| fungi | if you can get things you need from official in-distro packages, we have our own mirrors of those located in each ci node provider. if you can get things from dockerhub/quay, npm or pypi then we have caching proxies the nodes can pull them through | 01:57 |
| fungi | (technically the distro package mirrors are caches in each provider, but backed by a network filesystem) | 01:57 |
| sean-k-mooney | so for helm buidl i woudl personnaly use go get to instlal that via the proxy | 01:58 |
| cardoe | They're grabbing the library nginx I think | 01:58 |
| fungi | what proxy is go get using? | 01:58 |
| sean-k-mooney | fungi: its configurable | 01:58 |
| sean-k-mooney | via an env var | 01:59 |
| cardoe | So at this point I'm just trying to help the upstream project. | 01:59 |
| cardoe | But needing to slowly introduce some change. | 01:59 |
| fungi | sean-k-mooney: i literally mean where is the proxy for go get? i don't think we maintain one | 01:59 |
| sean-k-mooney | fungi: oh i dont think we do either but a normally http proxy woudl work | 02:00 |
| fungi | yeah, we can't really do wide-open proxies because we don't control what ip addresses the job nodes get | 02:00 |
| sean-k-mooney | so https://opendev.org/zuul/zuul-jobs/src/commit/d2d25cd9ec807d62b1bb4eb3395983b8b2eaea41/roles/configure-mirrors/defaults/main.yaml | 02:01 |
| sean-k-mooney | configure the http/https proxy vars corect | 02:01 |
| fungi | configure them to what though? | 02:01 |
| sean-k-mooney | there is a shared comunity go proxy | 02:01 |
| fungi | i guess that's a separate service that we'd run? | 02:02 |
| sean-k-mooney | https://proxy.golang.org | 02:04 |
| fungi | right now the stuff we're running caching web proxies for (quay/dockerhub, pypi, npm...) are just apache mod_proxy rules | 02:04 |
| sean-k-mooney | so the way gos packaging works is all impaort are urls to the the git repos | 02:04 |
| fungi | oh, you're saying we could tell apache mod_proxy to proxy connections to proxy.golang.org | 02:04 |
| sean-k-mooney | yep | 02:04 |
| fungi | that seems doable, sure | 02:05 |
| sean-k-mooney | so in go an import looks like this https://github.com/openstack-k8s-operators/nova-operator/blob/main/api/v1beta1/common_types.go#L22 | 02:05 |
| sean-k-mooney | i.e. its the url to the moduel on a git repo | 02:05 |
| sean-k-mooney | but instead of going to github directlly to get "github.com/openstack-k8s-operators/lib-common/modules/common/util" | 02:06 |
| sean-k-mooney | go get uses https://proxy.golang.org to get that which allow you to do versioning via a seprate go mod file | 02:06 |
| sean-k-mooney | like this https://github.com/openstack-k8s-operators/nova-operator/blob/main/go.mod#L15 | 02:07 |
| sean-k-mooney | so go get takes the reqiuried deps form yoru go mod file and download the speficed version via the poxy when enabled | 02:07 |
| sean-k-mooney | go install does the same thing but compiels and installs the resultign binary into yoru go bin path | 02:08 |
| sean-k-mooney | cardoe: anyway at this point im proably not helpign any more | 02:09 |
| sean-k-mooney | cardoe: as i siadi i woudl be inllined to extedn teh make file to have target to install helm-docs and use it to buidl the docs | 02:11 |
| sean-k-mooney | then just have zuul invoke that because it allwos you to test it the same way locally | 02:11 |
| fungi | if having local caching proxies of proxy.golang.org would help job stability, it's probably not contentious for us to add one. it would go in https://opendev.org/opendev/system-config/src/branch/master/playbooks/roles/mirror/templates/mirror.vhost.j2 | 02:12 |
| sean-k-mooney | the pattern we have been using for the k8s oeprator work is to have tagest to install each fo the test tools (envtest is the fake k8s api standind and ginkgo is the test runner) https://github.com/openstack-k8s-operators/nova-operator/blob/main/Makefile#L233-L242 and then the make test target just depend on the tool install target | 02:14 |
| sean-k-mooney | https://github.com/openstack-k8s-operators/nova-operator/blob/main/Makefile#L145-L149 | 02:14 |
| sean-k-mooney | then the ci can basicaly jsut cd to the correct directory and run "make test" | 02:15 |
| cardoe | yeah those operators are interesting unfortunately openshift only | 02:24 |
| sean-k-mooney | in theory you might be able to make them work on vaniala k8s but ya that kidn of unfortuente at the momemtn | 02:25 |
| sean-k-mooney | the only direct dep on openshift really is it uses routes instead of ingress by default | 02:25 |
| sean-k-mooney | there has not really been any effort ot make it work on non openshift k8s deployments | 02:25 |
| *** darmach688 is now known as darmach68 | 11:59 | |
| opendevreview | Tae Park proposed openstack/project-config master: Add repo app-openbao for starlingx https://review.opendev.org/c/openstack/project-config/+/935154 | 14:49 |
| opendevreview | Merged openstack/project-config master: Use 2024.2 constraints in master translation jobs https://review.opendev.org/c/openstack/project-config/+/934402 | 16:13 |
| opendevreview | Merged openstack/project-config master: Add separate acl group for watcher-tempest-plugin https://review.opendev.org/c/openstack/project-config/+/934357 | 16:13 |
| opendevreview | Merged openstack/project-config master: Update more ironic project ACLs for editHashtags https://review.opendev.org/c/openstack/project-config/+/935022 | 16:13 |
| opendevreview | Merged openstack/project-config master: Add repo app-openbao for starlingx https://review.opendev.org/c/openstack/project-config/+/935154 | 17:10 |
| cardoe | sean-k-mooney / fungi / clarkb: Just to show ya how much I'm trying with this.... https://review.opendev.org/c/openstack/openstack-helm/+/935019 you see how many recheck's I had to run? The ironic bits aren't touched or looked at in the current checks/gates. | 19:31 |
| clarkb | cardoe: do you know what is failing? | 19:34 |
| sean-k-mooney | it looks like diffent failure in diffent runs just lookign at the passign /failing jobs | 19:40 |
| sean-k-mooney | one as a container pull form docker io | 19:41 |
| sean-k-mooney | so that proably just the rate limiting | 19:41 |
| sean-k-mooney | thre are undfiend atribute error in other but i have never looked at these before so not sure why and or how it got fixed | 19:42 |
| clarkb | we have a docker hub caching proxy too which if not used may be helpful | 19:43 |
| sean-k-mooney | so the kubespary job https://zuul.opendev.org/t/openstack/build/d839dfba45364013b2ba21bc03d497ec | 19:44 |
| sean-k-mooney | looks like that going direct | 19:44 |
| sean-k-mooney | or if not dirfect then its not working but i would assume they just have not set that up | 19:44 |
| sean-k-mooney | looks like that a new job as of september | 19:45 |
| sean-k-mooney | https://github.com/openstack/openstack-helm/commit/aa3a6c489e7aedba8f20905dc400777afe1a2a75 | 19:45 |
| cardoe | sorry got a phone call. | 19:47 |
| cardoe | but yeah you guys nailed it. it's an assortment of failures. | 19:47 |
| cardoe | I have NO idea how the attribute errors got fixed. | 19:48 |
| sean-k-mooney | im going to prethend that job is not just a bunch fo random bash scripts https://github.com/openstack/openstack-helm/blob/a556dbe2320faf28a6badc6869002970c9082c99/zuul.d/base.yaml#L109-L133 | 19:48 |
| sean-k-mooney | it looks like they never actully spend time making them into real zuul v3 jobs | 19:49 |
| sean-k-mooney | you proably coudl imporve the stablity at least on the docker side by enabling the docker proxy here 9 | 19:51 |
| sean-k-mooney | https://github.com/openstack/openstack-helm/blob/a556dbe2320faf28a6badc6869002970c9082c99/tools/gate/playbooks/prepare-hosts.yaml#L6 | 19:51 |
| sean-k-mooney | which i htink is just adding https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/use-docker-mirror | 19:52 |
| sean-k-mooney | clarkb: ^ is that the correct role | 19:52 |
| sean-k-mooney | docker proably is not isntalled there so you migh need to do that here https://github.com/openstack/openstack-helm/blob/a556dbe2320faf28a6badc6869002970c9082c99/tools/gate/playbooks/deploy-env-kubespray.yaml#L136 | 19:54 |
| sean-k-mooney | instead | 19:54 |
| opendevreview | Merged openstack/openstack-zuul-jobs master: Update CentOS 9 Stream OpenAFS package to 1.8.13 https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/934989 | 19:54 |
| clarkb | sean-k-mooney: yes I think that is the right role | 19:56 |
| sean-k-mooney | cardoe: the stablity issues you hit are not nessiarly caused byt the packaging of the helml charts today | 19:57 |
| sean-k-mooney | that might be a factor but the ci jobs need carful maintaince | 19:57 |
| sean-k-mooney | i suspect that some of this is bitrot | 19:57 |
| sean-k-mooney | but i also dont have personal knowladge of the health of the openstack-helm proejct in general | 19:58 |
| sean-k-mooney | cardoe: overall https://zuul.opendev.org/t/openstack/builds?project=openstack%2Fopenstack-helm&skip=0 does not actully look that bad | 20:00 |
| sean-k-mooney | but with 15 jobs if you have even a little instablity in them it will be hard for any patch to pass twice so that it can merge | 20:01 |
| cardoe | well you guys have given me a good todo list | 23:35 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!