| *** yassine has joined #softwarefactory | 00:35 | |
| *** yassine is now known as Guest17713 | 00:35 | |
| *** caowei has joined #softwarefactory | 02:23 | |
| *** Guest17713 has quit IRC | 02:28 | |
| *** Guest17713 has joined #softwarefactory | 02:43 | |
| *** sfbender has joined #softwarefactory | 03:43 | |
| sfbender | Tristan de Cacqueray created software-factory/sf-ci master: repos: fix missing contentdir variable https://softwarefactory-project.io/r/12183 | 03:43 |
|---|---|---|
| dmsimard | tristanC: I was also seeing that error in DIB builds on review.rdo | 04:04 |
| dmsimard | apparently it made our nodepool builder loop and fill it's disk | 04:05 |
| tristanC | dmsimard: perhaps we should cherry-pick https://review.openstack.org/568180 directly ? | 04:11 |
| dmsimard | tristanC: getting late for me so I'll avoid giving a tired opinion :D | 04:12 |
| dmsimard | tristanC: for the time being I stopped nodepool-builder on nb01 (was useless) and the disk cleanup is still running | 04:13 |
| dmsimard | it's deleting very slowly. | 04:13 |
| tristanC | nhicher did the same on sf-project.io nb node too... | 04:13 |
| dmsimard | tristanC: I'm gonna head to bed while the rm is running, I'll send a quick email so folks are aware | 04:17 |
| dmsimard | email sent, I'm going to go and catch some ZzZ's | 04:23 |
| *** jpena|off is now known as jpena | 07:53 | |
| *** ssbarnea_ has joined #softwarefactory | 07:55 | |
| *** ssbarnea_ has quit IRC | 08:06 | |
| *** ssbarnea_ has joined #softwarefactory | 08:42 | |
| gundalow | Mornig all. Could I please get +1 on an update to the vyos image we are using https://softwarefactory-project.io/r/#/c/12185/ Thanks in advance | 10:34 |
| fbo_ | gundalow: morning, Sure that's now merged | 10:49 |
| gundalow | fbo_: Thank you :) | 10:49 |
| sfbender | Merged software-factory/sf-config master: zuul: set gearman ssl certificates https://softwarefactory-project.io/r/11591 | 11:21 |
| *** jpena is now known as jpena|lunch | 11:31 | |
| gundalow | corvus: Hi, when you added https://github.com/ansible-network/zuul-config/pull/18 did you make any other config changed? I've reverted it in https://github.com/ansible-network/zuul-config/pull/18/ though I'm seeing ERROR Unable to find playbook /tmp/e6703510c3c24a31ba111e0634296dec/trusted/project_0/github.com/ansible-network/zuul-config/playbooks/base-test/pre.yaml on https://github.com/ansible-network/ansible-zuul-jobs/pull/13 | 11:50 |
| gundalow | Though I don't see anything related in https://softwarefactory-project.io/r/#/q/status:merged | 11:54 |
| gundalow | ah, still had parent: base-test | 12:13 |
| *** jpena|lunch is now known as jpena | 12:25 | |
| *** dmsimard is now known as dmsimard|off | 12:58 | |
| sfbender | Merged software-factory/sf-config master: Some fixes for the sf-dlrn role https://softwarefactory-project.io/r/12052 | 14:08 |
| sfbender | Fabien Boucher created software-factory/managesf master: Switch mysql connector lib to https://github.com/PyMySQL/PyMySQL/ https://softwarefactory-project.io/r/12187 | 14:35 |
| *** jangutter has joined #softwarefactory | 15:15 | |
| sfbender | Fabien Boucher created software-factory/cauth master: Switch mysql connector lib to https://github.com/PyMySQL/PyMySQL/ https://softwarefactory-project.io/r/12189 | 15:37 |
| *** jpena is now known as jpena|brb | 15:43 | |
| sfbender | Fabien Boucher created software-factory/cauth-distgit master: Support both MySQL-python and python2-PyMySQL for transition https://softwarefactory-project.io/r/12190 | 15:45 |
| sfbender | Fabien Boucher created software-factory/cauth-distgit master: Remove obsolete dependency MySQL-python https://softwarefactory-project.io/r/12191 | 15:50 |
| *** jpena|brb is now known as jpena | 16:24 | |
| *** jpena is now known as jpena|off | 17:19 | |
| *** ssbarnea_ has quit IRC | 18:56 | |
| *** ssbarnea_ has joined #softwarefactory | 18:57 | |
| gundalow | Given success with over the past week, now looking at adding softwarefactory-webhook for ansible/ansible | 19:03 |
| gundalow | 1) How does Zuul handle branch configuration? Is it always going to look at ansible/ansible:devel for config? Or will it use ansible/ansible:stable-2.5 for a PR against stable-2.5? | 19:03 |
| gundalow | 2) Could someone please point me at the configuration (outside of GitHub) that defines the trusted repos, ie which defines Zuul should allow configuration to be loaded from gh/ansible-network/zuul-config | 19:06 |
| gundalow | 3) Where are the docs for jobs.files (where you limit if this job should be run based on file regexp) | 19:08 |
| gundalow | rcarrillocruz: 4) What was your thoughts on adding all the zuul config to ansible/ansible vs ansible/zuul-config | 19:09 |
| gundalow | 5) Does Zuul rebase before running checks, I *assume* so, though I don't see that happening in the job logs | 19:10 |
| dmsimard|off | 1) yea | 19:37 |
| dmsimard|off | 2) https://softwarefactory-project.io/r/gitweb?p=config.git;a=blob;f=zuul/ansible_networking.yaml;h=3f0c58dae394a1ca17fcdc4acb304280b1254b7b;hb=HEAD | 19:38 |
| dmsimard|off | 3) https://docs.openstack.org/infra/zuul/user/config.html#job ? | 19:39 |
| dmsimard|off | 5) zuul tests the patch as it is for the most part afaik.. but there is a merge-check mechanism to check if the patch can be merged | 19:40 |
| dmsimard|off | There's some built-in tooling to gerrit and git-review that helps with rebases, I guess not so much for GitHub | 19:40 |
| dmsimard|off | gundalow: ^ | 19:41 |
| mattclay | dmsimard|off: For #1, is that "yea", it always uses devel, or "yea" it will use the config from the same branch as the PR is made against? | 19:42 |
| mattclay | dmsimard|off: For #5 does that mean we'll need to do our own rebase in the check before running our tests to test against the PR as it would be merged? | 19:45 |
| dmsimard|off | mattclay: zuul will load branch specific config | 19:46 |
| mattclay | dmsimard|off: How does branch specific config work if the repo used for config isn't the same as the one being tested? | 19:47 |
| dmsimard|off | mattclay: not sure I follow | 19:53 |
| mattclay | dmsimard|off: If the Zuul config is in `ansible/zuul-config`, how would we, for example, use a different config for `ansible/ansible:devel` and `ansible/ansible:stable-2.5`? | 19:55 |
| mattclay | dmsimard|off: Also, am I correct in assuming that whatever repo is used for Zuul config, we need Zuul to gate merges to that repo to prevent breaking the Zuul config? | 20:05 |
| dmsimard|off | mattclay: you can selectively "shard" the configuration between different repositories. I think this would be better with an example, hang on. | 20:06 |
| dmsimard|off | For example, OpenStack has zuul-jobs (generic zuul things), openstack-zuul-jobs (generic openstack things) and then project-config (for the trusted execution things). However, the roles, playbooks and configuration from those repositories are available to all the repositories Zuul knows about, regardless of branches. | 20:07 |
| dmsimard|off | A good example I like to point at is the puppet-openstack modules | 20:08 |
| dmsimard|off | So there's a lot of puppet modules and what they do is centralize the bulk of the configuration in one repository, "puppet-openstack-integration" https://github.com/openstack/puppet-openstack-integration/blob/master/.zuul.yaml | 20:09 |
| dmsimard|off | and then all they have to do in the different projects, for example puppet-nova, is to map the jobs to the project https://github.com/openstack/puppet-nova/blob/master/.zuul.yaml | 20:09 |
| mattclay | dmsimard|off: So using your example, the config in the puppet-nova repo is branch specific and the config in all the other repos uses the default branch? | 20:18 |
| dmsimard|off | mattclay: well what I linked you was the master branch config but if you look at another branch, you'll see there's also a zuul.yaml file https://github.com/openstack/puppet-nova/blob/stable/queens/.zuul.yaml | 20:20 |
| dmsimard|off | so you could have totally different jobs running on devel than on stable-* branches, for example | 20:21 |
| dmsimard|off | mattclay: and yes, any repos included in the zuul main configuration should be gated | 20:24 |
| mattclay | dmsimard|off: What delineates "main configuration" from other configuration? How much of the config can be safely not gated? | 20:24 |
| dmsimard|off | mattclay: the main configuration is where the list of projects is defined, i.e https://softwarefactory-project.io/r/gitweb?p=config.git;a=blob;f=zuul/ansible_networking.yaml;h=3f0c58dae394a1ca17fcdc4acb304280b1254b7b;hb=HEAD | 20:25 |
| dmsimard|off | I don't know if there's a better word for it than that, I've just been calling it that | 20:26 |
| mattclay | dmsimard|off: So `ansible-network/zuul-config` itself doesn't need to be gated? | 20:26 |
| dmsimard|off | mattclay: yes, because if someone merges a bad zuul.yaml file in that repo, zuul will attempt to load it. | 20:26 |
| dmsimard|off | mattclay: You can try it now, if you submit a PR with a bogus config in any of the mapped projects, Zuul will warn you about it. If you somehow bypass Zuul to merge the bogus config it'll break things. | 20:27 |
| mattclay | dmsimard|off: What I'm trying to figure out is how much of our config would need to go in `ansible/zuul-config` (gated by Zuul) vs `ansible/ansible` (not gated by Zuul). | 20:28 |
| dmsimard|off | mattclay: That's an excellent question I don't have a good answer for right now. I understand that ansible/ansible is already included in the config and since zuul is (understandably) not gating it, you could potentially merge something bad | 20:30 |
| dmsimard|off | maybe mordred or corvus have opinions | 20:31 |
| mattclay | dmsimard|off: I didn't realize Zuul was already loading config from `ansible/ansible`. I don't think we actually have any Zuul config in there currently. | 20:31 |
| dmsimard|off | mattclay: the fact that ansible/ansible is listed in the config ( https://softwarefactory-project.io/r/gitweb?p=config.git;a=blob;f=zuul/ansible_networking.yaml;h=3f0c58dae394a1ca17fcdc4acb304280b1254b7b;hb=HEAD ) means that Zuul can and will load configuration from there, if there is any | 20:32 |
| dmsimard|off | mattclay: oh wait | 20:33 |
| dmsimard|off | mattclay: there's an explicit config to not include configuration from ansible/ansible | 20:33 |
| mattclay | dmsimard|off: So is the config loading all or nothing? Either Zuul can load any config from the repo or none at all? | 20:34 |
| dmsimard|off | mattclay: there's a few kind of things you can include/exclude, it's not all or nothing .. hang on let me get the docs | 20:36 |
| dmsimard|off | mattclay: https://docs.openstack.org/infra/zuul/admin/tenants.html?highlight=include#attr-tenant.untrusted-projects.%3Cproject%3E.include | 20:37 |
| corvus | mattclay, gundalow, dmsimard|off: regarding #5 -- zuul tests the change as it will land. that's different than testing it as written, or merely rebasing it on the tip. it starts with the current tip of the branch, then merges any dependent changes, then merges the change under test. | 20:40 |
| corvus | so you definitely don't (and shouldn't) do any rebasing, etc, inside the job itself. zuul does it all for you. | 20:40 |
| mattclay | corvus: That is for checks (not just gated merges)? | 20:41 |
| corvus | mattclay: yes, they behave the same way. gate just adds the additional aspect that it includes changes which happen to have been enqueued ahead of the change under test. but for the purposes of thinking about git repos, those are basically just additional "dependent" changes which also get merged into the repo state zuul prepares for the jobs. | 20:42 |
| dmsimard|off | having this discussion makes me realize that I took a lot of what gerrit does (or even the vocabulary) for granted and not trivial to translate to github :/ | 20:43 |
| corvus | a job in check on a github pull-request with no 'depends-on' headers will end up being simply the current branch tip with the pr merged into it. | 20:44 |
| mattclay | dmsimard|off, corvus: So back to the config loading. Is there any config that would be safe to have Zuul load from a non-gated repo? | 20:46 |
| mattclay | And by "safe" I mean that it wouldn't break Zuul. | 20:47 |
| corvus | mattclay: i believe sf is running with a patch (which is not yet upstreamed) so that zuul's configuration won't be "broken", but some of the content from that repo might be missing, which could still mean things are "broken" depending on how you look at it. basically, it constrains how much a single repo can break. if, for example, a repo defined a job which was only used within that repo, maybe | 20:49 |
| corvus | it's okay to load jobs from that repo without zuul gating it because it can only break itself. | 20:49 |
| mattclay | Yeah, if changes to config in ansible/ansible only break CI for ansible/ansible, that's acceptable. What I don't want to have happen is config going into ansible/ansible breaking Zuul for say all of SF. | 20:50 |
| corvus | even with upstream zuul, a tenant can only break themselves (ie, all of the ansible repos would be broken) -- i believe the sf patch would say, let ansible/ansible be broken, but ansible/ansible-networking continue to work. | 20:52 |
| corvus | mattclay: so, if you're willing to live with some amount of risk, and can pay attention to zuul check results on .zuul.yaml changes to ansible/ansible, and be responsive if something does break, then i think including some config in ansible/ansible would be okay. | 20:53 |
| corvus | mattclay: the advantage of doing that is that it may make some of the branch configuration stuff behave in the way it's normally expected to -- so you'd get a better idea of how zuul is designed to work. | 20:54 |
| corvus | mattclay: you can, of course, have the configuration entirely outside the repo, but that requires writing jobs just a little bit differently to deal with multiple branches on the target repo. | 20:55 |
| corvus | to try to make this a bit more concrete, and elaborate on the answer to question #1 -- | 20:56 |
| corvus | zuul has what are called job variants which are used based on the branch of the pull-request being tested. if you define jobs in a repo with multiple branches, you'll get a variant for each branch. for example, you'll end up with a "devel" variant, and a "stable/2.5" variant if the same job appears in the .zuul.yaml file on those branches of ansible. | 20:58 |
| mattclay | corvus: Thanks, that helps a lot. It sounds like we could keep most of the config in ansible/ansible so it would be specific to each branch, without risking breaking anything outside of ansible. | 20:58 |
| corvus | if you wanted to do the same thing in zuul-config instead, you would define the job twice in the same file, and then add "branches: devel" to the first definition, and "branches: stable/2.5" to the second. either way you end up with 2 variants. one approach is more implicit and automatic, the other is more explicit and requires more upkeep. | 20:59 |
| corvus | mattclay: yep | 20:59 |
| corvus | (the real magic of doing it all in-repo comes when it's time to branch "devel" to "stable/2.6" or whatever -- you automatically get stable/2.6 versions of the jobs just by making the git branch) | 21:00 |
| mattclay | Yeah, and that would fit well with our existing workflow. | 21:00 |
| mattclay | corvus: Can we configure Zuul to only watch branches matching certain patterns? | 21:01 |
| corvus | (i should add that if we find ourselves in a situation where we really want the in-repo branch behavior, but we don't want it in ansible/ansible, you can put the job definitions in another repo and branch it at the same time you do ansible/ansible. that's probably more work than we'd want for this situation, but i just wanted to mention the possibility -- we have lots of options) | 21:03 |
| corvus | mattclay: you mean only load zuul config for certain branches, or only run jobs on pull-requests to certain branches? | 21:05 |
| mattclay | corvus: Only running Zuul for PRs on certain branches and/or excluding some branches. Of course we wouldn't need to load config from branches we weren't going to test. | 21:06 |
| corvus | mattclay: yeah, the job branch matchers control that. if a pr doesn't match any of the job's branch variants, that job won't run. if you're doing in-repo config, you usually don't have to worry about that because the variants are created with implicit branch matchers. but if they aren't doing what you want, you can set it explicitly. | 21:09 |
| corvus | https://zuul-ci.org/docs/zuul/user/config.html#attr-job.branches | 21:09 |
| *** ssbarnea_ has quit IRC | 21:58 | |
| *** jruzicka has quit IRC | 22:08 | |
| *** jruzicka has joined #softwarefactory | 22:08 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!