| *** rlandy has quit IRC | 00:06 | |
| *** dmellado has joined #zuul | 00:53 | |
| *** bhavikdbavishi has joined #zuul | 03:34 | |
| *** bhavikdbavishi has quit IRC | 03:35 | |
| *** bhavikdbavishi has joined #zuul | 03:35 | |
| *** bjackman has joined #zuul | 03:51 | |
| *** rf0lc0 has joined #zuul | 04:28 | |
| *** rfolco has quit IRC | 04:29 | |
| *** bhavikdbavishi has quit IRC | 04:33 | |
| *** chkumar|out is now known as chandankumar | 04:53 | |
| *** kmalloc has quit IRC | 05:14 | |
| *** bhavikdbavishi has joined #zuul | 05:44 | |
| *** bhavikdbavishi has quit IRC | 06:06 | |
| *** yolanda has joined #zuul | 06:07 | |
| *** mgagne_ has quit IRC | 06:35 | |
| *** mgagne has joined #zuul | 06:39 | |
| *** gouthamr has quit IRC | 06:55 | |
| *** bhavikdbavishi has joined #zuul | 07:01 | |
| *** quiquell|off is now known as quiquell | 07:15 | |
| *** bhavikdbavishi has quit IRC | 07:18 | |
| *** bhavikdbavishi has joined #zuul | 07:22 | |
| openstackgerrit | Merged openstack-infra/zuul-jobs master: Update test-mirror-workspace-git-repos, add test https://review.openstack.org/624575 | 07:26 |
|---|---|---|
| *** bjackman has quit IRC | 07:34 | |
| *** AJaeger has quit IRC | 07:42 | |
| *** AJaeger has joined #zuul | 07:45 | |
| *** quiquell is now known as quiquell|brb | 07:54 | |
| *** themroc has joined #zuul | 08:15 | |
| *** quiquell|brb is now known as quiquell | 08:19 | |
| *** bhavikdbavishi has quit IRC | 08:35 | |
| *** jpena|off is now known as jpena | 08:56 | |
| *** bhavikdbavishi has joined #zuul | 09:08 | |
| *** jesusaur has quit IRC | 09:15 | |
| *** quiquell has quit IRC | 09:21 | |
| *** jesusaur has joined #zuul | 09:22 | |
| *** quiquell has joined #zuul | 09:25 | |
| *** bhavikdbavishi has quit IRC | 09:45 | |
| *** dkehn has quit IRC | 09:57 | |
| *** electrofelix has joined #zuul | 10:12 | |
| *** quiquell has quit IRC | 10:14 | |
| *** quiquell has joined #zuul | 10:15 | |
| *** bjackman has joined #zuul | 10:39 | |
| *** sean-k-mooney has quit IRC | 11:21 | |
| *** EmilienM|off is now known as EmilienM | 11:41 | |
| *** bhavikdbavishi has joined #zuul | 11:52 | |
| *** bhavikdbavishi has quit IRC | 11:56 | |
| *** bhavikdbavishi has joined #zuul | 11:56 | |
| quiquell | tobiash: What about workflowing this ? https://review.openstack.org/#/c/535549/ | 12:02 |
| quiquell | toabctl: is from tristanC | 12:03 |
| quiquell | tobiash: | 12:03 |
| quiquell | tobiash: It's nice to have when you are reporting NODE_FAILURES at your grafana | 12:03 |
| tobiash | I'd like to have corvus a second look on this as he also commented and I'm not quite sure if his thoughts have been addressed | 12:28 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Delay Github fileschanges workaround to pipeline processing https://review.openstack.org/625584 | 12:30 |
| *** jpena is now known as jpena|lunch | 12:35 | |
| evrardjp | hello folks | 12:40 |
| evrardjp | how hard would it be to ignore the 'files' directive of a job when said job is put into a specific pipeline? For example 'periodic' pipeline has no business with the file directive, but I expect jobs could be reused between 'check' and 'periodic' pipelines. | 12:43 |
| *** quiquell is now known as quiquell|brb | 12:45 | |
| *** bjackman has quit IRC | 12:50 | |
| *** dkehn has joined #zuul | 12:52 | |
| evrardjp | I wanted to avoid having two jobs almost the same (one inheriting from the other with only an extra "files" directive seemed overkill) | 12:52 |
| openstackgerrit | Fabien Boucher proposed openstack-infra/zuul master: Pagure driver https://review.openstack.org/604404 | 12:54 |
| *** bjackman has joined #zuul | 12:58 | |
| *** bhavikdbavishi1 has joined #zuul | 12:59 | |
| *** bhavikdbavishi has quit IRC | 13:00 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 13:00 | |
| *** bjackman_ has joined #zuul | 13:01 | |
| *** bjackman has quit IRC | 13:04 | |
| *** bjackman_ has quit IRC | 13:07 | |
| *** bjackman has joined #zuul | 13:08 | |
| *** quiquell|brb is now known as quiquell | 13:14 | |
| *** rlandy has joined #zuul | 13:27 | |
| openstackgerrit | Simon Westphahl proposed openstack-infra/zuul master: Fix skipped job counted as failed https://review.openstack.org/625910 | 13:28 |
| *** sean-k-mooney has joined #zuul | 13:31 | |
| SpamapS | evrardjp: you can assign a new files clause in the pipeline assignment section. | 13:38 |
| SpamapS | evrardjp: https://zuul-ci.org/docs/zuul/user/config.html#attr-project.%3Cpipeline%3E.jobs | 13:41 |
| evrardjp | ok | 13:41 |
| evrardjp | so I should have the files: section in my 'check', 'gate' or 'post' jobs, but not in periodics. Sounds good for reduction of jobs. | 13:42 |
| *** jpena|lunch is now known as jpena | 13:42 | |
| SpamapS | evrardjp: right, basically you'll have a "variant" for each pipeline. | 13:44 |
| evrardjp | I still believe I should have a feature for not taking into account those 'files' in some cases | 13:46 |
| evrardjp | which would be per 'pipeline' | 13:46 |
| evrardjp | ignore_files_stanza: true on periodics make sense to me :) | 13:46 |
| SpamapS | that's basically what you're doing | 13:47 |
| *** bjackman has quit IRC | 13:48 | |
| SpamapS | evrardjp: but I get what you're saying. periodics have no files, so it shouldn't even really apply. | 13:48 |
| *** rf0lc0 is now known as rfolco | 13:48 | |
| evrardjp | yeah exactly :) | 13:48 |
| *** bhavikdbavishi has quit IRC | 13:57 | |
| SpamapS | evrardjp: I think though, that maybe what you want to do is just set `files: []` in the periodics, and then let the other ones pull files from the original job variant? | 14:08 |
| evrardjp | SpamapS: that would be great, I was not sure it would work. | 14:10 |
| evrardjp | I don't have a small environment to test this | 14:11 |
| evrardjp | I thought that or None | 14:11 |
| SpamapS | null might work too. | 14:11 |
| openstackgerrit | Fabien Boucher proposed openstack-infra/zuul master: Pagure driver https://review.openstack.org/604404 | 14:22 |
| SpamapS | corvus: FYI, the scheme actually did not work. The master variant also ran. :-/ | 14:23 |
| SpamapS | And also in prod the secret didn't seem to get set on the playbook. | 14:25 |
| openstackgerrit | Merged openstack-infra/zuul-jobs master: Add a note on testing trusted roles https://review.openstack.org/624578 | 14:26 |
| mordred | fbo: that pagure driver is fun to watch come together ... the issue with webhook token being per-repo is annoying though. seems like they need a 'github app' concept or similar | 14:31 |
| evrardjp | SpamapS: extra bonus question: is the 'post' pipeline also filtered on 'files' like periodic, or would that be more like a gate pipeline? I am curious in the process how things are linked | 14:32 |
| openstackgerrit | Jens Harbott (frickler) proposed openstack-infra/nodepool master: [wip] Add dogpile.cache master to the -src tests https://review.openstack.org/625457 | 14:34 |
| openstackgerrit | Fabien Boucher proposed openstack-infra/zuul master: Pagure driver https://review.openstack.org/604404 | 14:37 |
| tristanC | mordred: did you see https://review.openstack.org/624896, what do you think about that approach? | 14:38 |
| frickler | evrardjp: IIRC the same filtering issue would apply to the post pipeline, yes | 14:38 |
| mordred | tristanC: oh - I didn't - and look at that, what a nice large stack of patches :) | 14:40 |
| mordred | tristanC: neat. so - it's a minor thing - but did you see the work to write a job-output.yaml file? wanted to discuss eventually switching to it from teh json - because we can write it with less RAM pressure (can just append the current info to the file, instead of needing to read the old file in, append to it, and write back out) ... how hard would it be to switch that code to use it instead? (I'm guessing not | 14:43 |
| mordred | hard, js parses yaml pretty well, right?) | 14:43 |
| mordred | tristanC: but I definitely love getting build log information into the build page | 14:44 |
| tristanC | serialization language shouldn't be an issue | 14:45 |
| evrardjp | frickler: just to be extra sure I understand: you meant that post pipeline wouldn't get information from the modified files, and therefore files: would be None, and therefore the "post" job would never run if files: directive is configured on a post job | 14:45 |
| mordred | tristanC: sweet | 14:45 |
| mordred | tristanC: I think the added info is quite nice! | 14:46 |
| SpamapS | evrardjp: for me, post pipeline is definitely filtered on files in my one monorepo. Don't want to push an app that didn't change. | 14:46 |
| tristanC | mordred: if we go that way, we should consider using /build/{id} instead of logurl as job result | 14:46 |
| tristanC | mordred: it seems like we could provide a much better result page, right now it only show the last lines of failed task | 14:47 |
| frickler | evrardjp: SpamapS: o.k., maybe I'm mixing this up with other post-ish pipelines, but I think there can be situations where the original patch becomes a merge commit, and the latter won't show any changed files in gerrit, resulting in your job not being run | 14:48 |
| * SpamapS is so damn confused by branch matchers though | 14:48 | |
| mordred | tristanC: yah - I agree with you. we'd talked some time back about making a view similar to job-output.html but rendered directly on the build page - but with expand/contract sections ... I think having error sections open by default would be a nice approach | 14:48 |
| SpamapS | frickler: merge commits still have the files they changed. | 14:48 |
| tristanC | mordred: exactly, it could show each roles used, and maybe arrange them as "pipelines" item | 14:48 |
| mordred | tristanC: but this seems like a great start - and should allow us to try different ideas for showing the rest of the logs | 14:49 |
| frickler | SpamapS: iirc not in what zuul gets told from gerrit. fungi or corvus might remember more about that, we did some long debugging to find this happening some time ago | 14:50 |
| tristanC | mordred: similarly for the console stream, would it be difficult to make it output structured object so that we can group ansible role output in boxes too? | 14:50 |
| mordred | tristanC: https://www.npmjs.com/package/js-yaml#safeloadall-string--iterator--options- <-- js-yaml supports multi-document files, so that's good | 14:51 |
| SpamapS | frickler: that is annoying. Hm. | 14:51 |
| mordred | tristanC: for the console stream - yes - because it's also available as a plain-text stream | 14:51 |
| fungi | frickler: SpamapS: part of the distinction is that different gerrit events provide different details. ref-updated doesn't provide a "files" list i don't think, while change-merged does | 14:51 |
| SpamapS | I don't use Gerrit | 14:51 |
| SpamapS | so.. | 14:51 |
| SpamapS | push has changes in it. | 14:51 |
| tristanC | if we could somehow have average timing information, then the console stream could also display boxes with progress-bar :) | 14:52 |
| mordred | :) | 14:52 |
| SpamapS | fungi: but what you're saying is, a tag push won't have files info. *that* I would expect. | 14:52 |
| fungi | SpamapS: i'll admit to not having time to digest all the scrollback in here... are you seeing events triggered by push in gh not using a files matcher like you expect? | 14:53 |
| frickler | fungi: it started with evrardjp's question on whether the post queue would be affected by jobs not being run due to a files: filter the same way we noticed earlier for the periodic queue | 14:55 |
| frickler | fungi: so no known issue, more of a what-if question | 14:55 |
| SpamapS | now, does anybody else want to take a swing at answering "How do I have a job run only once, on pushes to only one branch, when it exists in git on two branches?" | 14:56 |
| SpamapS | Because what's happening right now is I get two variants for every post job, one from 'master', and one from my promotion branch, 'prod' | 14:56 |
| SpamapS | Using explicit `branches: foo` on each variant. :-P | 14:57 |
| evrardjp | frickler: that's correctly rephrased, thanks! also , about what-ifs, if you haven't read this, you should: https://what-if.xkcd.com/ | 14:57 |
| *** bhavikdbavishi has joined #zuul | 14:57 | |
| * SpamapS is trying https://zuul-ci.org/docs/zuul/user/config.html#attr-pragma.implied-branch-matchers right now | 14:58 | |
| evrardjp | SpamapS: that's curious, a push on a specific branch should trigger only the matching branch jobs (assuming you have job defined in each branch or using branch matchers)? Or maybe I misunderstood? | 15:00 |
| evrardjp | Is it only for post that the problem appears? | 15:00 |
| mordred | SpamapS: do you get the double-jobs on pushes to master? or only on pushes to prod? | 15:06 |
| SpamapS | mordred: both. | 15:10 |
| SpamapS | I think | 15:10 |
| SpamapS | It's kind of hard to test | 15:10 |
| SpamapS | because .. you know.. prod. | 15:10 |
| SpamapS | I guess I need to create a stage deploy so I can break stuff. | 15:10 |
| *** bjackman has joined #zuul | 15:15 | |
| *** quiquell is now known as quiquell|off | 15:15 | |
| mordred | SpamapS: I'm asking because I'm wondering if somehow gh is emitting 2 events since the branches are closely related *waves arms wildly* - but that was mostly if pushes to prod were triggering master but pushes to master weren't triggering prod | 15:18 |
| SpamapS | mordred: thought about that but no, it's 1 build. | 15:19 |
| SpamapS | That runs *both* variants' playbooks. | 15:19 |
| SpamapS | https://zuul.gdmny.co/build/f8884949320e490685d8e984b3a59412 | 15:19 |
| SpamapS | actually | 15:19 |
| SpamapS | stupid | 15:19 |
| SpamapS | offload | 15:19 |
| mordred | SpamapS: ah - so you're getting one build that is overlaying both | 15:19 |
| SpamapS | you can find that one by going to zuul.gdmny.co and clicking to the build | 15:20 |
| SpamapS | (I have to fix my nginx to make direct links work) | 15:20 |
| SpamapS | mordred: correct | 15:20 |
| mordred | SpamapS: I think i finally fully grok what you're saying | 15:20 |
| SpamapS | I'm going to set up a sandbox project | 15:20 |
| mordred | SpamapS: I was thinking 2 different distinct builds were being triggered in parallel | 15:20 |
| mordred | but the thing your saying is now understood by my brain | 15:21 |
| SpamapS | mordred: zang | 15:21 |
| *** bhavikdbavishi has quit IRC | 15:21 | |
| *** bjackman has quit IRC | 15:23 | |
| * SpamapS almost done making a sandbox to test things in | 15:39 | |
| corvus | SpamapS: do you have a link to the inventory.yaml for the job which behaved wrong? | 15:44 |
| corvus | SpamapS: ok, found it. it looks like you've got the same jobs defined in both master and prod. so there are a total of 4 variants in the system | 15:49 |
| mrhillsman | on the builds page should i be expecting there to be pagination or that is not implemented | 15:49 |
| corvus | mrhillsman: not implemented yet, though i think you can add an argument to the url to get more | 15:50 |
| *** hashar has joined #zuul | 15:50 | |
| mrhillsman | ty sir | 15:50 |
| corvus | mrhillsman: "&limit=100" will get you 100 results. use that carefully :) | 15:51 |
| mrhillsman | hehe ++ | 15:51 |
| corvus | mrhillsman: you can also do "&skip=50" to skip the first 50 -- you can do your own pagination that way | 15:51 |
| corvus | SpamapS: https://zuul.gdmny.co/job/gmapi-post shows all 4 variants | 15:52 |
| mrhillsman | corvus thx | 15:52 |
| SpamapS | corvus: correct. I have no idea why. :-/ | 15:55 |
| corvus | SpamapS: are you merging the branches into each other? | 15:55 |
| SpamapS | corvus: master merges to prod | 15:55 |
| SpamapS | I'm working on making a sandbox that duplicates the problem but that you can all see. It might take a couple hours.. have to do kid-logistics now | 15:56 |
| corvus | SpamapS: i think that's how we've ended up with 4 variants; zuul is loading jobs from both branches | 15:56 |
| corvus | SpamapS: i'm going to dig around for another solution | 15:57 |
| SpamapS | corvus: yes! but it seems like the right thing to do would be to teach zuul how to tell that those are actually only 2 variants. :-P | 15:57 |
| SpamapS | anyway... -> bbl | 15:57 |
| corvus | SpamapS: okay, i think there are two alternatives you can do now, and something we could add to zuul to improve this in the future. | 16:08 |
| corvus | SpamapS: alternative 1) move the job config out of that repo and into another (unbranched) repo; it should work more-or-less as currently written. 2) go back to having two separate jobs (gmapi-post-dev, gmapi-post-prod) which are basically duplicative (we can't share the job definition in this alternative). don't put branch matchers on them at all -- instead, let the implied branch matchers get attached. | 16:12 |
| corvus | then in the pipeline config, add explicit branch matches to them. the pipeline config will ensure only the -prod job runs on the prod branch, and, even though there are 2 prod jobs defined, only one of them has the implied branch matcher for prod. | 16:12 |
| corvus | SpamapS: the thing we could do in the future is add branch inclusion/exclusion to the tenant config, so you could say "GoodMoney/tech: include-branches: [prod]" in main.yaml; then we would ignore configuration from the master branch. that has some downsides though, in that it would be hard for you to dynamically test config. | 16:14 |
| corvus | SpamapS: i think option 2 is the way to go. | 16:14 |
| corvus | tristanC: regarding https://review.openstack.org/535549 i think my suggestion at least deserves a response. would it help for me to -1 things whenever i have a question? (cc: jhesketh, tobiash) | 16:34 |
| corvus | tristanC: if you could also reply to jhesketh's question, that would be great. | 16:41 |
| *** themroc has quit IRC | 17:01 | |
| evrardjp | am I the only one with that interest in disabling file matchers for periodics? | 17:07 |
| evrardjp | maybe I am doing it wrong then | 17:07 |
| *** chandankumar is now known as chkumar|out | 17:13 | |
| SpamapS | corvus: Yeah, I don't love any of those. What I wonder is if we can just teach Zuul to not make variants across branches. | 17:15 |
| corvus | evrardjp: i thought your issue was resolved earlier? don't put files on the jobs. only put them on the pipelines where you want them. | 17:16 |
| SpamapS | corvus: like, could we make the `branches:` be "load a variant only from this branch" rather than "run on this branch" ? | 17:16 |
| evrardjp | corvus: that's the simplest fix/workaround. Now I am really believing there must be a better way / more meaningful | 17:17 |
| SpamapS | Which is basically the same as doing it in the tenant config, but gives more granularity. | 17:18 |
| corvus | SpamapS: i think that would be confusing, as it's very different from what branches means elsewhere | 17:18 |
| evrardjp | there are many ways to skin that cat: having different jobs (so different job inheritance), having unnamed "variants" directly defined in pipeline | 17:18 |
| evrardjp | sorry I intercepted that conversation -- we can discuss that later -- I thought it could be a good feature addition | 17:18 |
| SpamapS | corvus: maybe a different field. `config-branches:` ? | 17:19 |
| clarkb | evrardjp: corvus One approach might be to have pipelines intelligently ignore criteria that they can't act on? | 17:19 |
| evrardjp | clarkb: exactly | 17:19 |
| corvus | evrardjp: well, i think the suggested solution is nice -- it's very explicit and obvious. you're saying "when running this job on this pipeline, use these files. when running it on this other pipeline, don't". | 17:20 |
| evrardjp | or maybe not intelligently, but at least trigger that behaviour | 17:20 |
| corvus | clarkb, evrardjp: and when post grows the ability to match on files? | 17:20 |
| SpamapS | corvus: anyway, while we think about a less confusing way to configure... I'm still a bit puzzled what the use case is for running *both* variants in one build. | 17:20 |
| corvus | clarkb, evrardjp: (as it currently does on github) | 17:20 |
| SpamapS | I would have expected that we'd run the first one, or the last one, not both. | 17:20 |
| evrardjp | corvus: that kinda is the same meaning: when running on periodic pipeline, ignore file matchers. | 17:20 |
| evrardjp | as they are not relevant anyway -- but I understand it would mean carrying some code | 17:21 |
| evrardjp | for something that could be code less | 17:21 |
| evrardjp | I am just on the fence whether this is something we should do or not :p | 17:22 |
| corvus | evrardjp: i think you should give the suggested solution a good try first :) | 17:22 |
| evrardjp | also I am currently testing to have files: [] in pipeline to basically have a no-code version of that impact | 17:22 |
| evrardjp | corvus: I did, then reviewers said "that becomes very unreadable very quick" | 17:23 |
| clarkb | SpamapS: corvus: (and maybe this was suggested already) but couldn't you define all of the jobs for post on the merge destination side. The merge source would then merge into the dest somewhat cleanly and you'd have a single copy of the jobs | 17:23 |
| evrardjp | corvus: I don't intend to be the only one maintaining those jobs for that project:p | 17:23 |
| SpamapS | clarkb: prod isn't meant to *ever* differ from master. | 17:24 |
| corvus | clarkb, SpamapS: oh, yeah that might work -- but as long as you never merge prod back into master | 17:24 |
| SpamapS | It's a promotion workflow. I'd rather not carry changes in prod. | 17:24 |
| corvus | ok | 17:24 |
| SpamapS | I can if that's the only way | 17:24 |
| SpamapS | But the idea was to make it a delayed release branch. | 17:24 |
| SpamapS | I'm thinking more and more that tags might be better though. | 17:24 |
| corvus | evrardjp: is the change somewhere i can see it? | 17:25 |
| SpamapS | A big win on tags is that there's a clear link between the push to master and the tag by SHA, so I can very easily reuse the bits that were built on push. | 17:25 |
| evrardjp | corvus: yeah I will link you to different implementations, so you can see what it "looks like" | 17:26 |
| SpamapS | But the loss is that if I do need to hotfix production I have to land fixes in master. | 17:26 |
| SpamapS | I suppose if I'm willing to hotfix prod, I should be willing to carry a permanent change which is the deploy job config. Hm. | 17:27 |
| * SpamapS is feeling that the "just put it in a separate repo" path is the simplest one for now. | 17:27 | |
| clarkb | if master and prod branches can't/shouldn't differ then having a config repo independent of that set of rules may be a good model for it (corvus did suggest this earlier if I've read it correctly) | 17:27 |
| evrardjp | corvus: method 1) changing inheritance and creating a "check" job: https://review.openstack.org/#/c/625914/1/zuul.d/libvirt.yaml | 17:27 |
| AJaeger | evrardjp: show us your proposed change... | 17:28 |
| SpamapS | yeah and honestly, I've been thinking about puttin the prod stuff in an entirely different tenant. | 17:28 |
| evrardjp | method 2) variants in pipeline: https://review.openstack.org/#/c/625914/4/zuul.d/libvirt.yaml | 17:28 |
| AJaeger | evrardjp: sorry, should have read to end before asking... | 17:28 |
| evrardjp | method 3) variant in pipeline to disable matcher: https://review.openstack.org/#/c/625914/5/zuul.d/libvirt.yaml | 17:28 |
| AJaeger | evrardjp: you could use yaml anchors to have the list only once | 17:29 |
| evrardjp | AJaeger: that's fair :) | 17:29 |
| AJaeger | evrardjp: http://git.openstack.org/cgit/openstack/nova/tree/.zuul.yaml#n14 | 17:29 |
| evrardjp | my question is not really about how to write the job, but whether a variant of 3 (but automatic) would be an interesting feature or not. | 17:30 |
| evrardjp | AJaeger: yes I should totally use Anchors for method 2. | 17:31 |
| corvus | SpamapS: there's a third alternative that may work now: define a single job (gmapi-post) identical in both branches. in the project-pipeline, list the job twice, one with a branch matcher for each branch, and then customize the job for dev/prod there. | 17:31 |
| corvus | SpamapS: that gets you "one" definition of the job with minimal delta for the customization. | 17:31 |
| corvus | SpamapS: the only gotcha for that approach is that if the project-pipeline definition appears in both branches, both will be applied. if you're only setting variables and the run playbook, that's fine, they'll be overridden. but pre/post playbooks will be appended. and it's tricky to change variable values, since as long as the branches diverge, the last one is going to win. | 17:33 |
| corvus | SpamapS: so all things considered, i think alternative #1 or #2 from earlier are better, even if they're still not ideal. | 17:33 |
| corvus | SpamapS: however, if you put that project-pipeline definition outside of the repo (ie, in a config-project) it would resolve those issues (at the cost of making it a little harder to change the config) | 17:35 |
| SpamapS | corvus: another alternative.. delete the file from the prod branch? | 17:37 |
| SpamapS | It's sort of like carrying changes, but.. it's just a blanket "this file doesn't live in this branch ever" and an delta I'm willing to carry. | 17:37 |
| corvus | SpamapS: that would work | 17:38 |
| SpamapS | Yeah I think that's the simple solution for today. | 17:39 |
| SpamapS | Then I need to start thinking about whether tagging master is a reasonable way to release vs. merge ot prod. | 17:39 |
| corvus | SpamapS: that's functionally similar to the tenant include-branches idea, so if you like that, we can build that into zuul | 17:39 |
| SpamapS | Yeah lets see how it goes. | 17:40 |
| *** gouthamr_ has joined #zuul | 17:54 | |
| openstackgerrit | Jens Harbott (frickler) proposed openstack-infra/nodepool master: [wip] Add dogpile.cache master to the -src tests https://review.openstack.org/625457 | 18:11 |
| *** hashar has quit IRC | 18:32 | |
| dmsimard | An odd side effect of parenting "nodejs-npm" to "unittests" is that we end up attempting to recover subunit/stestr files | 18:35 |
| clarkb | dmsimard: subunit isn't python specific https://bazaar.launchpad.net/~subunit/subunit/master/files someone could add support for the protocol to js | 18:36 |
| clarkb | (I don't know that anyone has) | 18:36 |
| dmsimard | yeah, we're probably not using it :p | 18:43 |
| dmsimard | Stumbled on it when troubleshooting some arcane npm shrinkwrap issue | 18:43 |
| dmsimard | trying to see if I can leverage the same jobs as zuul for testing the new ara web ui | 18:44 |
| *** jpena is now known as jpena|off | 18:44 | |
| mordred | clarkb, dmsimard: I believe there is already js support that's in use somewhere | 18:45 |
| mordred | but I don't remember where | 18:45 |
| clarkb | https://www.npmjs.com/package/subunit-js stackviz maybe based on the name there | 18:46 |
| dmsimard | mordred: would you happen to know why I get that shrinkwrap issue in CI but not on my laptop ? http://logs.openstack.org/66/625666/4/check/ara-build-dashboard/9b1267a/ara-report/result/61cf5f72-b2c6-4860-a78d-104a8ab695ba/ | 18:46 |
| mordred | dmsimard: looking | 18:46 |
| dmsimard | my googlefu has thus far failed me | 18:47 |
| mordred | clarkb: yah - I think that's right - stackviz | 18:47 |
| *** rlandy is now known as rlandy|biab | 18:47 | |
| mordred | dmsimard: that job is using node v6 - are you using node v6 locally? | 18:48 |
| mordred | I think you might want at least v8 | 18:48 |
| dmsimard | ohhhhh | 18:48 |
| mordred | dmsimard: node_version: 8 | 18:48 |
| mordred | in your job vars | 18:48 |
| dmsimard | node --version is indeed returning v8 on my laptop | 18:48 |
| mordred | I'd start with that | 18:48 |
| dmsimard | it's 6 by default right | 18:49 |
| mordred | might just be a difference in resolver stuff | 18:49 |
| mordred | yeah | 18:49 |
| dmsimard | thanks I'll try that :D | 18:49 |
| *** hashar has joined #zuul | 18:50 | |
| mnaser | zuul related question -- can nodesets also be nested in configs | 18:50 |
| clarkb | mnaser: one nodeset including another nodeset? I don't think so | 18:51 |
| dmsimard | mnaser: nested how | 18:51 |
| mnaser | hmm, override is the word i was looking for. for example, nodesets for multinode devstack have certain groups defined | 18:52 |
| mnaser | say i want to reuse the nodeset with all group configs, but just changing the nodes: section | 18:52 |
| mnaser | say an example would be to define this abstract nodeset without nodes for 2 node deploys, then have 2.. 1 for bionic and 1 for xenial for exmaple | 18:53 |
| Shrews | mnaser: you can override nodesets | 18:53 |
| pabelanger | no, you need a new nodeset | 18:53 |
| dmsimard | I think I would redefine the nodeset | 18:54 |
| pabelanger | can't really tempalte nodesets today | 18:54 |
| mnaser | bah okay, ill carry all the copy pasted stuff then | 18:54 |
| mnaser | :< | 18:54 |
| dmsimard | mnaser: you just need to redefine it once ? | 18:54 |
| pabelanger | yah, it would be nice to parent a nodeset, like we can with job vars. But not sure how that would be expressed | 18:55 |
| mnaser | dmsimard: https://review.openstack.org/#/c/625448/13/.zuul.yaml kinda wanna avoid the magnum-two-node-xenial there | 18:57 |
| pabelanger | mnaser: you'd be able to use yaml anchor, but that would also have to live in the same file | 18:58 |
| mnaser | pabelanger: yeah, i'd have to bring that up to devstack repo then i guess | 18:59 |
| dmsimard | mordred: that fixed it \o/ now I just fixed javascript_content_dir and hopefully that should do it | 19:05 |
| mordred | \o/ | 19:05 |
| *** rlandy|biab is now known as rlandy | 19:40 | |
| *** manjeets has quit IRC | 19:55 | |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: WIP: Add cgroup support to ram sensor https://review.openstack.org/549506 | 20:21 |
| *** rlandy is now known as rlandy|brb | 20:30 | |
| openstackgerrit | Ian Wienand proposed openstack-infra/zuul-jobs master: [dnm] testing against base-test https://review.openstack.org/626002 | 20:35 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Add cgroup support to ram sensor https://review.openstack.org/549506 | 20:40 |
| *** rlandy|brb is now known as rlandy | 20:48 | |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Add cgroup support to ram sensor https://review.openstack.org/549506 | 21:26 |
| *** manjeets has joined #zuul | 21:48 | |
| corvus | mordred, tobiash: can you take a look at https://review.openstack.org/570668 when you have a moment | 22:04 |
| tobiash | looking | 22:05 |
| corvus | clarkb: ^ also that's a re-review for you | 22:05 |
| mordred | corvus: oh - this is the piece that was missing right? | 22:06 |
| corvus | mordred: yep | 22:07 |
| mordred | corvus: lgtm - but I'm gonna hold off to let other people look too if they want | 22:10 |
| tobiash | lgtm | 22:13 |
| tobiash | corvus: what do you think about creating a gear release this week? This would enable us to use the client keepalive in zuul. | 22:16 |
| corvus | tobiash: i'm starting to think may we should avoid releases until next year | 22:17 |
| corvus | s/may/maybe | 22:17 |
| tobiash | early next year would be fine for me too | 22:17 |
| clarkb | if we ca get the ipv6 friendlyness change into gear pre release that would be good too | 22:21 |
| clarkb | I'll review that change shortly | 22:21 |
| *** manjeets has quit IRC | 22:30 | |
| clarkb | the one thing I notice on https://review.openstack.org/#/c/570668/14/zuul/executor/server.py is data comes from node['connection_port'] are we really stuffing all that info about namespaces and user info and all that under connection_port? I guess this allows us to not need to redefine the node dict in nodepool? | 22:39 |
| *** dkehn has quit IRC | 22:40 | |
| *** dkehn has joined #zuul | 22:41 | |
| *** manjeets has joined #zuul | 22:45 | |
| corvus | tristanC, Shrews: ^ maybe we can expand that out? we shouldn't need to override fields like that. | 22:45 |
| clarkb | even calling it connections_details then having port for ssh and namespace etc for k8s might be clearer | 22:46 |
| corvus | wfm | 22:47 |
| clarkb | then for backward compat check if connection_port is set, if so treat it as just a port else look for _details | 22:47 |
| *** hashar has quit IRC | 22:56 | |
| openstackgerrit | Clark Boylan proposed openstack-infra/nodepool master: Run devstack zookeeper on tmpfs https://review.openstack.org/626038 | 23:21 |
| *** j^2 has joined #zuul | 23:36 | |
| openstackgerrit | Clark Boylan proposed openstack-infra/nodepool master: Trim devstack services used in testing https://review.openstack.org/626044 | 23:41 |
| SpamapS | hm | 23:43 |
| SpamapS | I'm confused about how role loading works | 23:43 |
| SpamapS | Oh, no.. ok I see what's oging on | 23:44 |
| SpamapS | going | 23:44 |
| *** yolanda has quit IRC | 23:55 | |
| SpamapS | corvus: Ugh, so deleting the file with the jobs in it from the prod branch has created a "conflicts any time we change the jobs" situation. :-/ | 23:56 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!