| *** armstrongs has quit IRC | 00:03 | |
| *** Goneri has quit IRC | 00:15 | |
| *** mattw4 has quit IRC | 00:20 | |
| *** Goneri has joined #zuul | 00:49 | |
| *** Goneri has quit IRC | 00:55 | |
| *** portdirect has quit IRC | 01:02 | |
| *** jangutter has quit IRC | 01:42 | |
| *** jangutter has joined #zuul | 01:42 | |
| *** jangutter_ has joined #zuul | 02:28 | |
| *** jangutter has quit IRC | 02:30 | |
| *** paladox is now known as [UK] | 02:59 | |
| *** [UK] is now known as paladox | 03:00 | |
| *** bhavikdbavishi has joined #zuul | 03:04 | |
| *** bhavikdbavishi has quit IRC | 03:10 | |
| *** rlandy|bbl is now known as rlandy | 03:13 | |
| *** rlandy has quit IRC | 03:14 | |
| *** bhavikdbavishi has joined #zuul | 03:16 | |
| *** zxiiro has quit IRC | 04:10 | |
| *** bolg has joined #zuul | 05:06 | |
| *** evrardjp has quit IRC | 05:33 | |
| *** evrardjp has joined #zuul | 05:34 | |
| *** swest has joined #zuul | 06:11 | |
| *** bolg has quit IRC | 07:37 | |
| *** avass has joined #zuul | 07:37 | |
| *** sshnaidm|afk is now known as sshnaidm | 07:53 | |
| *** jpena|off is now known as jpena | 07:56 | |
| *** pcaruana has joined #zuul | 08:02 | |
| *** reiterative has joined #zuul | 08:10 | |
| *** bolg has joined #zuul | 08:12 | |
| *** tosky has joined #zuul | 08:25 | |
| *** themroc has joined #zuul | 08:32 | |
| *** sugaar has joined #zuul | 08:33 | |
| *** avass has quit IRC | 08:54 | |
| *** electrofelix has joined #zuul | 09:36 | |
| sugaar | Hi, I was wondering, how does zuul handle the values contained in zuul.conf? are those variables that checks for the value contained in them? could be done the same if the values would be environmental variables? | 09:41 |
|---|---|---|
| *** bhavikdbavishi has quit IRC | 09:41 | |
| *** bhavikdbavishi has joined #zuul | 09:42 | |
| *** bhavikdbavishi has quit IRC | 09:46 | |
| *** [GNU] has quit IRC | 09:48 | |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: Authorization rules: support YAML nested dictionaries https://review.opendev.org/684790 | 09:58 |
| *** avass has joined #zuul | 11:10 | |
| *** bhavikdbavishi has joined #zuul | 11:13 | |
| *** bhavikdbavishi1 has joined #zuul | 11:16 | |
| *** bhavikdbavishi has quit IRC | 11:18 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 11:18 | |
| *** jangutter_ is now known as jangutter | 11:49 | |
| *** jpena is now known as jpena|lunch | 11:58 | |
| *** themroc has quit IRC | 12:07 | |
| *** themroc has joined #zuul | 12:09 | |
| *** themroc has quit IRC | 12:11 | |
| *** themroc has joined #zuul | 12:12 | |
| openstackgerrit | Paul Albertella proposed zuul/zuul master: Fix Gerrit config issue in tutorial demo https://review.opendev.org/701562 | 12:13 |
| *** bolg has quit IRC | 12:33 | |
| *** bolg has joined #zuul | 12:47 | |
| *** rfolco has joined #zuul | 12:54 | |
| *** zbr|rover has quit IRC | 13:00 | |
| *** bolg has quit IRC | 13:04 | |
| *** jpena|lunch is now known as jpena | 13:11 | |
| tristanC | mnaser: iiuc you replaced your k8s operator by helm charts for zuul right? | 13:15 |
| mnaser | tristanC: yeah it’s what we’re running now | 13:15 |
| tristanC | mnaser: is there a particular reason behind the change? | 13:16 |
| mnaser | tristanC: complexity and time mostly | 13:17 |
| mnaser | It’s a lot faster to write manifests than an operator, and we do miss out on some of the features that we can get by having an operator but it’s still early for us | 13:18 |
| tristanC | mnaser: alright, i'll give another stab at the operator cr as it is defined in the zuul repo | 13:18 |
| mnaser | cool, I think my helm work can be a useful “base” | 13:18 |
| tristanC | mnaser: it has been yes thanks | 13:19 |
| tristanC | mnaser: fwiw my wip is https://github.com/TristanCacqueray/dhall-zuul/blob/master/operator/application/Zuul.dhall | 13:20 |
| tristanC | and it results in this object: https://github.com/TristanCacqueray/dhall-zuul/blob/master/deployments/cr-k8s.yaml | 13:20 |
| *** bolg has joined #zuul | 13:21 | |
| mnaser | neat! | 13:21 |
| mnaser | I’m slowly revising the charts as I find small periods of time | 13:21 |
| *** Goneri has joined #zuul | 13:50 | |
| *** bhavikdbavishi has quit IRC | 13:50 | |
| *** bolg has quit IRC | 13:57 | |
| *** michael-beaver has joined #zuul | 14:07 | |
| *** rlandy has joined #zuul | 14:11 | |
| *** zbr has joined #zuul | 14:16 | |
| *** zxiiro has joined #zuul | 14:18 | |
| *** zbr is now known as zbr|rover | 14:18 | |
| *** mhu has joined #zuul | 14:26 | |
| *** portdirect has joined #zuul | 14:31 | |
| openstackgerrit | David Shrewsbury proposed zuul/zuul master: WIP: Documentation reorg https://review.opendev.org/701608 | 14:40 |
| openstackgerrit | David Shrewsbury proposed zuul/zuul master: WIP: Documentation reorg https://review.opendev.org/701608 | 14:43 |
| openstackgerrit | David Shrewsbury proposed zuul/zuul master: WIP: Documentation reorg https://review.opendev.org/701608 | 14:45 |
| *** pcaruana has quit IRC | 14:47 | |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Add --check-config option to zuul scheduler https://review.opendev.org/542160 | 14:49 |
| Shrews | If anyone can recommend how to fix the sidebar "Related Topics" links with 701608, I would appreciate the info! | 14:49 |
| openstackgerrit | Mohammed Naser proposed zuul/zuul-helm master: Add Zuul charts https://review.opendev.org/700460 | 14:54 |
| tristanC | Shrews: it seems like caused by the new index.rst lacking titles | 14:57 |
| tristanC | Shrews: e.g. https://review.opendev.org/#/c/701608/4/doc/source/overview/index.rst@1 should have something like https://review.opendev.org/#/c/701608/4/doc/source/references/client.rst@1 | 14:58 |
| Shrews | tristanC: hmm, i'll try that. thx | 15:00 |
| *** pcaruana has joined #zuul | 15:02 | |
| tristanC | Shrews: the re-org looks great, thanks! | 15:06 |
| Shrews | tristanC: thx :) | 15:06 |
| Shrews | tristanC: hrm, seems the 'title' directive is not enough. Need an actual header in the doc, but that does fix it | 15:07 |
| openstackgerrit | David Shrewsbury proposed zuul/zuul master: Documentation reorg https://review.opendev.org/701608 | 15:12 |
| tobiash | if someone has time, may I get a second review on https://review.opendev.org/696459? It's a tiny change that reduces log noise in some situations. | 15:13 |
| openstackgerrit | Jan Kubovy proposed zuul/zuul master: WIP: Add spec for scale out scheduler https://review.opendev.org/621479 | 15:14 |
| Shrews | tobiash: done | 15:14 |
| tobiash | Shrews: awesome, thanks! | 15:14 |
| openstackgerrit | David Shrewsbury proposed zuul/zuul master: Documentation reorg https://review.opendev.org/701608 | 15:22 |
| openstackgerrit | Mohammed Naser proposed zuul/zuul-helm master: Add Zuul charts https://review.opendev.org/700460 | 15:36 |
| corvus | sugaar: see here: https://zuul-ci.org/docs/zuul/admin/components.html look for "Zuul will interpolate environment variables" | 15:39 |
| openstackgerrit | Jan Kubovy proposed zuul/zuul master: WIP: Add spec for scale out scheduler https://review.opendev.org/621479 | 15:39 |
| openstackgerrit | Albin Vass proposed zuul/zuul master: Force fetch when updating merger repositories https://review.opendev.org/701753 | 15:41 |
| avass | Just noticed that someone deleted a tag from our repos and caused a huge queue because of this: http://paste.openstack.org/show/788206/ | 15:42 |
| avass | ^I'm guessing a bit but I think that should fix it | 15:42 |
| sugaar | corvus thanks | 15:43 |
| mordred | avass: yeah - deleting tags is super bad and people should not do it | 15:43 |
| avass | mordred: I agree :) | 15:44 |
| mordred | :) | 15:44 |
| avass | anyway, is there a good reason for the merger not to force fetch? | 15:48 |
| corvus | avass: i can't think of a good one | 15:48 |
| clarkb | seems like this would avoid problems if a branch is rebased too ? probably a good idea | 15:49 |
| mordred | ++ | 15:50 |
| Shrews | is the force option really named 'f' ? how... odd | 15:54 |
| corvus | Shrews: some of the api methods just pass through cmdline args | 15:55 |
| corvus | so that just translates to "add -f" | 15:55 |
| *** bhavikdbavishi has joined #zuul | 16:02 | |
| corvus | tristanC: can you take a look at https://review.opendev.org/701237 ? | 16:04 |
| *** jpena is now known as jpena|off | 16:06 | |
| *** bhavikdbavishi1 has joined #zuul | 16:07 | |
| *** bhavikdbavishi has quit IRC | 16:07 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 16:07 | |
| tristanC | corvus: yes. in the 'Start minikube' task output there is: '! Using the 'cri-o' runtime with the 'none' driver is an untested configuration!' | 16:09 |
| *** themroc has quit IRC | 16:09 | |
| corvus | tristanC: i guess we just tested it ;) | 16:09 |
| *** themroc has joined #zuul | 16:09 | |
| tristanC | corvus: yes, other than that, the change seems correct | 16:10 |
| corvus | tristanC: cool. i'm looking forward to the next release of crio, where we won't have to restart it after changing the registries.conf file | 16:10 |
| corvus | (it takes a long time to restart) | 16:11 |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Add --check-config option to zuul scheduler https://review.opendev.org/542160 | 16:11 |
| *** avass has quit IRC | 16:12 | |
| tristanC | corvus: it takes a long time to restart because it sigterm running pods, and iirc some kube process needs sigkill | 16:13 |
| corvus | yeah | 16:13 |
| tristanC | (i manually kill all pods before restarting crio and it's almost instantaneous) | 16:13 |
| corvus | oh interesting | 16:14 |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Add --validate-tenants option to zuul scheduler https://review.opendev.org/542160 | 16:14 |
| openstackgerrit | James E. Blair proposed zuul/zuul-helm master: Test helm charts against k8s https://review.opendev.org/701764 | 16:22 |
| corvus | tristanC, mnaser: ^ is that how you run a helm chart? :) | 16:22 |
| tristanC | corvus: that seems correct, though i never used helm actually :) | 16:23 |
| Shrews | zuul-maint: For those not following along, I've proposed a reorganization of our zuul documentation to follow a more accepted pattern (and I believe an easier to digest pattern) in https://review.opendev.org/701608. You can see the results at: https://bc90d6750c30bb4706d3-111c5415117c6f7e8c7678caa672fcb9.ssl.cf1.rackcdn.com/701608/6/check/zuul-tox-docs/feabb12/docs/ | 16:25 |
| Shrews | zuul-maint: I feel this also sets us up to fill the gap in user tutorials, which is a large barrier to wider adoption, IMO | 16:25 |
| tobiash | Shrews: awesome, is this ready for review? | 16:26 |
| Shrews | tobiash: yes. well, at least for debate :) | 16:26 |
| * corvus quibbles with the idea that "user manual" and "admin manual" are less "accepted", but i don't at all quibble with the idea that this may be an improvement based on our needs :) | 16:26 | |
| * Shrews does not quibble with that which he himself spouts nonsense about :) | 16:27 | |
| tristanC | corvus: Shrews: perhaps we should drop 'user' and 'admin' section in toc, and instead specify the target audiance at the begining of a document (when it's not clear by the title) | 16:29 |
| fungi | what's the documentation model the reorganization is based on? is it really designed for documenting software which is installed and managed by different people than are interacting with it? | 16:30 |
| Shrews | i believe SpamapS once mentioned the need for more user tutorials, so he may be interested as well | 16:30 |
| Shrews | fungi: see commit message | 16:30 |
| tristanC | Shrews: for example, 'install zuul' and 'create a job' doesn't really need to be tagged 'admin' or 'user' | 16:31 |
| fungi | skimming that blog, it seems to be relevant to software whose admins and users are the same people | 16:31 |
| corvus | Shrews: looking at the "discussions" section, i see "components" between "zuul concepts" and "project gating". concepts and gating are user-focused, components is admin focused | 16:31 |
| fungi | not for documenting services which are run and used by different sets of people | 16:31 |
| corvus | tenant config is also admin focused | 16:31 |
| fungi | how does this documentation restructure prevent users from getting overwhelmed by administrator/operator documentation? | 16:32 |
| Shrews | i agree a clearer delineation between admin/user docs is a need. open to all options others suggest there. | 16:32 |
| corvus | what if we kept the user/admin split, then did the 4 categories in each of those? | 16:33 |
| corvus | (4 categories = tutorials/howtos/discussions/reference) | 16:33 |
| fungi | yeah, separate user documentation from admin documentation but still keeping the substructure under them would make sense | 16:34 |
| corvus | the downside of that is it would be tricky to do general-audience introductory material | 16:34 |
| Shrews | corvus: what do you mean by "kept the user/admin split"? what are we keeping from the existing docs? | 16:35 |
| corvus | (do we duplicate it? or put some of it at the top level as front-matter) | 16:35 |
| fungi | general-audience introductory material could be more appropriate for user documentation, and then have the admin documentation recommend readers also see that | 16:35 |
| *** themroc has quit IRC | 16:35 | |
| corvus | Shrews: https://etherpad.openstack.org/p/7lDwFP6dze | 16:35 |
| fungi | without needing to duplicate it in both | 16:35 |
| corvus | fungi: yeah, could be an option | 16:36 |
| Shrews | oh, not keeping anything, but splitting into separate docs. got it | 16:36 |
| tristanC | fungi: we could generate a "general-audience introductory material" subset of the doc if you are worry it's going to be overwhelming, e.g. we could pick 'tutorial: setup-zuul', 'tutorial: create-a-job', 'howto: configure github-app', ... | 16:37 |
| corvus | Shrews: well, i meant keep the top level of the TOC at https://zuul-ci.org/docs/zuul/ | 16:37 |
| corvus | but then using the second-level from the proposal here | 16:37 |
| Shrews | k | 16:37 |
| tristanC | i find the 'admin' / 'user' split confusing when you are both admin and user, which is likely what happens when you discover zuul.... | 16:38 |
| Shrews | they could share a Reference | 16:38 |
| fungi | i prefer the idea of being able to give users a focused view of only user-oriented documents so they don't need to swim through a mixed list of non-user-related documents | 16:38 |
| corvus | tristanC: yeah, that's a good point, however there are far more user-only users of zuul than combined user+admins. maybe we can make a progression of docs that introduces people to both. | 16:39 |
| Shrews | i think it would be difficult to decide what's an Admin discussion doc and what's a User discussion doc, wouldn't it? what would be the deciding factor there? | 16:39 |
| corvus | it's also possible that we may not want "admin / reference" and all reference should be under user docs or something. | 16:39 |
| fungi | combining them in a big grab-bag of documents for different audiences makes it harder on users when they don't necessarily know the terms or what they're looking for | 16:40 |
| tristanC | corvus: then perhaps should we also split config-project-user and untrusted-user? | 16:40 |
| corvus | Shrews: https://bc90d6750c30bb4706d3-111c5415117c6f7e8c7678caa672fcb9.ssl.cf1.rackcdn.com/701608/6/check/zuul-tox-docs/feabb12/docs/discussions/components.html is def an admin discussion | 16:40 |
| corvus | tristanC: well, the only difference is pipelines. pipelines are another user/admin grey area. but i'm not sure subdividing user is the right answer there... | 16:42 |
| tristanC | well i meant having 'admin' and 'user' docs is better, but it's also more work | 16:42 |
| corvus | Shrews: oh i just saw your "share a reference" idea... yeah. | 16:43 |
| Shrews | i'd argue that discussions seems logical to share, too. a reader will choose to dive in on those when they want to get more in-depth, regardless of if they're user or admin. it's really the tutorials and how-tos that have different audiences | 16:44 |
| corvus | Shrews: yeah -- though "tenant config reference" may be an admin-only reference? | 16:45 |
| tristanC | corvus: a config-project-user could use doc about tenant configuration, global project-pipeline-config, fast localhost job | 16:45 |
| corvus | Shrews: maybe that's not as big of a problem though if we title it well | 16:45 |
| corvus | tristanC: yeah, though i'm not afraid of users accidentally running into that info. | 16:46 |
| Shrews | corvus: yeah, but i don't expect someone to read the reference stuff straight through like a tutorial. so if something there is admin-only, i think that's ok | 16:47 |
| tristanC | Shrews: i agree, I find such doc structure easy to navigate and it's not that of an issue for an user to gloss over admin doc | 16:48 |
| *** sshnaidm is now known as sshnaidm|bbl | 16:48 | |
| tristanC | you may end up reading in a loop 'tutorial -> howto -> reference -> discussion -> tutorial -> ...' | 16:48 |
| openstackgerrit | Merged zuul/zuul-jobs master: Add cri-o support to use-buildset registry https://review.opendev.org/701237 | 16:49 |
| Shrews | yeah, something more of a graduated level of reading: tutorials to get the basics, howtos to solve specific problems, discussions after more familiarity, reference only when needed | 16:50 |
| Shrews | at least for a user | 16:50 |
| Shrews | admins will likely skip tutorials and go straight to howtos (install, configure, monitor). i'm not even sure what an admin-level tutorial is (other than the quick-start) | 16:51 |
| SpamapS | Shrews: very interested in collaborating on tutorial. Very little time to contribute unfortunately. | 16:52 |
| corvus | Shrews: yeah, quickstart -> howto (eg install github app) seems like a reasonable progression for admin | 16:52 |
| SpamapS | The biggest missing tutorial is "I am a dev who has a Zuul somehow, how do I start?" | 16:53 |
| corvus | yep | 16:53 |
| Shrews | SpamapS: yep. thus the empty user tutorial section :) | 16:53 |
| *** avass has joined #zuul | 16:54 | |
| tristanC | SpamapS: if the zuul is empty, then perhaps https://bc90d6750c30bb4706d3-111c5415117c6f7e8c7678caa672fcb9.ssl.cf1.rackcdn.com/701608/6/check/zuul-tox-docs/feabb12/docs/howtos/pti.html ? | 16:55 |
| openstackgerrit | James E. Blair proposed zuul/zuul-helm master: Test helm charts against k8s https://review.opendev.org/701764 | 16:55 |
| Shrews | So, did we come up with an agreed upon change for the user/admin split? Seem there was consensus on a shared discussion/reference section... i think | 16:56 |
| mnaser | corvus: im actually a fan of avoiding running helm's server side component (tiller) which is being removed in helm 3 anyways, so what i like to do is something like: helm template --name <foo> charts/foo | kubectl apply -f- | 16:56 |
| tristanC | mnaser: doesn't "helm install" cli works without tiller? | 16:56 |
| mnaser | only with helm 3, i think | 16:57 |
| SpamapS | tristanC: *Way* too reference-material. I want a step by step thing I can copy/paste into my git tree and see working. | 16:57 |
| SpamapS | mnaser: *has been removed* in 3 (it's out!) | 16:57 |
| SpamapS | We're using it in prod. | 16:57 |
| mnaser | yeah, i'm using helm 3 too (but actually use templates only) | 16:57 |
| SpamapS | (and.. it's got a few bugs) | 16:58 |
| SpamapS | It keeps forgetting bits of the manifests. | 16:58 |
| SpamapS | so upgrades sometimes just go "hey I'm trying to create something that exists" | 16:58 |
| tristanC | Shrews: 'look for and fix config-error' could be a good admin tutorial | 16:58 |
| corvus | Shrews: i think there's general support for trying something like that -- want to take another stab at a TOC? | 16:58 |
| mnaser | SpamapS: yeah, that's been my similar experience, so we have argocd doing the application of manifests and what not, and helm to template them out | 16:58 |
| Shrews | corvus: sure. will try something after lunch | 16:58 |
| tristanC | Shrews: thanks again for putting the new doc for discussion, that's a lot of work! | 16:59 |
| corvus | ++ | 16:59 |
| corvus | (this is hard) | 16:59 |
| SpamapS | mnaser: good to know I'm not alone! ;) | 16:59 |
| *** mattw4 has joined #zuul | 17:00 | |
| corvus | mnaser: we should have this test job use argo :) | 17:00 |
| * mnaser has a call but will comment in a bit about that | 17:01 | |
| openstackgerrit | Albin Vass proposed zuul/zuul master: Force fetch when updating merger repositories https://review.opendev.org/701753 | 17:01 |
| avass | oops | 17:01 |
| mordred | avass: haha | 17:03 |
| *** tosky has quit IRC | 17:05 | |
| *** tosky has joined #zuul | 17:06 | |
| openstackgerrit | Merged zuul/zuul master: Only report to changes in gerrit https://review.opendev.org/696459 | 17:18 |
| fungi | clarkb: i think you also said https://review.opendev.org/701753 sounded like a fine idea? | 17:21 |
| clarkb | I did, shoudl I approve it? | 17:22 |
| corvus | ++ | 17:23 |
| clarkb | done | 17:24 |
| openstackgerrit | James E. Blair proposed zuul/zuul-helm master: Test helm charts against k8s https://review.opendev.org/701764 | 17:29 |
| *** jpena|off is now known as jpena | 17:31 | |
| *** evrardjp has quit IRC | 17:33 | |
| *** evrardjp has joined #zuul | 17:34 | |
| *** sshnaidm|bbl is now known as sshnaidm | 17:38 | |
| corvus | mnaser: what's the plan for supplying a nodepool.yaml file for the helm charts? | 17:39 |
| corvus | mnaser: am i reading it right that it's expected to be a secret? | 17:42 |
| mnaser | corvus: the idea is that you would provide the 'config' key and it would write it out as yaml inside the secret which is then mounted inside /etc/nodepool in the container | 17:43 |
| mnaser | so in your values.yaml file (when running helm template or install), you'd have somethiong like: config:\n foo: bar ... | 17:44 |
| corvus | mnaser: ah, i see that now, lines 10-14 in charts/nodepool/values.yaml | 17:45 |
| corvus | cool, i think that makes sense, thanks | 17:45 |
| mnaser | np! | 17:55 |
| corvus | mnaser: i just argo'd a nodepool: http://paste.openstack.org/show/788213/ | 18:09 |
| corvus | the builder is in a crash loop, but hey | 18:10 |
| mnaser | corvus: #progress ! | 18:10 |
| mnaser | corvus: small tip is `kubectl logs statefulset/nodepool-builder` so you avoid having to look up the pod name | 18:11 |
| mordred | corvus: look at your argoing! | 18:12 |
| corvus | oh here's why it's crashing: RuntimeError: No ZooKeeper servers specified in config. | 18:12 |
| corvus | that makes sense :) | 18:12 |
| mordred | zuul does not work well without zookeeper servers | 18:12 |
| openstackgerrit | James E. Blair proposed zuul/zuul-helm master: Change builder container name https://review.opendev.org/701793 | 18:13 |
| corvus | look a real change | 18:14 |
| mnaser | corvus: in our deployment i used the zookeeper helm charts | 18:15 |
| mordred | corvus: I understand that one! | 18:15 |
| mnaser | and then pointed to it | 18:15 |
| corvus | mnaser: these? https://github.com/helm/charts/tree/master/incubator/zookeeper | 18:18 |
| mnaser | corvus: yep! | 18:18 |
| *** bhavikdbavishi has quit IRC | 18:18 | |
| corvus | cool, then that's my next step, along with giving a a custom values set to argo | 18:19 |
| openstackgerrit | Merged zuul/zuul master: Force fetch when updating merger repositories https://review.opendev.org/701753 | 18:20 |
| corvus | mnaser, mordred: where were we on the "version bump" issue? https://zuul.opendev.org/t/zuul/build/789e42d8129944df8d47354d5ad26667 | 18:21 |
| mnaser | ya, welcome to helm charts where you're supposed to bump version on every. single. change. | 18:21 |
| mnaser | so you can do smoething like 0.0.2 | 18:21 |
| corvus | i would like to reject the premise. is that an option? :) | 18:22 |
| mordred | yeah - that seems kinda anti CD and hard with specualtive gating | 18:22 |
| mnaser | pretty much what i was strugglin with because the idea while you can use argo to point towards a repo | 18:23 |
| mnaser | someonew who's using straight helm needs to point at a .tar.gz that's hosted somewhere for a helm index | 18:23 |
| corvus | do you know if argo cares about the version? | 18:24 |
| mnaser | so you couldn't CD using those helm charts because the "dependency" system relies on versioning and actual .tar.gz | 18:24 |
| mnaser | argo does not care about the version, but if someone wants to consume those charts into their own chart (i.e. if i make my own zuul-system), i have to use the helm requirements.yaml which requires an explicit version pointing at a published .tgz | 18:24 |
| corvus | this system has... flaws. | 18:25 |
| mnaser | yes, it's VERY much not based with any thought of CD. | 18:25 |
| mnaser | for example, all of our monitoring infra is in a chart which depends on a few other smaller charts | 18:26 |
| mnaser | if i need to bump chart "foo" which is used in "monitoring". i have to bump foo from 1.0.0 to 2.0.0, then i have to PUBLSIH 2.0.0, and then i have to bump the dependency of "monitoring" for "foo" from 1.0.0 to 2.0.0 | 18:27 |
| *** sgw has quit IRC | 18:27 | |
| mnaser | because the dependencies (.tar.gz) are downloaded during build time | 18:27 |
| mnaser | and apparently using file:// references is fRoWnEd uPoN | 18:27 |
| corvus | mnaser: well, anyway, we can make speculative helm repos like you were discussing the other day to help with that... | 18:27 |
| corvus | but i think maybe the versioning within zuul-helm is a different issue. basically, it seems like we need to do the pbr thing here | 18:28 |
| mnaser | ya, i mean, im not opposed to like | 18:29 |
| mordred | yeah. | 18:29 |
| mnaser | finding a better approach. | 18:29 |
| Shrews | corvus: of the howtos listed in https://bc90d6750c30bb4706d3-111c5415117c6f7e8c7678caa672fcb9.ssl.cf1.rackcdn.com/701608/6/check/zuul-tox-docs/feabb12/docs/howtos/index.html its seems those all would fall under admin howtos, yes? | 18:29 |
| mordred | maybe we need to do a pbr-like tool that produces a values file? | 18:29 |
| corvus | mordred: i think it needs to edit the Chart.yaml ? | 18:29 |
| mordred | yeah. maybe the tool need to do that | 18:29 |
| *** jpena is now known as jpena|off | 18:29 | |
| mnaser | yeah Chart.yaml is what needs to be modified for the version correct | 18:29 |
| mordred | but maybe we run it in jobs and also before making the tar.gz ? | 18:29 |
| mnaser | wait wait | 18:30 |
| mnaser | i just got an idea | 18:30 |
| mordred | just thinking out loud | 18:30 |
| mordred | awesome | 18:30 |
| corvus | mordred: yeah, i think that would do the trick..... /me waits for mnaser's idea | 18:30 |
| mnaser | i think when you run a helm build | 18:30 |
| mnaser | you can override version in command line | 18:30 |
| * mnaser double checks | 18:30 | |
| mnaser | yes, "helm package" has an option called --version | 18:30 |
| mnaser | --version string set the version on the chart to this semver version | 18:30 |
| *** notnone is now known as at_work | 18:30 | |
| corvus | Shrews: install, zfs are admin; cross-project gating, pti, badges are user; troubleshooting is admin | 18:31 |
| *** electrofelix has quit IRC | 18:31 | |
| mnaser | helm package --version 0.1.1-dev123 . | 18:31 |
| mnaser | Successfully packaged chart and saved it to: /home/mnaser/src/github.com/vexxhost/helm-charts/charts/dell-exporter/dell-exporter-0.1.1-dev123.tgz | 18:31 |
| mnaser | ooou neat | 18:31 |
| corvus | mnaser, mordred: also it looks like we can --check-version-increment=false on the linter | 18:32 |
| corvus | so between that and setting --version on publish jobs, we're probably good -- we can just ignore the version in the repo | 18:33 |
| corvus | gotta run | 18:33 |
| mnaser | i think if we adopt that pattern (and drop --check-version-increment) in the zuul/zuul-jobs we want to deliver the whole "set" of jobs from ci to publish | 18:34 |
| mnaser | that way the behaviour is predictable for users | 18:34 |
| openstackgerrit | David Shrewsbury proposed zuul/zuul master: Documentation reorg https://review.opendev.org/701608 | 18:44 |
| *** tosky has quit IRC | 18:48 | |
| Shrews | that PS offers a user/admin split. we could do away with the "Zuul Users"/"Zuul Admins"/"Digging Deeper" headers I guess as another option | 18:52 |
| mordred | mnaser: ++ | 18:54 |
| *** sgw has joined #zuul | 18:56 | |
| pabelanger | corvus: tristanC: clarkb: could we priorities https://review.opendev.org/678273/ ? this is related to https://review.opendev.org/660856/ which was skip file maters on periodic pipelines | 19:17 |
| pabelanger | prioritize* | 19:18 |
| *** pcaruana has quit IRC | 19:35 | |
| corvus | pabelanger: ack will do | 19:36 |
| pabelanger | thank you | 19:38 |
| openstackgerrit | James E. Blair proposed zuul/zuul-jobs master: Move chart-testing to a role and disable version check https://review.opendev.org/701822 | 19:48 |
| corvus | mnaser, mordred: ^ | 19:48 |
| openstackgerrit | James E. Blair proposed zuul/zuul-helm master: Change builder container name https://review.opendev.org/701793 | 19:48 |
| corvus | now i make tacos | 19:49 |
| fungi | mmmtacos | 19:58 |
| *** openstackgerrit has quit IRC | 19:59 | |
| *** mhu has quit IRC | 20:02 | |
| pabelanger | clarkb: unrelated, but do you know if pip python environment markers can be used via CLI? or only in requirement files | 21:02 |
| webknjaz | Yes but don't forget to quote/escape the whole def if you have spaces | 21:04 |
| pabelanger | webknjaz: thanks | 21:06 |
| *** openstackgerrit has joined #zuul | 21:19 | |
| openstackgerrit | Merged zuul/zuul-jobs master: Add basic Helm jobs https://review.opendev.org/700222 | 21:19 |
| fungi | pabelanger: just to parrot what webknjaz said, i've used them from the command-line fine but yes stuff like semicolons does need careful escaping | 21:22 |
| clarkb | pabelanger: sorry I didn't get back earlier. But looks like you got your answer | 21:26 |
| * clarkb has been distracted with paperwork today | 21:26 | |
| clarkb | I should finish that up so I can focus on work work soon | 21:26 |
| pabelanger | fungi: webknjaz: clarkb: yup, worked as expected. thanks! | 21:26 |
| *** michael-beaver has quit IRC | 21:27 | |
| *** Goneri has quit IRC | 21:41 | |
| corvus | mnaser: https://review.opendev.org/701822 made my helm change pass | 22:14 |
| mnaser | corvus: neat! | 22:18 |
| corvus | mnaser: did you use argo to deploy zk? if so, did you use a release or the git repo? | 22:21 |
| mnaser | corvus: i have my own "local" chart that is pinned to the latest (at the time) release | 22:22 |
| mnaser | sorry, my local chart with depends on the zookeeper one | 22:23 |
| corvus | mnaser: ah, gotcha | 22:23 |
| mnaser | i have no values defined so i just use the out of the box values | 22:23 |
| corvus | mnaser: so you're sort of a few steps ahead with a system chart | 22:24 |
| mnaser | yes, but i haven't had time to "generalize" it | 22:24 |
| corvus | ack | 22:24 |
| mnaser | the thing that also made it hard is im not sure how to do the "system" chart inside the main repo, unless we use file:/// inside the requirements for it | 22:25 |
| openstackgerrit | Merged zuul/zuul-helm master: Added nodepool to charts https://review.opendev.org/700462 | 22:26 |
| mnaser | corvus, mordred: as we're starting to merge things to zuul/zuul-helm, i'd like my deployment to actually start pointing at it | 22:27 |
| mnaser | given that will be useful is helping us find any possible issues, but i'd appreciate if we can treat it as "hey lets not break a downstream user" as i would like to CD it | 22:28 |
| mnaser | i could pin to commits but that seems probably counterintuitive :> | 22:28 |
| corvus | mnaser: i have the same goals. but we may still need to intentionally break some stuff in the early days, but if so, we can probably just coordinate here until things settle. | 22:29 |
| mordred | i'd love for you to CD it too ... I think we should make sure we're happy enough with a CI job before you do - maybe let's at least get https://review.opendev.org/#/c/701764/ in before you start CDing from upstream repo? | 22:30 |
| mnaser | corvus: ya im totally ok to break it, but "hey we're breaking this" is all im asking (i'm cool with working around it rather than having to engineer a ton of backwards compatibility) | 22:30 |
| corvus | hrm, apparently "--generate-name" is unknown to helm? | 22:31 |
| mnaser | mordred: given that it's 100% matching what im running and i dont want to maintain my local nodepool code anymore, it's ok _enough_ for me, but yes, i'm going to work on the job too | 22:31 |
| openstackgerrit | Merged zuul/zuul-jobs master: Move chart-testing to a role and disable version check https://review.opendev.org/701822 | 22:31 |
| mnaser | wee, because i was using these nodepool charts 100% as is, it was noop | 22:36 |
| mnaser | corvus: is it okay if i take over your nodepool testing change? | 22:38 |
| corvus | mnaser: please | 22:49 |
| openstackgerrit | Mohammed Naser proposed zuul/zuul-helm master: Test helm charts against k8s https://review.opendev.org/701764 | 22:51 |
| mnaser | corvus: ok cool! i'm going to start building out the "zuul-system" chart and use that for testing | 22:51 |
| corvus | mnaser: it looks like zookeeper-0.6.4 is the latest release, but it's from 2018. is that what you're using? | 22:55 |
| fungi | that sounds like some mighty stable software | 22:57 |
| corvus | fungi: well, the contents of the git repo are much more recent | 22:58 |
| fungi | ahh, so maybe they just disagree with esr's advice about release frequency | 22:58 |
| mnaser | https://review.opendev.org/#/c/701764/4/charts/zuul-system/requirements.yaml | 22:58 |
| mnaser | which i stole from https://github.com/helm/charts/blob/master/incubator/zookeeper/Chart.yaml#L4 | 22:59 |
| mnaser | which runs 3.5.5 according to the chart | 22:59 |
| corvus | mnaser: that says it's running chart version 2.1.3, but i don't see that at http://storage.googleapis.com/kubernetes-charts-incubator | 23:02 |
| corvus | i only see 0.6.4; what am i missing? | 23:03 |
| corvus | but huh, http://storage.googleapis.com/kubernetes-charts-incubator/zookeeper-2.1.3.tgz exists | 23:03 |
| mnaser | corvus: i think the problem is that the directory listing is limited (hence NextMarker), helm uses an index file to find things | 23:03 |
| mnaser | http://storage.googleapis.com/kubernetes-charts-incubator/index.yaml | 23:04 |
| mnaser | (warning a 763kb yaml file) | 23:04 |
| corvus | is that how you find that 2.1.3 is the magic number? | 23:04 |
| corvus | (since they didn't put that in the docs) | 23:04 |
| mnaser | corvus: the magic number is 2.1.3 by looking at what Chart.yaml points in master (because they run chart-testing and force you to bump version for every change) | 23:04 |
| mnaser | and they publish .. every .. single .. change | 23:04 |
| corvus | wow, ok. thx | 23:05 |
| mnaser | yeah, hence the ~760kb index... and thats not even for the "stable" repo | 23:05 |
| fungi | maybe they've taken the continuous deployment "every change is a release" mantra to heart? | 23:05 |
| mnaser | the stable repo is 7.1MB yaml file | 23:05 |
| mnaser | 9709 total releases for the stable repo according to my simple grepping | 23:06 |
| fungi | yeesh | 23:08 |
| mnaser | this was noe of the thing that made it hard for me to build a 'speculative' repo server | 23:09 |
| mnaser | was that id have to index all of that to know if i should go upstream or use local build | 23:09 |
| fungi | hopefully parsing ~10k version records isn't too slow | 23:10 |
| mnaser | parsing a ~8mb yaml file is about as wild as you think it is | 23:10 |
| mnaser | lol | 23:10 |
| fungi | oh, it's more than just git tags? yeah, that's a boatload of yaml, and you're going to need a bigger boat | 23:13 |
| fungi | it's all fun and games until someone loses an i | 23:13 |
| mnaser | yeah its not git tags heh | 23:16 |
| openstackgerrit | Mohammed Naser proposed zuul/zuul-helm master: Test helm charts against k8s https://review.opendev.org/701764 | 23:18 |
| clarkb | fungi: where we're going we don't need speed | 23:22 |
| clarkb | I guess that is what happens when you get off road. you slow down | 23:22 |
| corvus | mnaser: i'm struggling a bit with how to provide a nodepool.yaml. i understand that it can go in values.yaml, and that i could provide an alternate values.yaml with my own config. that's fine, except that if i want to have argo do that, it has to be in the app repo. so if i want to point argo at zuul/zuul-helm for nodepool, then that means my nodepool.yaml needs to be in a values file in that repo. | 23:22 |
| mnaser | corvus: correct, so the way i work around that is i declartively add apps | 23:22 |
| mnaser | and ill do soemthing like this | 23:22 |
| mnaser | corvus: http://paste.openstack.org/show/788220/ | 23:24 |
| mnaser | (i dont use the cli or ui, so i just declartively define apps like that) | 23:24 |
| corvus | ooooh | 23:24 |
| corvus | okay, that's opening up a new set of options, thanks :) | 23:24 |
| mnaser | there's also another way but it's super annoying and unsustainable where you proivde a yaml path | 23:25 |
| mnaser | so something lik name: config.labels[0].name\nval: foo and that would explode forever | 23:25 |
| corvus | mnaser: yeah, i was on the edge of writing "yaml -> parameter override" converter for that but realized that's insane. | 23:25 |
| mnaser | yeah i learned about the values thing recently | 23:26 |
| mnaser | i had the same challenge for a while | 23:26 |
| corvus | cool, i will go try that now :) | 23:26 |
| pabelanger | mnaser: looking at your example, that means nodepool.yaml lives inside your helm chart? | 23:28 |
| pabelanger | assuming that is a helm chart | 23:28 |
| corvus | pabelanger: it's an argocd declaration (which points to a helm chart) | 23:28 |
| mnaser | pabelanger: it would live in the argocd application definition which is fed into the actual chart. think i'm providing an ansible vars file to an existing role | 23:29 |
| pabelanger | thanks, googling | 23:29 |
| corvus | we could probably write a zuul-jobs role to template in a file into the "helm.values" thing so we could make it a little more user-friendly | 23:29 |
| clarkb | does that mean the nodepool charts require argo to be useful? | 23:30 |
| openstackgerrit | Mohammed Naser proposed zuul/zuul-helm master: Test helm charts against k8s https://review.opendev.org/701764 | 23:31 |
| pabelanger | yah, it would be awesome to say have argocd read the existing nodepool.yaml file, some how (not that I'm involved here :)) | 23:31 |
| corvus | clarkb: nope | 23:32 |
| mnaser | clarkb: nope, as a matter of fact the test code im building above is only using helm | 23:32 |
| mnaser | pabelanger: the idea is that you can literally copy-paste your existing nodepool.yaml and it'll feed it in | 23:32 |
| corvus | clarkb: this is mostly "how to get argo to do the --values thing you do with helm" :) | 23:32 |
| corvus | \o/ https://imgur.com/a/SptBID8 | 23:32 |
| mnaser | so you could technically shut down your existing nodepool, run the helm chart with your existing config, and everything will start back up | 23:32 |
| corvus | that's an argo, a zk, and a nodepool launcher running | 23:32 |
| mnaser | wee | 23:33 |
| clarkb | corvus: I see, supporting both rather than just argo | 23:33 |
| corvus | clarkb: yep. my tiny summary of argo is "something that runs helm for you" | 23:33 |
| mnaser | ^^^ yep, watches a repo and applies thing | 23:33 |
| clarkb | and uses redis apparently | 23:34 |
| clarkb | be sure to set memory limits on the redis container :) | 23:34 |
| corvus | (or even, disable the watching part and have zuul run argo (to run helm)) | 23:35 |
| pabelanger | mnaser: right, copy it sounds like. Not point to file and use some sort of magic to open, ready yaml content, close file | 23:35 |
| mnaser | pabelanger: yeah because the 'file' has to live in a kubernetes secret | 23:36 |
| mnaser | woo | 23:37 |
| mnaser | that job managed to apply all resources! | 23:37 |
| pabelanger | mnaser: okay cool, thanks. Trying to map the layers into brain :) | 23:38 |
| mnaser | minirant: i hate how we take 25 minutes to setup our test env and k8s takes like... a minute or two | 23:39 |
| mnaser | ok now i only need to add a small piece of code to wait for all pods to become ready | 23:39 |
| clarkb | mnaser: you know that like 50% of that is waiting on api calls right? | 23:39 |
| mnaser | cause the charts are applying | 23:39 |
| clarkb | mnaser: I rewrote keystone setup in python and cut a ton of time off devstack | 23:39 |
| clarkb | (and then there is setup for all the other services) | 23:40 |
| mnaser | clarkb: did that end up landing too btw? :> | 23:40 |
| clarkb | no it was quite a bit hacky. more a PoC to show people "look devsdtack is slow because osc is inefficient" | 23:40 |
| clarkb | entrypoints kill us as does provisioning a new token for each command (and needing to list the catalog and all that stuff each time too) | 23:41 |
| clarkb | if we switch to a single process we can take all the overhead and run it once | 23:41 |
| mnaser | ah | 23:43 |
| openstackgerrit | Mohammed Naser proposed zuul/zuul-helm master: Test helm charts against k8s https://review.opendev.org/701764 | 23:43 |
| mnaser | ok, so the above should be a full run. if that works, i'll take the role to run a helm chart against a kubernetes cluster and export it out to zuul/zuul-jobs because i can make use of that too :) | 23:44 |
| clarkb | mnaser: https://review.opendev.org/#/c/673108/6/tools/create_keystone_accounts.py if you are curious. I sent email about it and tried to get more interest in the problem space. Unfortunately I think "it works but is slow" is good enough for most people | 23:44 |
| fungi | yeah, in the spirit of "let's make sure we test like a user would interact with the services" i get the attraction, but osc is just not efficient being called over and over in tight scripted loops | 23:45 |
| pabelanger | mnaser: we are also spoiled, I'd happily wait 25mins vs manually testing any day | 23:45 |
| corvus | \o/ http://paste.openstack.org/show/788221/ | 23:45 |
| mnaser | weee | 23:45 |
| corvus | that's a min-ready node :) | 23:45 |
| clarkb | corvus: using the gce driver? | 23:46 |
| pabelanger | looks like it | 23:46 |
| corvus | yep | 23:46 |
| pabelanger | that's neat | 23:46 |
| corvus | that's in the gerritcodereview-ci project (what will become the production deployment of gerrit's zuul) | 23:46 |
| corvus | i think i just about have enough to start pushing up a change | 23:46 |
| pabelanger | corvus: how are you solving privileged containers? Do you have your own k8s in google cloud? | 23:47 |
| openstackgerrit | James E. Blair proposed zuul/zuul-helm master: Add empty clouds value https://review.opendev.org/701865 | 23:47 |
| corvus | pabelanger: GKE instances are privileged by default | 23:47 |
| pabelanger | ah | 23:47 |
| pabelanger | some reason openshift went the other way :) | 23:48 |
| clarkb | pabelanger: gke is quite a bit more relaxed about perms and stuff than say openshift | 23:48 |
| pabelanger | clarkb: yah | 23:48 |
| SpamapS | Do we still need privileged executors? | 23:48 |
| pabelanger | think so | 23:48 |
| SpamapS | I thought new bwrap + new kernel meant no. | 23:48 |
| SpamapS | I still have privileged executors but was just wondering. | 23:49 |
| pabelanger | I'm not up to speed, but I don't think anybody has tested? | 23:49 |
| tristanC | SpamapS: userns are still blocked by seccomp at least | 23:50 |
| SpamapS | Ahh, so you have to reconfigure docker to disable those blocks. | 23:51 |
| SpamapS | or cri-o or whatever you're using ;) | 23:54 |
| tristanC | I implemeted almost all of the Zuul CR defined in https://zuul-ci.org/docs/zuul/developer/specs/kubernetes-operator.html, for example given: https://github.com/TristanCacqueray/dhall-zuul/blob/master/operator/examples/zuul-cr.yaml the operator applies: https://github.com/TristanCacqueray/dhall-zuul/blob/master/deployments/cr-k8s.yaml | 23:58 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!