| -@gerrit:opendev.org- Tristan Cacqueray proposed: [zuul/zuul-operator] 845851: Update CRD apiVersion to v1 (from v1beta) https://review.opendev.org/c/zuul/zuul-operator/+/845851 | 00:25 | |
| @geethree:matrix.org | Hey folx. | 01:34 |
|---|---|---|
| SHould the zuul-operator work as is? Using... | ||
| ``` | ||
| apiVersion: operator.zuul-ci.org/v1alpha2 | ||
| kind: Zuul | ||
| metadata: | ||
| name: zuul | ||
| spec: | ||
| imagePrefix: ndex.docker.io/zuul | ||
| ``` | ||
| And seeing .. | ||
| ``` | ||
| gerald@gerald-laptop:~/skydio/repos/skyops/services/cicd/zuul$ kubectl logs job/create-database | ||
| mysql: [Warning] Using a password on the command line interface can be insecure. | ||
| ERROR 2003 (HY000): Can't connect to MySQL server on 'db-cluster-haproxy:3306' (111) | ||
| ``` | ||
| @geethree:matrix.org | I am able to connect to the database directly by starting an ephemeral pod installing mysql-client and running the command that is specified in the job 🤔 | 01:39 |
| -@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] 810955: GUI: Add tenant dropdown to top menu https://review.opendev.org/c/zuul/zuul/+/810955 | 08:06 | |
| @mhuin:matrix.org | > <@gerrit:opendev.org> James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 847856: Use attributes instead of a nested dict for web cache https://review.opendev.org/c/zuul/zuul/+/847856 | 08:09 |
| corvus: once this one gets merged WDYT of https://review.opendev.org/c/zuul/zuul/+/810955 ? This is nice to have on multi-tenants deployments, it saves you a click when switching status pages from tenant to tenant | ||
| -@gerrit:opendev.org- Zuul merged on behalf of Matthieu Huin https://matrix.to/#/@mhuin:matrix.org: [zuul/zuul] 832293: REST API: cache tenants list https://review.opendev.org/c/zuul/zuul/+/832293 | 09:30 | |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 847856: Use attributes instead of a nested dict for web cache https://review.opendev.org/c/zuul/zuul/+/847856 | 09:36 | |
| -@gerrit:opendev.org- Rajesh Tailor proposed: [zuul/zuul] 847946: Fix typo from 'execption' to 'exception' https://review.opendev.org/c/zuul/zuul/+/847946 | 10:39 | |
| @jrosser:matrix.org | Clark: here is my change to ARA to make it query Zuul for sqlite files https://github.com/ansible-community/ara/compare/master...jrosser:ara:zuul-sqlite | 11:37 |
| -@gerrit:opendev.org- Tristan Cacqueray proposed: [zuul/zuul-operator] 845851: Update CRD apiVersion to v1 (from v1beta) https://review.opendev.org/c/zuul/zuul-operator/+/845851 | 11:38 | |
| @tristanc_:matrix.org | Gerald: what's the status of the other pods? | 11:39 |
| -@gerrit:opendev.org- Tristan Cacqueray proposed: [zuul/zuul-operator] 845851: Update CRD apiVersion to v1 (from v1beta) https://review.opendev.org/c/zuul/zuul-operator/+/845851 | 12:19 | |
| -@gerrit:opendev.org- Tristan Cacqueray proposed: [zuul/zuul-operator] 845851: Update CRD apiVersion to v1 (from v1beta) https://review.opendev.org/c/zuul/zuul-operator/+/845851 | 13:33 | |
| -@gerrit:opendev.org- Tristan Cacqueray proposed: [zuul/zuul-operator] 847978: Remove gearman configuration https://review.opendev.org/c/zuul/zuul-operator/+/847978 | 14:03 | |
| -@gerrit:opendev.org- Tristan Cacqueray proposed: [zuul/zuul-operator] 845851: Update CRD apiVersion to v1 (from v1beta) https://review.opendev.org/c/zuul/zuul-operator/+/845851 | 15:35 | |
| @tristanc_:matrix.org | corvus: it seems like [OLM](https://olm.operatorframework.io/docs/getting-started/) can be used to declare dependency on external CRD (such as cert-manager or pxc). Would you mind using that for the zuul-operator? | 16:01 |
| @tristanc_:matrix.org | and then, the zuul-operator could define the so-called CSV resource so that it can be added to an operator catalog. That way, dependencies installation would be taken care of by the OLM | 16:05 |
| @jim:acmegating.com | tristanC: the installation process for olm looks a little weird (like, you have to download a binary and run it?) -- it seems like that would be an extra hurdle for zuul-operator users? | 16:06 |
| @jim:acmegating.com | tristanC: maybe it could be optional? i think we already have flags to indicate the other operators aren't necessary... | 16:08 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 846445: Add ssh_server option to Gerrit driver https://review.opendev.org/c/zuul/zuul/+/846445 | 16:08 | |
| @tristanc_:matrix.org | corvus: it does look a little weird. but this may be better than vendoring the dependency. In particular, to support recent kubernetes, we need to use the new apiVersion, which means the zuul-operator now has to udpate the other operators. pxc is optional, but not cert-manager. | 16:12 |
| @jim:acmegating.com | tristanC: if we used olm, what would cause cert-manager to be upgraded? | 16:15 |
| @sean-k-mooney:matrix.org | you install olm via the operator sdk | 16:16 |
| @sean-k-mooney:matrix.org | its mainly intended for openshift use | 16:16 |
| @jim:acmegating.com | sean-k-mooney: yeah, it's a pretty weird way to install something for k8s. | 16:16 |
| @sean-k-mooney:matrix.org | i assume the zuul operator should also work with k8s | 16:16 |
| @jim:acmegating.com | sean-k-mooney: yes, we target plain k8s | 16:17 |
| @tristanc_:matrix.org | sean-k-mooney: it seems like you can deploy olm on k8s though | 16:17 |
| @sean-k-mooney:matrix.org | i can | 16:17 |
| @sean-k-mooney:matrix.org | *it can | 16:17 |
| @sean-k-mooney:matrix.org | but not sure how well that is tested | 16:17 |
| @sean-k-mooney:matrix.org | i really dont know enough about it | 16:18 |
| @sean-k-mooney:matrix.org | i belive there are some limiations around upgrade | 16:18 |
| @sean-k-mooney:matrix.org | can you currently have multiple versions fo the zuul operator installed on the same k8s in differnt namespaces? | 16:19 |
| @tristanc_:matrix.org | corvus: zuul will define a required crd that way https://olm.operatorframework.io/docs/tasks/creating-operator-manifests/#required-apis , and i assume OLM will take care of installing the necessary resources | 16:19 |
| @sean-k-mooney:matrix.org | because i belive olm has issues with that | 16:19 |
| @jim:acmegating.com | tristanC: and olm will handle upgrading pxc, for example, when required apis change? | 16:20 |
| @tristanc_:matrix.org | sean-k-mooney: that's actually part of the issue we are facing integrating the zuul-operator, it presently does not support namespaced installation, there can only be one operator for the whole cluster. Looking at OLM specification, it seems like it enables managing such setting | 16:20 |
| @tristanc_:matrix.org | corvus: that's what it says on the website yes | 16:21 |
| @sean-k-mooney:matrix.org | olm does not support namespaced installation either | 16:21 |
| @sean-k-mooney:matrix.org | at least that was the feedback i was given when i asked if we could use namespaces for ci | 16:21 |
| @sean-k-mooney:matrix.org | e.g. 1 namespace per job | 16:21 |
| @sean-k-mooney:matrix.org | the answer i got was olm does not supprot that properly | 16:22 |
| @tristanc_:matrix.org | sean-k-mooney: i meant OLM can install operator per namespace. I guess OLM installation needs to be cluster wide | 16:22 |
| @sean-k-mooney:matrix.org | my understding is it can technially install things in a namespace | 16:23 |
| @sean-k-mooney:matrix.org | but i was told the operator it installs would also have to be cluser wide if you want the dep management to work | 16:23 |
| @jim:acmegating.com | tbh, i don't think namespaced zuul-operator is a use case that we intended to support | 16:24 |
| @tristanc_:matrix.org | sean-k-mooney: according to the install metadata, you can define multiple install mode, e.g. `OwnNamespace`, `SingleNamespace`, `MultiNamespace` or `AllNamespaces` | 16:24 |
| @sean-k-mooney:matrix.org | again im just relaying info i was given i have not validated it but i was specificly told the openstack operators we are pocing would need to be custler wide due to olm limitations | 16:24 |
| @sean-k-mooney:matrix.org | corvus ack | 16:25 |
| @sean-k-mooney:matrix.org | my usecause for it was ci | 16:25 |
| @tristanc_:matrix.org | corvus: we are presently developing operators on a shared cluster, and not being able to run different version of the zuul-operator is problematic | 16:25 |
| @sean-k-mooney:matrix.org | so set up one openshift and then have zuul test operators in differnt namespaces | 16:25 |
| @sean-k-mooney:matrix.org | tristanC: if you figure out how to do it with olm please let me know | 16:26 |
| @sean-k-mooney:matrix.org | i would like to be able to test https://github.com/openstack-k8s-operators/keystone-operator and the other olm based operators on a shared cluster but we are not sure that will be possible currently | 16:27 |
| @tristanc_:matrix.org | sean-k-mooney: here is the coumentation i was planning to follow: https://olm.operatorframework.io/docs/tasks/install-operator-with-olm/#example-install-the-latest-version-of-an-operator | 16:27 |
| @jim:acmegating.com | i would think whether zuul-operator can coexist with multiple versions probably has more to do with how it's written than olm itself. it's receiving events from k8s and they would need to be filtered appropriately. also, different versions of the crd would presumably be an issue. | 16:30 |
| @jim:acmegating.com | tristanC: zuul-operator will only install cert-manager if it isn't already installed. | 16:31 |
| @jim:acmegating.com | tristanC: it seems like it should be possible to use olm with zuul-operator as currently written with few changes, as long as the pre-reqs are installed first. that might be worth experimenting with and seeing how that works? then we can decide if we want to rely on it, or just keep it as an optional install method? | 16:32 |
| @tristanc_:matrix.org | corvus: great, i'll try that path, and if it works as expected, than i think we should support it, and perhaps remove the vendored resources for pxc and cert-manager | 16:33 |
| @jim:acmegating.com | tristanC: i agree that's worth considering -- but i'd really like to see how that looks for an end user first. i'm very concerned about the whole "download and run the operator-sdk" method of installation. i'm not sure that's going to be palatable for a lot of folks. | 16:35 |
| @tristanc_:matrix.org | corvus: to make the zuul-operator stay in a single namespace, i think we only need that change: https://review.opendev.org/c/zuul/zuul-operator/+/847790 | 16:35 |
| @jim:acmegating.com | tristanC: maybe once you have a demo, it's worth a mailing list thread to evaluate it? | 16:35 |
| @sean-k-mooney:matrix.org | i think there are other ways to install it | 16:36 |
| @sean-k-mooney:matrix.org | its pre installled on openshift | 16:36 |
| @jim:acmegating.com | tristanC: yes, that namespace change was along the lines of what i was thinking. but there are caveats there; i'll leave comments. | 16:36 |
| @sean-k-mooney:matrix.org | but olm adds a lot of stuff to your deplooyment | 16:36 |
| @tristanc_:matrix.org | corvus: i'm very concerned how the dependencies are presently managed, and upgrading from v1beta to v1 might become a lot of work without OLM, see my attempts in https://review.opendev.org/c/zuul/zuul-operator/+/845851 | 16:36 |
| @jim:acmegating.com | tristanC: what specifically is the problem? and how does olm help? | 16:45 |
| @jim:acmegating.com | tristanC: it looks like you're doing something unusual with the pxc operator -- according to https://www.percona.com/doc/kubernetes-operator-for-pxc/kubernetes.html the latest version is 1.11.0 and it still has crd.yaml and operator.yaml files (i don't see a bundle.yaml) | 16:52 |
| @jim:acmegating.com | but https://zuul.opendev.org/t/zuul/build/85f9837517534662828c0718347e2d58/log/docker/k8s_percona-xtradb-cluster-operator_percona-xtradb-cluster-operator-5d7bdc54d-dtqcc_default_e6977ab5-b3fa-4c60-be04-a2a805b35dad_0.txt says something about version 1.12.0 | 16:53 |
| @jim:acmegating.com | so maybe roll that back to 1.11.0? | 16:53 |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 848014: Report timing info for POST_FAILURE and TIMED_OUT builds https://review.opendev.org/c/zuul/zuul/+/848014 | 16:56 | |
| @jim:acmegating.com | anyway, i like the idea of olm, but i'd like to be certain that (a) it actually provides more functionality than what we're already doing by just vendoring in some static yaml files; and (b) it's not difficult for users to install and maintain. i think those are the things we need to analyze before we decide to remove the internal dependency support. however, i think it's entirely sensible to optionally support olm even if we have the internal support still. hope that clarifies my current thinking. | 16:56 |
| @clarkb:matrix.org | I have been trying to test this locally but my local test setup is all kidns of unahppy: `ERROR: for zookeeper Cannot start service zookeeper: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "tmpfs" to rootfs at "/datalog": mount tmpfs:/datalog (via /proc/self/fd/6), flags: 0xe, data: uid=: invalid argument: unknown` | 16:56 |
| @tristanc_:matrix.org | corvus: the problem is that the zuul-operator installed certificates using the `cert-manager.io/v1alpha2` apiVersion, and that version is no longer available with the v1 crd of the cert-manager, so that means the zuul-operator will somehow have to manage the cert-manager upgrade. | 16:58 |
| @clarkb:matrix.org | I've got a bunch of meetings this morning so unsure of how in depth of debugging I'll get to | 16:58 |
| @clarkb:matrix.org | separately the $USER_ID change to docker-compose seems to not work locally beacuse i have no $USER_ID var. Should it be $UID? | 16:59 |
| @jim:acmegating.com | tristanC: honestly, that sounds like a problem with cert-manager that neither olm nor zuul-op can resolve: if cert-manager only supports one api version, then there is no way to have a seamless upgrade | 16:59 |
| @clarkb:matrix.org | Switching to uid and removing use of tmpfs does seem to work for me which may be sufficient for testing this one new test I have added | 17:00 |
| @tristanc_:matrix.org | corvus: according to its documentation, the OLM should take care of updating the cert-manager to the desired version. Well that is what I would like to try and observe :) | 17:01 |
| @jim:acmegating.com | tristanC: imagine we were already using olm: zuul-op would have created cert CRs with v1alpha1; how (and when) do those get turned into v1? | 17:01 |
| @sean-k-mooney:matrix.org | it wont update the exsiting deployment to use new crds | 17:02 |
| @jim:acmegating.com | right, i'm saying there are 2 aspects to api versioning here: what versions of the other operators are running, and then how zuul-operator interacts with those. if the other operator doesn't support multiple api versions simultaneously, then no matter who is managing the operator dependency lifecycle, there's no way to do a seamless upgrade. it's teardown and restart (for the deps at least) regardless. | 17:02 |
| @sean-k-mooney:matrix.org | at least i dont think it will since olm does not know the meaning fo the crds provded by operators | 17:02 |
| @jim:acmegating.com | sean-k-mooney: yeah, if anyone were to do it, it would have to be either cert-manager or zuul-op | 17:03 |
| @sean-k-mooney:matrix.org | so really there probly need to be a step to move to a version fo cert-manager taht supprot the alpha api and a betaw or v1 | 17:03 |
| @jim:acmegating.com | (and even if it were cert-manager, zuul-op would still need coordination so it wouldn't see missing v1alpha1 CRs and recreate them) | 17:03 |
| @sean-k-mooney:matrix.org | then move to v1 | 17:03 |
| @sean-k-mooney:matrix.org | then upgrade cert manager again | 17:04 |
| @jim:acmegating.com | yeah, i think the only viable way to do this would be for cert-manager to support both, zuul-op to detect that and perform its own migration | 17:04 |
| @sean-k-mooney:matrix.org | well unless cert manager has its own migration logic for the CRs | 17:05 |
| @jim:acmegating.com | none of that requires "olm" though; olm only addresses the "upgrade cert-manager to a newer version [which can support both api revs]" part | 17:05 |
| @sean-k-mooney:matrix.org | but if it did that would work without olm | 17:05 |
| @jim:acmegating.com | sean-k-mooney: yeah, but zuul-op would see missing certs and recreate them, so it would need coordination, at a minimum | 17:05 |
| @sean-k-mooney:matrix.org | yep | 17:06 |
| @sean-k-mooney:matrix.org | olm is basicaly like apt or dnf for operators | 17:06 |
| @jim:acmegating.com | i think 80% of this problem is "how to have zuul-operator migrate its interaction with its dependencies" and 20% is "how to upgrade the dependencies". | 17:07 |
| @jim:acmegating.com | (and olm vs vendor addresses the 20% part) | 17:07 |
| @sean-k-mooney:matrix.org | https://cert-manager.io/docs/installation/upgrading/remove-deprecated-apis/ | 17:09 |
| @sean-k-mooney:matrix.org | that is probly relevnt to this | 17:09 |
| @sean-k-mooney:matrix.org | looks like 1.5 | 17:10 |
| @sean-k-mooney:matrix.org | is the bridge release | 17:10 |
| @sean-k-mooney:matrix.org | where the api is dperecated but not removed as it is in 1.6 | 17:11 |
| @jim:acmegating.com | so the sequence is: 1) run cert-manager 1.5; 2) zuul-operator migrates certs to new apis (using cmctl command listed there); 3) run cert-manager 1.6+ | 17:11 |
| @jim:acmegating.com | whether it's olm or vendor, i think we'd need several zuul-operator releases to keep up with that. | 17:11 |
| @jim:acmegating.com | (like a zuul-op release that expects 1.5 and performs the upgrade; then a zuul-op that expects 1.6+ and has the upgrade code removed) | 17:12 |
| @sean-k-mooney:matrix.org | for cert manager this is likely a one time pain once your on a v1 api | 17:12 |
| @sean-k-mooney:matrix.org | rather then alpha | 17:12 |
| @clarkb:matrix.org | Ok I got it the test running locally without a tmpfs and it passes so my change is hopefully good | 17:12 |
| @jim:acmegating.com | Clark: did you use the ./test-setup-docker.sh script? | 17:13 |
| @jim:acmegating.com | Clark: that has ```export USER_ID=$(id -u)``` in it | 17:13 |
| @jim:acmegating.com | * Clark: did you use the tools/test-setup-docker.sh script? | 17:14 |
| @clarkb:matrix.org | ah ok that is where the var comes from. No I don't use it because I had a preexisting env that I was just trying to docker-compose up -d | 17:14 |
| @clarkb:matrix.org | fwiw I think you can just use $UID and that would be more portable | 17:14 |
| @jim:acmegating.com | Clark: ah, i use the script every time. i also frequently `docker-compose down` | 17:14 |
| @clarkb:matrix.org | got it. Didn't realize it was good for spinning up old envs. FWIW I half suspect the tmpfs issue is a docker / new kernel bug | 17:15 |
| @sean-k-mooney:matrix.org | more portable becase $() is a bashism? | 17:15 |
| @jim:acmegating.com | Clark: fwiw, i don't have a $UID set in fish :) | 17:15 |
| @sean-k-mooney:matrix.org | and wont work on fish/dash? | 17:15 |
| @clarkb:matrix.org | > <@sean-k-mooney:matrix.org> more portable becase $() is a bashism? | 17:15 |
| Because UID is something bash sets. | ||
| @jim:acmegating.com | it's true that using UID would make the docker-compose work standalone if the user is running bash | 17:16 |
| @jim:acmegating.com | but then it would cause the script to fail | 17:17 |
| @jim:acmegating.com | because you can't set UID in bash | 17:17 |
| @jim:acmegating.com | oh but if the script is run as bash, then it shouldn't be necessary | 17:18 |
| @jim:acmegating.com | Clark: maybe worth a try then? :) | 17:18 |
| @clarkb:matrix.org | Ya I think it should work with teh script and by hand if using bash | 17:18 |
| @clarkb:matrix.org | anyway. The main issue is the tmpfs thing and that seems to be something to do with docker and/or my very new kernel :/ | 17:19 |
| @sean-k-mooney:matrix.org | if you set the interperter via the #! line i guess | 17:19 |
| @jim:acmegating.com | yeah the script does that | 17:19 |
| @jim:acmegating.com | Clark: thanks for riding the bleeding edge :) | 17:19 |
| @clarkb:matrix.org | I found an internet comment suggesting I needed to cahnge the docker compose yaml version but that didn't help | 17:20 |
| @sean-k-mooney:matrix.org | odd not sure why tempfs would break docker | 17:20 |
| @clarkb:matrix.org | Oh! $UID isn't in env its more magical so docker-compose doesn't see it either :/ | 17:21 |
| @sean-k-mooney:matrix.org | that kind of againt the kernel changes should not break userspace mentality | 17:21 |
| @clarkb:matrix.org | So now I wonder if the issue is the UID thing | 17:22 |
| @clarkb:matrix.org | tmpfs exploding ebcause we assign a UID to it | 17:22 |
| @tristanc_:matrix.org | corvus: i think the issue OLM solve is that when we `kubectl apply cert-manager-bundle-1.5`, then we may leak resources that was installed by the previous bundle. | 17:22 |
| @jim:acmegating.com | we should put a comment in the script :) | 17:22 |
| @clarkb:matrix.org | aha that was it. Ok ya once I sorted out USER_ID the tmpfs mount works | 17:24 |
| @tristanc_:matrix.org | corvus: I guess the solution is to `kubectl delete` first, but then we would loose any cr that was defined. And I think that is why OLM is so important, because it deals with these upgrade issues. | 17:25 |
| @tristanc_:matrix.org | we still need to manage the CRs though, e.g. using cmctl | 17:26 |
| @jim:acmegating.com | tristanC: it looks like cert-manager upgrades are just "apply": https://cert-manager.io/docs/installation/upgrading/#upgrading-using-static-manifests so i don't think we have to worry about leaks | 17:27 |
| @sean-k-mooney:matrix.org | they have specific upgrade steps in the 1.5 to 1.6 notes | 17:28 |
| @sean-k-mooney:matrix.org | so in general yes i thhink its just apply | 17:28 |
| @sean-k-mooney:matrix.org | if they dont remove apis | 17:28 |
| @jim:acmegating.com | so right now, there is a fully manual upgrade path that involves stopping zuul-operator, upgrading cert-manager, running cmctl, upgrading zuul-operator to a future version that support v1, then starting zuul-op. | 17:31 |
| @jim:acmegating.com | if we wanted any kind of automation, we'd need to figure out who is responsible for running cmctl. it may be zuul operator, or maybe olm has some way of dealing with that. | 17:32 |
| @tristanc_:matrix.org | it does not seems like olm would deal with that | 17:33 |
| @jim:acmegating.com | if zuul-operator has cmctl upgrade support added, then it's possible for either it to perform a cert-manager upgrade, or for olm to perform the upgrade. | 17:33 |
| @jim:acmegating.com | * if zuul-operator has cmctl upgrade support added, then it's possible for either it to perform a cert-manager upgrade, or for olm to perform the cert-manager upgrade (and then zuul-op would run cmctl next time it starts). | 17:34 |
| @tristanc_:matrix.org | well, i just want to be able to use the zuul-operator on a cluster which only accept crd/v1. For that, we also need a more recent PXC operator, and it seems like the OLM service is designed to handle such upgrade, hence my suggestion to use it instead of vendoring the PXC operator... | 17:36 |
| @sean-k-mooney:matrix.org | its designed to support it in the same way dnf is designed ot upgrade openstack | 17:37 |
| @sean-k-mooney:matrix.org | it will upgrade the operator it wont neesiarly update the resouces provdied by the operator or convet to new apis | 17:37 |
| @jim:acmegating.com | tristanC: i get that, but that's solving the easy part without solving the hard part. there's no functional difference form a user's perspective between using olm for this upgrade and just having zuul-operator splat out a new yaml apply. the only way the upgrade story changes from "user does everything manually" to "even part of the upgrade happens automatically" is when we start adding upgrade support for the CRs themselves to zuul-operator. that's because right now, no matter whether it's olm or zuul-op performing the cert-manager upgrade, the user has to sequence the actual upgrade manually. | 17:39 |
| @jim:acmegating.com | tristanC: so i think the best thing for the moment is to keep things simple and acknowledge that dependency upgrading isn't covered by zuul-operator and needs to be done manually. so the only thing we need in your change is just the new bundles and using the new CR formats | 17:40 |
| @jim:acmegating.com | (and as i said, it's totally fine to want to use olm to manage the dependencies and i think we should support that; but it's not [currently] a solution to the upgrade problem) | 17:41 |
| @tristanc_:matrix.org | I'd be happy to look at the upgrade problem, but I've not yet been able to deploy zuul with the operator :) | 17:42 |
| @tristanc_:matrix.org | but ok, i'll try to make the crd v1 update works with the vendored yaml, and document the upgrade step. Then i'll see how we can leverage OLM | 17:43 |
| -@gerrit:opendev.org- Tristan Cacqueray proposed: [zuul/zuul-operator] 845851: Update CRD apiVersion to v1 (from v1beta) https://review.opendev.org/c/zuul/zuul-operator/+/845851 | 17:54 | |
| -@gerrit:opendev.org- Tristan Cacqueray proposed: [zuul/zuul-operator] 845851: Update CRD apiVersion to v1 (from v1beta) https://review.opendev.org/c/zuul/zuul-operator/+/845851 | 18:38 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 846442: Update ZooKeeper class connection methods https://review.opendev.org/c/zuul/nodepool/+/846442 | 18:50 | |
| -@gerrit:opendev.org- Tristan Cacqueray proposed: [zuul/zuul-operator] 845851: Update CRD apiVersion to v1 (from v1beta) https://review.opendev.org/c/zuul/zuul-operator/+/845851 | 19:22 | |
| -@gerrit:opendev.org- Tristan Cacqueray proposed: [zuul/zuul-operator] 845851: Update CRD apiVersion to v1 (from v1beta) https://review.opendev.org/c/zuul/zuul-operator/+/845851 | 20:09 | |
| -@gerrit:opendev.org- Tristan Cacqueray proposed: [zuul/zuul-operator] 845851: Update CRD apiVersion to v1 (from v1beta) https://review.opendev.org/c/zuul/zuul-operator/+/845851 | 21:00 | |
| -@gerrit:opendev.org- Tristan Cacqueray proposed: [zuul/zuul-operator] 845851: Update CRD apiVersion to v1 (from v1beta) https://review.opendev.org/c/zuul/zuul-operator/+/845851 | 22:02 | |
| @blaisep-sureify:matrix.org | LMK if there is a better forum for this... (Gerrit provided too many options with no guidance.) | 22:48 |
| Being a new Zuul admin, I created a merge conflict. | ||
| I didn't notice in the terminal (that's already a problem), but when I looked at the Web client, I noticed the big read label. | ||
| So the client suggests `downloading the patchset` and resolving the conflict. | ||
| when I choose "download", I get a panel with a bunch of options: | ||
| @blaisep-sureify:matrix.org | Looking at the options, it's hard to know which to pick and some of the choices are the subject of vigorous debates. | 22:50 |
| There's a bar in Mountain View where you can get your ass kicked if you're on the wrong side of the rebase vs merge debate. | ||
| @blaisep-sureify:matrix.org | Is this what happens with merge conflicts because of the "patch set " model? | 22:51 |
| @jim:acmegating.com | > <@blaisep-sureify:matrix.org> LMK if there is a better forum for this... (Gerrit provided too many options with no guidance.) | 22:53 |
| > Being a new Zuul admin, I created a merge conflict. | ||
| > I didn't notice in the terminal (that's already a problem), but when I looked at the Web client, I noticed the big read label. | ||
| > So the client suggests `downloading the patchset` and resolving the conflict. | ||
| > when I choose "download", I get a panel with a bunch of options: | ||
| This is strictly a gerrit question, so is a bit out of scope for this room/zuul -- but you may find opendev's documentation about the gerrit workflow useful: https://docs.opendev.org/opendev/infra-manual/latest/index.html -- there are probably others from other communities (like wikimedia) too. | ||
| @jim:acmegating.com | that guide has some general information about dowloading patches, fixing conflicts, rebasing, etc with gerrit | 22:54 |
| @blaisep-sureify:matrix.org | Thanks! | 22:56 |
| isnt it weird that there is only one change, what is it in conflict with? | ||
| There is no "ours" vs "theirs" | ||
| @blaisep-sureify:matrix.org | btw, the openDev docs are really very good. | 22:57 |
| -@gerrit:opendev.org- Tristan Cacqueray proposed: | 22:58 | |
| - [zuul/zuul-operator] 845851: Update CRD apiVersion to v1 (from v1beta) https://review.opendev.org/c/zuul/zuul-operator/+/845851 | ||
| - [zuul/zuul-operator] 847830: Update to the latest version of kopf https://review.opendev.org/c/zuul/zuul-operator/+/847830 | ||
| @jsokolvewd:matrix.org | > <@blaisep-sureify:matrix.org> Thanks! | 22:59 |
| > isnt it weird that there is only one change, what is it in conflict with? | ||
| > There is no "ours" vs "theirs" | ||
| > | ||
| But there is - review is an attempt to merge something to a certain branch, the one you specified when pushing, the `refs/for/<branch>` bit. So, the merge conflict is between your commit under review and current state of target branch | ||
| @blaisep-sureify:matrix.org | I see, yes, it was a new repo but there was some text in the original file. | 23:31 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!