| *** acozine1 has quit IRC | 00:20 | |
| *** gouthamr has joined #zuul | 00:37 | |
| *** odyssey4me has quit IRC | 00:41 | |
| *** odyssey4me has joined #zuul | 00:41 | |
| *** sc68cal_ has joined #zuul | 00:42 | |
| *** rbergero1 has joined #zuul | 00:46 | |
| *** graffatcolmingov has joined #zuul | 00:48 | |
| *** mhu has joined #zuul | 00:48 | |
| *** ssbarnea_ has joined #zuul | 00:49 | |
| *** mhu` has quit IRC | 00:51 | |
| *** sc68cal has quit IRC | 00:51 | |
| *** eventingmonkey has quit IRC | 00:51 | |
| *** sigmavirus24 has quit IRC | 00:51 | |
| *** fbo_ has quit IRC | 00:51 | |
| *** ssbarnea has quit IRC | 00:51 | |
| *** rbergeron has quit IRC | 00:51 | |
| *** lennyb has quit IRC | 00:51 | |
| *** ssbarnea_ is now known as ssbarnea | 00:51 | |
| *** eventingmonkey has joined #zuul | 00:53 | |
| *** fbo_ has joined #zuul | 00:57 | |
| *** lennyb has joined #zuul | 00:58 | |
| *** harlowja has quit IRC | 01:42 | |
| *** JasonCL has quit IRC | 01:47 | |
| *** gouthamr has quit IRC | 02:33 | |
| *** elyezer_ has quit IRC | 02:56 | |
| *** elyezer_ has joined #zuul | 02:57 | |
| tristanC | clarkb: according to https://gitlab.openci.io/openci/community/issues/3 , it seems like websocket is considered to be the protocol to exchange data between ci? | 03:12 |
|---|---|---|
| tristanC | thus we may have to implement a websocket source/reporter driver instead | 03:13 |
| clarkb | I dont think anything ia decided my undertsanding was they were still interested in exploring options | 03:14 |
| clarkb | and had never heard of fedmsg before | 03:15 |
| clarkb | (so were happy to have more input) | 03:15 |
| tristanC | pabelanger: the nice thing with mqtt is that it's already being used for gerrit events, so it makes more sens to me to make zuul publish there directly | 03:17 |
| clarkb | ya thats just an rfc | 03:17 |
| clarkb | so one proposal | 03:17 |
| clarkb | it is interesting that the proposal is to build a new pub sub on top of websockets though rather than using an existing implementation | 03:20 |
| clarkb | If you are interested in that stuff I know fdegir is too and lrobably a good person to talk to | 03:20 |
| tristanC | clarkb: with mqtt, aren't you missing event if you are disconnected? | 03:21 |
| clarkb | tristanC: depends, you an configure the client to ask the server to queue for you iirc | 03:21 |
| clarkb | if the queue is smaller than eventa over your disconnection period you do los messages iirc | 03:22 |
| tristanC | perhaps it would be easier to consume using a feed protocol like jsonfeed or rss | 03:23 |
| clarkb | its too late for me to properly think this through but I'll have to give it a proper read in the morning | 03:25 |
| clarkb | I think the two things that initially stand out to me are that building a new pub sub state machine rather than using an existing protocol seems like more work than necessary. And it seems this protocol expects you to know who your dependents are which is likely not realistic (you can know what you depend on but not who depends on you) | 03:26 |
| tristanC | clarkb: that's my feeling too, though it sounds like a zuul driver could accomodate that protocol if needed | 03:28 |
| fdegir | tristanC: regarding rfc, as clarkb said, it’s a proposal from one of the participants | 03:34 |
| fdegir | tristanC: it seems he’s been thinking about similar stuff for a while and written rfc already | 03:35 |
| *** harlowja has joined #zuul | 03:37 | |
| fdegir | tristanC: so, it would be good if you can share anything you may have been thinking/doing already there for people to see | 03:37 |
| tristanC | fdegir: sure, i'll comment on the issue | 03:40 |
| *** elyezer_ has quit IRC | 04:27 | |
| *** elyezer_ has joined #zuul | 04:36 | |
| *** harlowja has quit IRC | 05:22 | |
| *** haint_ has quit IRC | 06:14 | |
| *** nguyenhai has joined #zuul | 06:14 | |
| *** nguyenhai has quit IRC | 06:32 | |
| *** Wei_Liu1 has joined #zuul | 06:39 | |
| *** Wei_Liu has quit IRC | 06:41 | |
| *** Wei_Liu1 is now known as Wei_Liu | 06:41 | |
| *** nguyenhai has joined #zuul | 06:45 | |
| *** elyezer_ has quit IRC | 06:59 | |
| *** elyezer_ has joined #zuul | 06:59 | |
| *** hashar has joined #zuul | 07:22 | |
| *** jesusaur has quit IRC | 07:23 | |
| *** jesusaur has joined #zuul | 07:29 | |
| *** electrofelix has joined #zuul | 07:41 | |
| *** jpena|off is now known as jpena | 07:42 | |
| tobiash | pabelanger: responded on 535685 | 07:46 |
| *** elyezer_ has quit IRC | 07:59 | |
| *** elyezer_ has joined #zuul | 08:02 | |
| *** elyezer_ has quit IRC | 08:07 | |
| *** elyezer_ has joined #zuul | 08:09 | |
| *** zaro__ has quit IRC | 08:10 | |
| *** zaro__ has joined #zuul | 08:10 | |
| *** logan- has quit IRC | 08:11 | |
| *** cmurphy has quit IRC | 08:11 | |
| *** odyssey4me has quit IRC | 08:11 | |
| *** pbrobinson has quit IRC | 08:11 | |
| *** dvn has quit IRC | 08:11 | |
| *** cmurphy has joined #zuul | 08:13 | |
| *** logan- has joined #zuul | 08:13 | |
| *** odyssey4me has joined #zuul | 08:16 | |
| *** pbrobinson has joined #zuul | 08:16 | |
| *** dvn has joined #zuul | 08:16 | |
| *** dvn has quit IRC | 08:24 | |
| *** persia has quit IRC | 08:26 | |
| *** persia has joined #zuul | 08:28 | |
| *** dvn has joined #zuul | 08:35 | |
| *** hashar has quit IRC | 08:35 | |
| *** JasonCL has joined #zuul | 08:48 | |
| *** JasonCL_ has joined #zuul | 08:53 | |
| *** yolanda_ is now known as yolanda | 08:54 | |
| *** JasonCL has quit IRC | 08:55 | |
| *** elyezer_ has quit IRC | 08:58 | |
| *** sshnaidm|afk is now known as sshnaidm|off | 09:00 | |
| *** JasonCL_ has quit IRC | 09:02 | |
| *** elyezer_ has joined #zuul | 09:03 | |
| *** JasonCL has joined #zuul | 09:07 | |
| *** JasonCL has quit IRC | 09:08 | |
| *** JasonCL has joined #zuul | 09:09 | |
| *** JasonCL has quit IRC | 09:13 | |
| *** JasonCL has joined #zuul | 09:14 | |
| *** JasonCL has quit IRC | 09:25 | |
| *** JasonCL has joined #zuul | 09:29 | |
| *** snapiri has quit IRC | 09:33 | |
| *** AJaeger has quit IRC | 09:38 | |
| openstackgerrit | Matthieu Huin proposed openstack-infra/nodepool master: Add separate modules for management commands https://review.openstack.org/536303 | 09:42 |
| *** JasonCL has quit IRC | 09:56 | |
| *** JasonCL has joined #zuul | 09:57 | |
| *** JasonCL has quit IRC | 09:59 | |
| *** JasonCL has joined #zuul | 10:04 | |
| *** JasonCL has quit IRC | 10:09 | |
| *** elyezer_ has quit IRC | 10:20 | |
| *** elyezer_ has joined #zuul | 10:21 | |
| *** jpena is now known as jpena|lunch | 11:00 | |
| *** JasonCL has joined #zuul | 11:05 | |
| LinuxJedi | mordred, Shrews, corvus: so, the two things that are definitely missing in Zuul that we would need are: Grid Display, this is an output of builds in a grid similar to buildbot (see the grid display output here: http://buildbot.askmonty.org/buildbot/), proper log viewing and a deep search to find things like all of the failures of a certain test. | 11:06 |
| *** xinliang has quit IRC | 11:25 | |
| *** elyezer_ has quit IRC | 11:35 | |
| *** xinliang has joined #zuul | 11:38 | |
| *** xinliang has quit IRC | 11:38 | |
| *** xinliang has joined #zuul | 11:38 | |
| *** elyezer_ has joined #zuul | 11:41 | |
| *** jpena|lunch is now known as jpena | 12:01 | |
| *** JasonCL has quit IRC | 12:06 | |
| *** elyezer_ has quit IRC | 12:27 | |
| *** elyezer_ has joined #zuul | 12:28 | |
| *** odyssey4me has quit IRC | 12:44 | |
| *** odyssey4me has joined #zuul | 12:44 | |
| *** elyezer_ has quit IRC | 12:45 | |
| *** elyezer_ has joined #zuul | 12:47 | |
| *** gouthamr has joined #zuul | 12:49 | |
| *** gouthamr has quit IRC | 12:49 | |
| *** gouthamr has joined #zuul | 12:49 | |
| *** pwhalen has quit IRC | 12:59 | |
| *** pwhalen has joined #zuul | 13:04 | |
| *** pwhalen has joined #zuul | 13:04 | |
| *** dkranz has joined #zuul | 13:04 | |
| *** JasonCL has joined #zuul | 13:40 | |
| *** JasonCL has quit IRC | 13:41 | |
| *** JasonCL has joined #zuul | 13:46 | |
| electrofelix | hughsaunders: did the nodepool-plugin get moved? | 13:50 |
| *** JasonCL has quit IRC | 13:51 | |
| *** elyezer_ has quit IRC | 13:56 | |
| *** JasonCL has joined #zuul | 13:57 | |
| *** elyezer_ has joined #zuul | 14:01 | |
| dmsimard | mordred, corvus: https://review.openstack.org/#/c/556967/ was a pretty breaking change that merged quickly right before the release and it broke SF. We'll work on adding CI on our end (and potentially third party CI on Zuul directly) but I hope we can do better now that v3 is released. | 14:03 |
| dmsimard | I don't know if anyone else is following master but it probably broke them too | 14:04 |
| corvus | dmsimard: we know, that was the intent. we knew that change was breaking which is why we delayed the release for several weeks while we worked on it. we discussed it quite a lot, including with tristan. | 14:06 |
| corvus | dmsimard: we don't intend to make those kinds of breaking changes any more. | 14:06 |
| corvus | dmsimard: if you want to work on ci, please work on adding tests to zuul. there's no reason that needs third-party ci. | 14:07 |
| tristanC | fwiw it didn't "broke SF" as we the change couldn't pass the ci with new api route, it needed some workaround to support both routes until sf zuul package using the tag landed | 14:07 |
| corvus | yeah, there was no reasonable way to roll that out without intervention | 14:10 |
| corvus | we had to hold automatic updates and apply them manually for openstack | 14:10 |
| corvus | dmsimard: fyi, this file already has one test for how sf.io cofigures its web servers: http://git.zuul-ci.org/cgit/zuul/tree/tests/unit/test_web_urls.py | 14:11 |
| corvus | happy to add more :) | 14:11 |
| dmsimard | corvus: I see what you mean by adding tests to Zuul -- but I still see value in knowing that a particular patch appears to be breaking an implementation of Zuul. I guess I could compare that to Nova working by itself vs working through devstack. | 14:12 |
| tristanC | corvus: would be nice to have a real functional test, e.g. testing a base job with secret | 14:13 |
| dmsimard | If BonnyCI was still a thing, I'd be interested in knowing if a patch breaks them | 14:13 |
| dmsimard | Even if it's just for the sake of fostering collaboration between the developers and the consumers/packagers | 14:13 |
| corvus | dmsimard: sure, but that should be the second line of defense -- make that test if we can't model it in the unit tests. | 14:14 |
| corvus | dmsimard: bonnyci is not a thing, so all the work they contributed to zuul's test suite lives on. | 14:14 |
| corvus | tristanC: we can do that in zuul's unit test suite | 14:15 |
| corvus | tristanC: we have quite a few similar tests | 14:15 |
| dmsimard | fair, but SF has to test it's implementation on top of the packaged master anyway -- the overhead of running this same job third party is probably minimal | 14:15 |
| dmsimard | FWIW I'm not telling you these should be voting jobs | 14:15 |
| corvus | tristanC: the thing to keep in mind is that zuul's "unit" test suite is much more like any other program's "functional" test suite | 14:16 |
| corvus | everything it does is as real as possible | 14:16 |
| tristanC | corvus: though it's still using mock environment, while a functional test that install zuul, start the service, maybe even use zuul-jobs and trigger a job would provide valuable feedback imo | 14:17 |
| corvus | tristanC: the only thing that is mocked is gerrit | 14:17 |
| tristanC | and nodepool? | 14:18 |
| corvus | tristanC: and nodepool, for the tests which use nodes (though there's another job that uses a real nodepool) | 14:18 |
| corvus | for example, here's a test that runs about 8 jobs testing various things by running actual ansible playbooks: http://git.zuul-ci.org/cgit/zuul/tree/tests/unit/test_v3.py#n2030 | 14:20 |
| tristanC | oh so maybe it's the zuul-jobs and secrets that could be added to the nodepool-zuul-functional job | 14:21 |
| corvus | tristanC: yeah, we might want to use that job, or a new one, since the main unit tests don't require network access. | 14:23 |
| tristanC | corvus: ftr, here is the sf-ci job that validate zuul is working as expected: https://softwarefactory-project.io/r/gitweb?p=software-factory/sf-ci.git;a=blob;f=health-check/zuul.yaml | 14:24 |
| tristanC | and because config-update are done by zuul too, post job are also validated like so: https://softwarefactory-project.io/r/gitweb?p=software-factory/sf-ci.git;a=blob;f=health-check/playbooks/config_submit_change.yaml | 14:27 |
| dmsimard | corvus: I'm already planning on having a zuul-related integration job in ara's gate .. would I catch errors by installing ara from source (from the patch) and running those tests ? | 14:28 |
| corvus | tristanC: i like that test :) | 14:28 |
| tristanC | corvus: those were the test that detected the issue with the secret refactor that were not working for base job | 14:28 |
| corvus | tristanC: yep, and led to you helping to improve the unit tests. to be clear, i'm not opposed to more testing in the form of third-party ci, but i think it's important that it be auxillary -- any time it catches an error that the unit test suite didn't catch, we should fix the unit test suite if possible. this is a good example :) | 14:31 |
| corvus | tristanC: (that patch hasn't landed yet, but it will) | 14:31 |
| corvus | dmsimard: i think if ara-in-zuul has errors, zuul should ignore them, so the tests may not help as written (we'd need to come up with a way to validate results) | 14:32 |
| corvus | dmsimard: (they would *run* ara though, just not use the output) | 14:33 |
| dmsimard | corvus: I suppose you could say it's more about the ara-report role from zuul-jobs | 14:33 |
| tristanC | corvus: oh yes, i meant to add those kind of test in first-party ci. we actually can't afford to run sf-ci on every zuul change :-) | 14:33 |
| corvus | tristanC: maybe someday :) | 14:33 |
| dmsimard | corvus: What I was planning was to set up a nested zuul (in a multinode job, nodepool would use the second node as a static node) with ARA from source (with the gerrit patch) and then run a fairly regular job.. then check if the report was generated successfully | 14:34 |
| dmsimard | as the new version picks up momentum, it'll become important for me to know when a particular patch breaks something | 14:35 |
| dmsimard | FWIW doing nested Ansible things makes my brain hurt | 14:36 |
| corvus | dmsimard: what's the status of my 3 patches to ara? you asked me to hold for 1.0 6 months ago... | 14:39 |
| dmsimard | corvus: yup, that's sad isn't it | 14:39 |
| dmsimard | it makes me sad | 14:39 |
| corvus | i think they help significantly when using ara with zuul | 14:40 |
| corvus | dmsimard: do you want them on the master branch, on 1.0...? | 14:40 |
| *** electrofelix has quit IRC | 14:42 | |
| dmsimard | corvus: I'll give another look at the patches. Long story short, there was not supposed to be a new release of the stable version but ara 1.0 has turned a bit into a zuul v3 thing. I'm planning a release sometime soon to address some issues I've seen with the middleware and other performance things based on feedback from other users | 14:43 |
| corvus | dmsimard: ok. the patches as they stand do need work; but it'll be nice to know whether/when that work should happen | 14:44 |
| dmsimard | corvus: will do | 14:45 |
| dmsimard | corvus: just rebased your patches so they're at least current, I'll take a look at some point | 14:52 |
| corvus | dmsimard: okay, i'm happy to update them to address comments. let me know when it's safe. :) | 14:57 |
| *** maeca has joined #zuul | 15:26 | |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: Check out more appropriate branches of role and playbook repos https://review.openstack.org/558643 | 15:32 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: Check out more appropriate branches of role and playbook repos https://review.openstack.org/558643 | 15:33 |
| *** openstackgerrit has quit IRC | 15:34 | |
| corvus | clarkb, tobiash, pabelanger, mordred: ^ i think that's ready now. one question i think is worth asking -- is that the way to go? i mean, ansible roles don't usually have parallel release tracks (ie, stable branches) do they? though -- openstack-ansible does... i guess the question is: does supporting multiple branches for roles make sense? should we insist on only using a single branch from role repos? | 15:37 |
| corvus | or is that too prescriptive? | 15:37 |
| *** yolanda_ has joined #zuul | 15:39 | |
| corvus | (i believe we implicitly made the assumption (without realizing we were doing so) that roles repos wouldn't be branched, which is why we ended up with this case being unexamined) | 15:39 |
| corvus | also, i wrote a long release note for that. probably all release notes shouldn't be that long, but it's a complicated issue. if anyone can suggest shorter wording i'm all for it. | 15:40 |
| *** yolanda has quit IRC | 15:41 | |
| mordred | corvus: I think openstack-ansible provides an example of a case where a repo containing more than one role is legitimately branched - so I think supporting multiple branches for roles repos does make sense - also, projects that have roles that exist only in support of their zuul jobs - if the zuul jobs are branched, the roles need to be too ... | 15:52 |
| *** colettecello has quit IRC | 15:53 | |
| *** gothicmindfood has joined #zuul | 15:53 | |
| mordred | corvus: that said, I think for single-role repos (which are more likely to be the form that we find roles in that are intended for more general use such as galaxy publication) the chances of having a branch are less? | 15:53 |
| clarkb | mordred: in osa case youd want roleA on branch A and role B on branch B from the same repo? | 15:54 |
| mordred | clarkb: I don't think so? | 15:57 |
| corvus | tbh, that osa was branched has come as a surprise to me :) | 16:00 |
| corvus | i mean, it shouldn't have, since i've helped with their jobs. i did not think through the implications :) | 16:01 |
| corvus | but yeah, the queens branch of os_nova will install the queens branch of nova | 16:04 |
| corvus | so that's obviously a thing :) | 16:04 |
| *** hashar has joined #zuul | 16:05 | |
| clarkb | ya I think osa woukd work in this system | 16:07 |
| odyssey4me | yep, OSA branches with the same series as openstack as each stable branch focuses on enabling the deployment of that series | 16:09 |
| odyssey4me | however, we're starting to also implement unbranched or differently branches infrastructure roles for non-openstack things | 16:10 |
| corvus | odyssey4me: do you distribute through galaxy at all? | 16:10 |
| odyssey4me | we would like to, but the method to publish from openstack-ci as far as I know if not yet ready | 16:10 |
| odyssey4me | *is | 16:10 |
| rcarrillocruz | i believe tristanC has some role around for publishing to galaxy | 16:10 |
| corvus | odyssey4me: ah, yeah... if it were, how would the branching work? | 16:10 |
| rcarrillocruz | but there are some issues , requireing user and password, not working with orgs or smth like that | 16:11 |
| odyssey4me | heh, yeah - galaxy only really publishes the last tag IIRC | 16:11 |
| corvus | like, does galaxy let you say "install os_nova/queens"? | 16:11 |
| odyssey4me | so that's not something we've totally thought through | 16:11 |
| corvus | okay, so there indeed be dragons there :) | 16:11 |
| odyssey4me | our roles are all versioned in such a way that, for example, 16.x.x is pike, 17.x.x is queens | 16:11 |
| odyssey4me | so if we publish, hopefully we could publish any tag - I'm not sure, however, what galaxy would deliver if we published, say 16.0.6 after 17.0.1 | 16:12 |
| odyssey4me | that said, our interest in publishing at the point is more around our infrastructure roles - where we'd only really be concerned with people using the latest tag | 16:13 |
| rcarrillocruz | so galera and the likes? | 16:14 |
| corvus | there are still some test failures on 558643 -- they look to be cases where the tests are relying on the playbook being inside the workdir to access content | 16:36 |
| corvus | we have a carveout for 'trusted/' i think we just need to add 'untrusted/' to that | 16:37 |
| *** openstackgerrit has joined #zuul | 17:02 | |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: Check out more appropriate branches of role and playbook repos https://review.openstack.org/558643 | 17:02 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: Allow lookup plugins to read from playbook dir https://review.openstack.org/559132 | 17:02 |
| *** jpena is now known as jpena|off | 17:16 | |
| kklimonda | hmm, child jobs can't override variables set in parent (trusted) jobs? | 17:20 |
| *** harlowja has joined #zuul | 17:21 | |
| *** hashar has quit IRC | 17:21 | |
| corvus | kklimonda: they should | 17:21 |
| corvus | kklimonda: (but not 'final' jobs) | 17:22 |
| *** harlowja has quit IRC | 17:25 | |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: Allow some plugins to read from playbook dir https://review.openstack.org/559132 | 17:42 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul master: Check out more appropriate branches of role and playbook repos https://review.openstack.org/558643 | 17:42 |
| SpamapS | One thing about zuul-jobs | 17:55 |
| SpamapS | We were trying to consume a few of them | 17:55 |
| SpamapS | and they assume things about the images you have | 17:55 |
| SpamapS | like tox being installed | 17:55 |
| SpamapS | it would be good to have those assumptions clearly expressed somewhere, or even just the exact diskimage-builder elements to use. | 17:56 |
| corvus | SpamapS: ++ though i thought we had some handling for things like "install tox if it isn't already" | 18:03 |
| corvus | basically, i think we wanted to keep assumptions about images as small as possible. so when we find them, we should either document or fix them as appropriate :) | 18:04 |
| Shrews | that's the ensure-tox role (part of the tox job) http://git.openstack.org/cgit/openstack-infra/zuul-jobs/tree/roles/ensure-tox/tasks/main.yaml | 18:05 |
| corvus | Shrews: yeah that's what i was remembering! | 18:06 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul-jobs master: Add README to ensure-tox role https://review.openstack.org/559142 | 18:07 |
| SpamapS | hm | 18:10 |
| SpamapS | maybe I need to merge more | 18:10 |
| SpamapS | pulled in zuul-jobs about 2 weeks ago | 18:11 |
| SpamapS | need a strategy for tracking it | 18:11 |
| mrhillsman | what is a proper statement for what .zuul.yaml is | 18:12 |
| *** AJaeger has joined #zuul | 18:13 | |
| mrhillsman | "The file used by Zuul to manage your project's jobs" | 18:14 |
| Shrews | per-project job configuration file? | 18:14 |
| mrhillsman | thx | 18:14 |
| Shrews | i'm just throwing out words. corvus likely can come up with something better | 18:15 |
| mrhillsman | i was trying to find it in the docs but thought i would ask here | 18:15 |
| mrhillsman | agreed, i could do the same based on the docs, but figured someone here may have had to provide such a statement before | 18:17 |
| *** harlowja has joined #zuul | 18:29 | |
| *** bhavik1 has joined #zuul | 18:32 | |
| openstackgerrit | Merged openstack-infra/zuul-jobs master: Add README to ensure-tox role https://review.openstack.org/559142 | 18:36 |
| *** bhavik1 has quit IRC | 18:44 | |
| corvus | mordred, tobiash, clarkb, pabelanger: https://review.openstack.org/559132 and https://review.openstack.org/558643 are green and ready for review | 18:54 |
| corvus | i made the necessary path security changes in a separate change to make sure they didn't get lost in the larger change. (but they're also an improvement on their own -- fixing some cases where we would erroneously deny access) | 18:55 |
| corvus | (i think with those, we should always be able to use {{ role_path }} to read files) | 18:56 |
| *** elyezer_ has quit IRC | 18:57 | |
| *** elyezer_ has joined #zuul | 18:58 | |
| *** JasonCL has quit IRC | 19:03 | |
| *** JasonCL has joined #zuul | 19:04 | |
| *** gouthamr has quit IRC | 19:04 | |
| *** JasonCL has quit IRC | 19:07 | |
| mordred | corvus: nice work | 19:23 |
| *** jesusaur has quit IRC | 19:25 | |
| mordred | corvus: first patch looks great - second patch also looks great but is going to take a little longer to read | 19:35 |
| *** jesusaur has joined #zuul | 19:41 | |
| *** JasonCL has joined #zuul | 19:59 | |
| *** JasonCL has quit IRC | 20:00 | |
| *** JasonCL has joined #zuul | 20:01 | |
| *** JasonCL has quit IRC | 20:02 | |
| *** JasonCL has joined #zuul | 20:02 | |
| *** JasonCL has quit IRC | 20:04 | |
| *** JasonCL has joined #zuul | 20:04 | |
| *** JasonCL has quit IRC | 20:11 | |
| *** JasonCL has joined #zuul | 20:13 | |
| *** JasonCL has quit IRC | 20:21 | |
| *** pwhalen_ has joined #zuul | 20:56 | |
| *** pwhalen has quit IRC | 20:57 | |
| *** pwhalen_ is now known as pwhalen | 21:23 | |
| *** pwhalen has joined #zuul | 21:23 | |
| *** JasonCL has joined #zuul | 21:52 | |
| *** JasonCL has quit IRC | 21:53 | |
| clarkb | corvus: I've +2'd the first one but not approved it in case you want tobiash to look over it (I think that may be worthwhile considering his time in this area of the code and its security implications) | 21:58 |
| clarkb | however its a lot more straightforward than I initially thought once I realized that 'file' is an overloaded term in ansible | 21:58 |
| corvus | clarkb: yeah, i agree tobiash should look at it | 21:59 |
| clarkb | corvus: now starting to digest https://review.openstack.org/#/c/558643/ how does ansible know to use a playbook in untrusted/ over trusted/ is that just a path ordering thing? (I'm sure I'll eventually find it as I get through the review but it was somethign that jumped out at me after reading the commit message ) | 22:18 |
| *** maeca has quit IRC | 22:20 | |
| corvus | clarkb: it's preparePlaybook() in executor/server.py | 22:21 |
| corvus | clarkb: we specify the full exact path to the playbook; it's not an ansible search issue | 22:21 |
| clarkb | gotcha | 22:21 |
| corvus | clarkb: (roles, however, have a search path -- but we add either the untrusted or trusted checkouts to that search path as appropriate in prepareZuulRole) | 22:22 |
| *** JasonCL has joined #zuul | 22:35 | |
| *** JasonCL has quit IRC | 22:36 | |
| *** JasonCL has joined #zuul | 22:36 | |
| *** maeca has joined #zuul | 22:40 | |
| *** JasonCL has quit IRC | 22:41 | |
| clarkb | corvus: https://review.openstack.org/#/c/558643/8/tests/fixtures/config/role-branches/git/project1/zuul.yaml line 5, where does parent-job-pre come from? | 22:45 |
| *** threestrands has joined #zuul | 23:02 | |
| *** weshay is now known as weshay_pto | 23:05 | |
| *** JasonCL has joined #zuul | 23:06 | |
| *** JasonCL has quit IRC | 23:09 | |
| *** maeca has joined #zuul | 23:09 | |
| *** pwhalen has quit IRC | 23:10 | |
| *** maeca has quit IRC | 23:10 | |
| *** elyezer_ has quit IRC | 23:11 | |
| pabelanger | tobiash: good points on 535685 | 23:45 |
| clarkb | corvus: I'ev managed to do a first pass on the second change you linked finally | 23:45 |
| clarkb | corvus: mostly still trying to fully wrap my head around it and left some questions. Nothing stnads out as needing to be completely redone or anything like that though | 23:45 |
| *** gouthamr has joined #zuul | 23:51 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!