| *** igordc has quit IRC | 00:09 | |
| *** rfolco has quit IRC | 00:45 | |
| *** sgw has quit IRC | 01:16 | |
| *** sgw has joined #zuul | 01:34 | |
| *** noorul has joined #zuul | 02:09 | |
| *** saneax has joined #zuul | 02:22 | |
| *** noorul has quit IRC | 02:47 | |
| *** noorul has joined #zuul | 02:52 | |
| *** rfolco has joined #zuul | 02:52 | |
| *** noorul has quit IRC | 02:57 | |
| *** noorul has joined #zuul | 03:08 | |
| *** noorul has quit IRC | 03:29 | |
| *** noorul has joined #zuul | 03:58 | |
| *** noorul has quit IRC | 04:39 | |
| *** noorul has joined #zuul | 04:42 | |
| *** noorul has quit IRC | 05:03 | |
| *** saneax has quit IRC | 05:55 | |
| *** pcaruana has quit IRC | 07:14 | |
| *** pcaruana has joined #zuul | 07:24 | |
| *** gtema has joined #zuul | 07:40 | |
| *** gtema has quit IRC | 08:19 | |
| *** bjackman has joined #zuul | 09:40 | |
| *** bjackman has quit IRC | 10:00 | |
| *** bjackman has joined #zuul | 13:06 | |
| *** bjackman has quit IRC | 13:11 | |
| pabelanger | Was pointed to https://developer.github.com/changes/2019-09-05-apps-protected-branches-api/ by gundalow! This is huge for us, it finally gives a way to remove commit access to a github repo (branch) and only have zuul merge | 13:58 |
|---|---|---|
| pabelanger | I've confirmed it works too | 13:58 |
| pabelanger | tobiash: SpamapS: ^you likey are interested^ | 13:58 |
| corvus | pabelanger: cool! can you see if our docs on how to set up the app need to be updated? | 13:59 |
| fungi | gundalow is a celebrity now! | 14:00 |
| tobiash | pabelanger: I don't believe that this finally happened :) | 14:00 |
| pabelanger | corvus: ++ can propose that for monday | 14:00 |
| pabelanger | tobiash: IKR | 14:00 |
| pabelanger | now, if only they allow users to +A their own PR in review | 14:01 |
| fungi | oh, wait, i guess you mean gundalow pointed out that article to you, didn't develop the feature | 14:01 |
| fungi | still cool find | 14:01 |
| pabelanger | fungi: yah, I know ansible had a meeting with github a while back, asking for things to make life better on github | 14:01 |
| pabelanger | IIRC, I asked for github apps branch protections, and 2 account issues for reviews | 14:01 |
| fungi | sounds like it was a worthwhile discussion | 14:02 |
| pabelanger | I hope it was too! | 14:02 |
| pabelanger | jlk: big thanks to humans on github side for new feature :D | 14:02 |
| gundalow | Just pointed it out, though it's something I've been pushing for. | 14:39 |
| *** rfolco has quit IRC | 15:04 | |
| *** zxiiro has quit IRC | 17:10 | |
| *** zxiiro has joined #zuul | 17:11 | |
| *** saneax has joined #zuul | 17:20 | |
| *** noorul has joined #zuul | 17:21 | |
| *** saneax has quit IRC | 17:37 | |
| gundalow | I have lots of contacts at GitHub now, so if you have any requests (big or small) please let me know and I'll pass them on | 18:10 |
| mnaser | is there any interest in perhaps looking into moving the zuul operator to a golang based one instead of an ansible one? | 18:11 |
| mnaser | the reason is i'm trying to go more towards adding more resources (imagine things like Tenant, Project, etc) | 18:13 |
| mnaser | and the more complex these things get (and involve making a bunch of API calls possibly) the most it's easier to use a programming language to accomplish them.. | 18:14 |
| mnaser | i guess alternatively i was also looking at Kopf | 18:14 |
| mnaser | which is python based: https://kopf.readthedocs.io/en/latest/ | 18:14 |
| tristanC | mnaser: it shouldn't be an issue to manage many custom resources with ansible, and we can always write a python module library to perform complex tasks | 18:20 |
| mnaser | tristanC: i just figured longer term it'd be easier especially for branching out to avoid things like register and when: ... when it can probably easier/cleaner to have code that does that | 18:21 |
| mnaser | but i guess if we go that path then yeah we can probably write zuul_tenant or zuul_project etc | 18:21 |
| tristanC | mnaser: i proposed to include extra resources for tenant, connections, nodepool objects, but this was replaced by a single Zuul and Nodepool resources | 18:22 |
| mnaser | tristanC: any reason in particular (or maybe i can go back and read that?) .. it seems like it might be easier to let a user manage those resources like that rather than a singular abstract zuul resource | 18:22 |
| tristanC | mnaser: https://review.opendev.org/#/c/659180/1/doc/source/developer/specs/kubernetes-operator.rst@42 and https://review.opendev.org/#/c/659180/8/doc/source/developer/specs/kubernetes-operator.rst@157 | 18:23 |
| mnaser | it can introduce delegation because we can use rbac to lock down certain things (i.e new project additions) | 18:23 |
| tristanC | rbac would have been a good argument for extra resources... perhaps this can be implemented later | 18:24 |
| mnaser | its an interesting balance of flexibiltiy vs ease of use | 18:25 |
| mnaser | right now its a neasy way to get going but if i want to deploy $db in my own way, it's not really possible for me | 18:25 |
| tristanC | mnaser: iirc the spec mention being able to override the dburi by something deployed outside of the operator | 18:26 |
| mnaser | other projects have solved this long term by making the operator really low level (i.e. prometheus-operator) and then having a project that's batteries included (kube-prometheus) | 18:26 |
| mnaser | and one uses the other. but yeah, seems like this is already gone to the more "distro" side of things | 18:27 |
| pabelanger | yah, you shouldn't need to consume db from zuul operator, IIRC is was optional | 18:47 |
| pabelanger | I'm not sure how it will look for our operator, but I really like the 'here is a thing, and it is installed and basically working' approach. Then I can use new tooling or maybe same to add things like tenant, etc. If we try to build an all-in-one solutions for all, that is going to contain a log of business logic IMO | 18:49 |
| pabelanger | I'm also not a fan anymore of having a system be complex in templating a bunch of things, then go through a few layers to produce a config file. It is great when you have time / work with it every day, but after you step away and swift back, you totally forget how all that works. I'd much rather store the config file in git or encrypt it | 18:51 |
| *** noorul has quit IRC | 18:54 | |
| *** noorul has joined #zuul | 19:04 | |
| *** hashar has joined #zuul | 19:26 | |
| tristanC | pabelanger: with k8s, the service environment is going to be well controlled, i don't think the zuul configuration really needs to be exposed. what kind of config do you think the user will need to manage? | 19:52 |
| tristanC | in software factory, the user can only set the domain name for merger.git_user_email, some limits for executor.min_avail_{hdd,mem} and the executor.disk_limit_per_job | 19:55 |
| *** noorul has quit IRC | 20:01 | |
| *** mattw4 has joined #zuul | 20:12 | |
| *** hashar has quit IRC | 20:27 | |
| pabelanger | tristanC: in the case of puppet-zuul or puppet-nodepool, we had the issue each time we added a new setting or wanted to expose another setting, it was about 5 layers of changes needed to allow it. Because we had puppet-openstackci, what users were to use. Now I know the design of operator is a little different, but I've stopped having $cfgmgt be the interface to user for changing settings, if we want to do | 20:35 |
| pabelanger | that, awesome, but also would like to just access raw config directly. Otherwise, in your example above with SF, we'd need a new release of SF to support the next setting | 20:35 |
| pabelanger | not to say it is wrong, just I'd prefer not to have it | 20:35 |
| pabelanger | templating of templating of templates gets old, especially when you are old :) A lot to mental map | 20:36 |
| pabelanger | as example, even https://github.com/ansible-network/windmill-config/blob/master/zuul/zuul.conf.j2 has too much if / else for my liking but I haven't found time to work on zuul.d for zuul services | 20:38 |
| * pabelanger heads off to work in garage again | 20:38 | |
| tristanC | pabelanger: the main advantage is that this provides a clear interface for the user which is easier to manage from the operator devel point of view. We do need to update the template to support extra knobs, but that also helps preventing erroneous or incompatible user-provided raw configuration. | 20:46 |
| tristanC | actually, it seems like the operator specs doesn't specify user-provided zuul.conf configuration, only the main.yaml and nodepool.yaml are provided raw by the user | 20:50 |
| corvus | yeah, i expect zuul.conf to be generated by the operator | 20:51 |
| corvus | (because the operator needs to know things about database, zk, connections, etc, so it's appropriate for it to generate it) | 20:52 |
| corvus | there's no reason for the operator to care about tenants, so the tenant config just gets passed through. you can generate that however you like | 20:54 |
| corvus | i believe the nodepool config is *mostly* passed through -- except that we'll shard it so we have one launcher per provider | 20:55 |
| corvus | that's an example of where the configuration does relate to the deployment topology -- but only a little. | 20:56 |
| corvus | and i think that's main determination in whether having the operator do something adds value: "does this interact with the deployment topology?" | 20:57 |
| tristanC | mnaser: it seems like a higherlevel operator could implement a ZuulTenant resources resulting in a generated zuulYamlConfig | 21:01 |
| *** armstrongs has joined #zuul | 21:33 | |
| *** armstrongs has quit IRC | 21:39 | |
| *** mattw4 has quit IRC | 21:44 | |
| SpamapS | ehhhh | 21:44 |
| SpamapS | tristanC: what would be the benefit of that versus just passing in the yaml file? | 21:45 |
| tristanC | SpamapS: mnaser mentioned that through k8s rbac, you could let things create tenant but not connections for example | 21:48 |
| mnaser | yep, so having the yaml generated by using other existing resources (so zuul resource can watch for tenant, and when it changes, it updates the configmap of zuul and reloads) | 21:49 |
| tristanC | SpamapS: and in software factory, we generate the zuul tenant configuration from a more generic "resources" description that we use to generate others service config (such as code-search, cgit, ...). Thus we don't want the enduser to bother with zuul tenant configuration, thus we will likely create such higher level operator. | 21:50 |
| mnaser | imho the operator can have many low level resources (and you can have some $distro) that uses all those resources to build something ready to go for you | 21:51 |
| tristanC | SpamapS: SF resources also let each tenant manage their list of source repositories. For example https://softwarefactory-project.io/zuul/t/ansible/projects is generated from https://github.com/ansible/zuul-config/blob/master/resources/ansible.yaml | 21:53 |
| SpamapS | hm | 21:53 |
| SpamapS | I think that we should consider a tenant service, rather than abusing k8s for it. | 21:53 |
| SpamapS | I've wanted that for a while. We implemented something like it for BonnyCI. | 21:54 |
| tristanC | SpamapS: what do you mean by tenant service? | 21:54 |
| SpamapS | A Zuul API endpoint for tenant maintenance. | 21:54 |
| SpamapS | For instance, it would be ideal if one could add tenants by installing the github app on a repo. | 21:54 |
| tristanC | SpamapS: oh yes, that would be even easier if zuul let us inject tenant and source-repositories through an API | 21:55 |
| SpamapS | https://github.com/BonnyCI/integration-handler | 21:55 |
| SpamapS | This was specific to github events. But I think it's a generic problem. | 21:56 |
| SpamapS | And frankly, handling github events would cover quite a few users' needs. Doing this in the K8S operator would only solve it for K8S users. | 21:58 |
| tristanC | SpamapS: well, that's the idea of such higherlevel operator, something that converts external information to a zuulYamlConfig (that is managed by the lowerlevel zuul-operator) | 21:59 |
| tristanC | the current zuul-operator specification doesn't conver such things, the Zuul CRD spec except a configmap with the main.yaml content | 22:00 |
| SpamapS | Yeah, I see the point, but I believe it would be simpler and more useful as python in zuul itself. | 22:04 |
| SpamapS | With the state stored in zookeeper, and the tenant yaml mostly being a way to get things into the service without using the API. | 22:05 |
| SpamapS | That would also be more aligned with the auth system, since you'd use the same auth system for interacting with zuul's current API and the tenant configs. | 22:07 |
| *** saneax has joined #zuul | 22:33 | |
| *** saneax has quit IRC | 22:55 | |
| fungi | is zk a good long-term/durable configuration store, or does it need to be backed up with some other sort of database service so the data persists through cluster restarts? also, how easy would it be to manage that configuration if the zuul configuration api was offline (basically poke values directly into zk, i guess?) | 23:08 |
| *** logan- has quit IRC | 23:59 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!