)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":25733,"name":"Jan Gutter","email":"github@jangutter.com","username":"jangutter"},"change_message_id":"c899ed98f546c046cd53f3131284ac904da076c3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"ffd5a6eb_25c172f2","updated":"2024-10-03 10:12:05.000000000","message":"(unrelated to the previous CI failure....)","commit_id":"14fea0e6af189db3a38e49f9281dd34278820a71"},{"author":{"_account_id":25733,"name":"Jan Gutter","email":"github@jangutter.com","username":"jangutter"},"change_message_id":"496601e37be0d07fc005bc0e68d169cee270611b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":22,"id":"cd8f451e_1c2e63ff","updated":"2024-10-07 16:34:21.000000000","message":"\u003e Changing them opens a number of questions that I think should be answered:\n\n(setting context here, I agree that these questions need answering!)\n\n\u003e Currently, we update these by just copying in new versions. How could we\n\u003e effectively maintain a fork? Should we?\n\nThere are some internal changes already to the pxc-bundle.yaml template - the intention making it easier to test (i.e. run in an unsafe mode). I suspect that using a transformer like Kustomize rather than the templating method might lower the maintenance burden.\n\n\u003e Should we expect that use-cases that can\u0027t be covered by the operators as written \n\u003e should be handled by external deployment?\n\nI think it\u0027s possible, but, honestly, I think it\u0027ll ramp up the adoption burden for small-scale deployments. There is definitely an added maintenance and tech burden shifted towards the project here, but it\u0027s away from some users.\n\n\u003e Should we instead make these changes upstream and then update to them once merged\n\u003e there?\n\nI suspect that upstream might recommend folks to \"just use Kustomize\"....\n\n\n\nMy ideal future scenario would be that the bundled resources are no longer templates - making for easier version bumping. I guess it ends up whether the direction of the operator needs to go towards being \"simpler\" or towards being a \"zuul distro\".","commit_id":"8a7c2f470cb5737f6c64a76c635741edd84efe9a"},{"author":{"_account_id":36342,"name":"Damian Fajfer","display_name":"fajfer","email":"damian@fajfer.org","username":"fajfer"},"change_message_id":"a49d116acc2b22d3c26a61d1a24e891cc8fc3664","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":22,"id":"6dba1c80_d7837ad1","updated":"2024-11-08 11:05:06.000000000","message":"\u003eOur intent was to include these operators verbatim because we presume their authors know best how to run their software.\n\nand you\u0027re right, I\u0027ve been zuul-operator users for years and always used the defaults from here - they never put me down, however this change to me fixes a problem wtih having a corporate proxy thus being unable to pull images straight from the internet\n\n\u003eCurrently, we update these by just copying in new versions. How could we effectively maintain a fork? Should we?\n\nWe specified nowhere that this","commit_id":"8a7c2f470cb5737f6c64a76c635741edd84efe9a"},{"author":{"_account_id":35201,"name":"Michael Kelly","display_name":"Michael Kelly","email":"mkelly@arista.com","username":"michael_kelly"},"change_message_id":"8fcdc5c94add5d55656383a674ca782079cde036","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":22,"id":"303d748f_03414a2c","in_reply_to":"28522562_52a03d4f","updated":"2024-11-08 03:46:40.000000000","message":"Fwiw, this was part of the rationale behind wanting to introduce a helm chart to manage this instead - having this managed by the operator itself means that the operator must be installed with admin level cluster permissions.  It also introduces a few awkward scenarios:\n\n* you can\u0027t install conflicting versions of the nested operators\n* if you attempt to use the nested operator installs for anything else, the zuul-operator can\u0027t delete them\n* afaik we don\u0027t actually delete them anyway, so deploying a zuul cluster leaves (surprising) artifacts in your cluster\n\nHelm provides a mechanism for installing nested charts and this allows the user to customize the underlying components as much or as little as they want to.  It also means that the nested components go away when the parent chart is removed. I\u0027d suggest leaving the bundled templates as vanilla as possible (and possibly deprecating this approach) and use a helm chart to this end instead.","commit_id":"8a7c2f470cb5737f6c64a76c635741edd84efe9a"},{"author":{"_account_id":36342,"name":"Damian Fajfer","display_name":"fajfer","email":"damian@fajfer.org","username":"fajfer"},"change_message_id":"a49d116acc2b22d3c26a61d1a24e891cc8fc3664","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":22,"id":"d876f101_0ea49666","in_reply_to":"303d748f_03414a2c","updated":"2024-11-08 11:05:06.000000000","message":"@mkelly@arista.com not sure what would be the operator purpose at this point if we artificially work on limiting what it can be used for. It already is the least popular choice of deploying Zuul since it\u0027s unusable for most users in the current state and requires some legwork (setting up ingresses manually comes to mind) before you can work with it. Zuul also doesn\u0027t have any official helm charts, you have to set all manifests up yourself. I fail to see the agenda here","commit_id":"8a7c2f470cb5737f6c64a76c635741edd84efe9a"},{"author":{"_account_id":25733,"name":"Jan Gutter","email":"github@jangutter.com","username":"jangutter"},"change_message_id":"07b39d7bb6f25f50c3144a396f1f09b2465ceca8","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":22,"id":"905ddca2_b40dc82c","in_reply_to":"30695f02_9246b89b","updated":"2024-10-09 15:56:15.000000000","message":"Just confirming my understanding: Currently, the way the bundled operators work:\n\nDevelopment:\n  1. fetch an upstream yaml file\n  2. edit some of them by hand (\"converting them to a template\")\n  3. bundle them into the operator artifact\n  \nRuntime:\n  4. set the template parameters\n  5. apply the templated out yaml\n  \nMost of them are untemplated - the pxc operator being the one with the most \"nontrivial\" customisations, intended to run in an \"unsafe\" mode for CI.\n\nWhat I\u0027d like to attempt is:\n\nDevelopment:\n  1. fetch upstream yaml files\n  2. bundle them verbatim into the operator artifact\n  3. bundle a set of transformation rules into the artifact (like the ones used by \"kustomize\")\n  \nRuntime:\n  4. use the combination of parameters, transformation rules and upstream yaml files to render out the yaml\n  5. apply the rendered yaml\n\nIn my mind, this changes zuul-operator into a \"distribution\". It\u0027s bundling tested operators together with the zuul service into a single composition. (This is the path I\u0027d prefer.)\n\nThe alternative path is to unbundle the external operators, going maximally simple. In this way, to assemble a useful Zuul instance for us, we\u0027d be managing the DB and zookeeper (this makes sense beyond a certain scale anyway).\n\nApologies for the long-winded explanation here - the end result I\u0027m trying to get at is to:\n * increase the automation of updating bundled operators\n * allow more dynamic customization of bundled operators","commit_id":"8a7c2f470cb5737f6c64a76c635741edd84efe9a"},{"author":{"_account_id":35201,"name":"Michael Kelly","display_name":"Michael Kelly","email":"mkelly@arista.com","username":"michael_kelly"},"change_message_id":"001d5259351ce23b6134d261aca09c96ef822f82","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":22,"id":"b036e252_4034740f","in_reply_to":"5d488e74_a118b29d","updated":"2024-11-16 00:23:58.000000000","message":"Nope.  Use the zuul-operator, but manage the actual deployment of it using helm charts.  Having the operator want to install other operators is an absolute nightmare in a shared k8s environment where you don\u0027t want the operator itself to have admin privs.","commit_id":"8a7c2f470cb5737f6c64a76c635741edd84efe9a"},{"author":{"_account_id":36342,"name":"Damian Fajfer","display_name":"fajfer","email":"damian@fajfer.org","username":"fajfer"},"change_message_id":"40107027a100bafdceba05f497f88ac9ccf67e0f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":22,"id":"48766968_da24807d","in_reply_to":"6dba1c80_d7837ad1","updated":"2024-11-08 11:07:13.000000000","message":"This is some draft published by an accident i dont even remember writing","commit_id":"8a7c2f470cb5737f6c64a76c635741edd84efe9a"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"a3623574080ff19d8c53fc943b8607280f3dfe2f","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":22,"id":"28522562_52a03d4f","in_reply_to":"905ddca2_b40dc82c","updated":"2024-10-09 16:20:16.000000000","message":"Your proposal sounds good to me, and I understand your use of the word distribution now.  I think the main thing to know about our original intention for the operator is that it should be opinionated with respect to the dependencies.  So the user has two choices:\n\n1) Use the bundled dependencies exactly the way the zuul project configured them in the operator.\n2) or: Turn them off and roll your own.\n\nSo I think we\u0027d want to keep the number of kustomizations fairly small (the unsafe switch for CI, the image source, maybe a storage class or something like that?) and not try to expose all the different things you can do with these operators to zuul-operator users.  If someone wants to run 6 pxc replicas on a custom ceph setup, it\u0027s going to be easier for them to just tell the pxc operator to do that directly rather than telling the zuul operator to tell the pxc operator that.\n\nThere\u0027s no shame in the second option (\"Turn them off and roll your own\").  If a user has an opinion on how the pxc operator should run, they should express it directly.  As you note, above a certain size, it\u0027s probably how most deployments should operate.  We don\u0027t really want to have anything to do with this stuff.  Option 1 is there just to make it easy for the easy case.\n\nTo summarize, I think your proposal (as long as the number of kustomizations is small) aligns with our original goals and will make maintenance easier, which is good as well.","commit_id":"8a7c2f470cb5737f6c64a76c635741edd84efe9a"},{"author":{"_account_id":36342,"name":"Damian Fajfer","display_name":"fajfer","email":"damian@fajfer.org","username":"fajfer"},"change_message_id":"d5472cf3bd877b9ea632e765765532140c5efb8a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":22,"id":"5d488e74_a118b29d","in_reply_to":"c2190ba1_1f952b13","updated":"2024-11-15 13:48:39.000000000","message":"Hey, sorry @mkelly@arista.com I assumed that you were opting for helm charts as an alternative Zuul installation/management method to the zuul-operator","commit_id":"8a7c2f470cb5737f6c64a76c635741edd84efe9a"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"688413c6d8ac413551a3c88247a26338e43c1817","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":22,"id":"30695f02_9246b89b","in_reply_to":"cd8f451e_1c2e63ff","updated":"2024-10-09 15:26:27.000000000","message":"\u003e My ideal future scenario would be that the bundled resources are no longer templates - making for easier version bumping. I guess it ends up whether the direction of the operator needs to go towards being \"simpler\" or towards being a \"zuul distro\".\n\nI\u0027m not entirely sure what you mean by the last sentence, but I\u0027m pretty sure the answer is \"simple\".  Everything about its design, as I\u0027m sure you\u0027ve seen, is to put as thin a veneer as possible over the actual software.  The fewer changes we have to make over time to the operator, the better.\n\nSo with that in mind, I think the idea of not including the templates for external deps sounds like a great idea.  Are you imagining a build step?  so that we download them, Kustomize them, and then bundle them as they are today?  Or are you imagining the operator does those steps when it\u0027s running?  It couldn\u0027t do that in an airgapped environment, so you must be imagining the first thing.\n\nWhether we do that and commit the result or not doesn\u0027t sound like a terribly important distinction.  If it makes it easier to commit the result like we have today, we can just enforce the process with a gate job.","commit_id":"8a7c2f470cb5737f6c64a76c635741edd84efe9a"},{"author":{"_account_id":35201,"name":"Michael Kelly","display_name":"Michael Kelly","email":"mkelly@arista.com","username":"michael_kelly"},"change_message_id":"9bfd708f2f2e1de79d50c8312c56e4a10e64b586","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":22,"id":"c2190ba1_1f952b13","in_reply_to":"d876f101_0ea49666","updated":"2024-11-14 21:07:00.000000000","message":"@damian@fajfer.org Sorry, not entirely following you there.  How does having a helm chart to manage the operator install (and any adjacent components it may want to use) limit what the operator can be used for?","commit_id":"8a7c2f470cb5737f6c64a76c635741edd84efe9a"},{"author":{"_account_id":36342,"name":"Damian Fajfer","display_name":"fajfer","email":"damian@fajfer.org","username":"fajfer"},"change_message_id":"81c40f805ecde01617ff0b3b3bf9e71c6796b772","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":23,"id":"5d4a4877_85e56600","updated":"2025-08-13 13:45:38.000000000","message":"recheck","commit_id":"3d3acd1a9a17450342c61126f4a59ad3d8e01858"}],"zuul_operator/templates/pxc-create-db.yaml":[{"author":{"_account_id":25733,"name":"Jan Gutter","email":"github@jangutter.com","username":"jangutter"},"change_message_id":"c899ed98f546c046cd53f3131284ac904da076c3","unresolved":true,"context_lines":[{"line_number":7,"context_line":"    spec:"},{"line_number":8,"context_line":"      containers:"},{"line_number":9,"context_line":"      - name: mysql"},{"line_number":10,"context_line":"        image: percona:8.0"},{"line_number":11,"context_line":"        command:"},{"line_number":12,"context_line":"          - \"mysql\""},{"line_number":13,"context_line":"          - \"-h\""}],"source_content_type":"text/x-yaml","patch_set":9,"id":"d728d9f1_7fe7d6c5","side":"PARENT","line":10,"range":{"start_line":10,"start_character":8,"end_line":10,"end_character":26},"updated":"2024-10-03 10:12:05.000000000","message":"So this expands to `docker.io/library` but the imagePrefix is `docker.io/percona`","commit_id":"fef7c272f7e92b5aa414cbeeb7bd943b45d9eecb"},{"author":{"_account_id":25733,"name":"Jan Gutter","email":"github@jangutter.com","username":"jangutter"},"change_message_id":"a76548eb7d91985d3add6309c27cc2b5b69ff584","unresolved":false,"context_lines":[{"line_number":7,"context_line":"    spec:"},{"line_number":8,"context_line":"      containers:"},{"line_number":9,"context_line":"      - name: mysql"},{"line_number":10,"context_line":"        image: percona:8.0"},{"line_number":11,"context_line":"        command:"},{"line_number":12,"context_line":"          - \"mysql\""},{"line_number":13,"context_line":"          - \"-h\""}],"source_content_type":"text/x-yaml","patch_set":9,"id":"ad521630_bad801ac","side":"PARENT","line":10,"range":{"start_line":10,"start_character":8,"end_line":10,"end_character":26},"in_reply_to":"d728d9f1_7fe7d6c5","updated":"2024-10-03 12:40:55.000000000","message":"Done","commit_id":"fef7c272f7e92b5aa414cbeeb7bd943b45d9eecb"}]}