| *** jamesmcarthur has joined #zuul | 00:15 | |
| *** jamesmcarthur has quit IRC | 00:31 | |
| *** jamesmcarthur has joined #zuul | 00:31 | |
| *** jamesmcarthur has quit IRC | 00:35 | |
| *** rlandy|ruck has quit IRC | 01:11 | |
| *** threestrands has joined #zuul | 01:24 | |
| *** bhavikdbavishi has joined #zuul | 02:08 | |
| *** bhavikdbavishi1 has joined #zuul | 02:14 | |
| *** bhavikdbavishi has quit IRC | 02:14 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 02:14 | |
| *** manjeets_ has joined #zuul | 04:14 | |
| *** manjeets has quit IRC | 04:16 | |
| *** mattw4 has joined #zuul | 05:37 | |
| *** quiquell|off is now known as quiquell|rover | 05:47 | |
| *** pcaruana has joined #zuul | 06:11 | |
| *** mattw4 has quit IRC | 06:18 | |
| *** bhavikdbavishi has quit IRC | 06:40 | |
| *** gtema has joined #zuul | 06:54 | |
| *** yolanda_ has joined #zuul | 07:07 | |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Support fail-fast in project pipelines https://review.openstack.org/652764 | 07:12 |
|---|---|---|
| *** quiquell|rover is now known as quique|rover|brb | 07:33 | |
| *** webknjaz has quit IRC | 08:03 | |
| *** webknjaz has joined #zuul | 08:03 | |
| *** quique|rover|brb is now known as quiquell|rover | 08:05 | |
| *** klindgren has quit IRC | 08:10 | |
| *** klindgren has joined #zuul | 08:10 | |
| *** gtema has quit IRC | 09:03 | |
| *** gtema has joined #zuul | 09:06 | |
| *** hashar has joined #zuul | 09:10 | |
| *** snapiri has joined #zuul | 09:28 | |
| *** threestrands has quit IRC | 09:36 | |
| *** electrofelix has joined #zuul | 09:46 | |
| *** sshnaidm|afk is now known as sshnaidm | 09:56 | |
| openstackgerrit | Markus Hosch proposed openstack-infra/zuul master: Evaluate CODEOWNERS settings during canMerge check https://review.openstack.org/644557 | 09:56 |
| *** strigazi has quit IRC | 10:09 | |
| *** AJaeger has quit IRC | 10:57 | |
| *** AJaeger has joined #zuul | 11:00 | |
| *** panda is now known as panda|lunch | 11:18 | |
| *** gtema has quit IRC | 11:37 | |
| *** rlandy has joined #zuul | 12:20 | |
| *** rlandy is now known as rlandy|ruck | 12:27 | |
| *** pcaruana has quit IRC | 12:30 | |
| *** panda|lunch is now known as panda | 12:32 | |
| *** pcaruana has joined #zuul | 12:53 | |
| *** bhavikdbavishi has joined #zuul | 12:56 | |
| *** bhavikdbavishi has quit IRC | 12:58 | |
| *** bhavikdbavishi has joined #zuul | 13:06 | |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul-jobs master: Add test_setup_reset_connection setting https://review.openstack.org/653130 | 13:27 |
| pabelanger | AJaeger: thanks, copypasta error^ | 13:27 |
| *** bhavikdbavishi1 has joined #zuul | 13:37 | |
| *** bhavikdbavishi has quit IRC | 13:38 | |
| *** bhavikdbavishi1 has quit IRC | 13:41 | |
| Shrews | tobiash: About the nodepool memory usage issue corvus pointed out, are you seeing similar results in your environment? | 13:58 |
| tobiash | looking | 13:59 |
| *** quiquell|rover has quit IRC | 14:00 | |
| *** quiquell has joined #zuul | 14:00 | |
| *** quiquell is now known as quiquell|off | 14:00 | |
| tobiash | I'm seeing something similar starting mid of january in our deployment | 14:02 |
| Shrews | tobiash: does that correlate to using the new launcher cache? | 14:03 |
| pabelanger | Shrews: I looked at sf.io, but didn't see much change | 14:04 |
| tobiash | Shrews: have to check but I think that was earlier | 14:04 |
| tobiash | I see increased memory usage starting begin of december but with also dropping curves | 14:04 |
| tobiash | and since mid of january it looks monotone increasing | 14:05 |
| Shrews | pabelanger: might want to keep an eye on it. *If* it is the cache, likely depends on the the rate of node launching | 14:06 |
| pabelanger | Shrews: yah, I need to get some monitoring going on zuul.a.o too | 14:07 |
| pabelanger | mordred: have any thoughts on https://review.openstack.org/650880/ ? that adds logic to skip zuul_debug_info on python 2.6 hosts | 14:09 |
| mordred | pabelanger: we have hosts that have python2.6??? | 14:11 |
| pabelanger | mordred: I do in ansible-network :( | 14:11 |
| mordred | pabelanger: wow | 14:11 |
| pabelanger | yah, that isn't even on centos6 | 14:11 |
| mordred | I'm fine with it - although in general we obviously can't *actually* support python2.6 - but I don't have a problem with an occasional whack-a-mole when it's easy like that | 14:13 |
| tobiash | Shrews: what's weird is that I had one instance running for a month but it showed the memleak behavior after two weeks | 14:14 |
| tobiash | not sure what causes this yet | 14:15 |
| mordred | pabelanger: remind me - is validate_host exercised speculatively? | 14:15 |
| pabelanger | mordred: no, however I think I linked a test | 14:15 |
| mordred | ok | 14:16 |
| tobiash | but I cannot test this easily right now because we frequently do a rolling restart on config changes (due to the single cloud provider config reload problem) | 14:16 |
| pabelanger | let me check | 14:16 |
| pabelanger | yah: https://logs.zuul.ansible.com/25/25/c6523631f0c8f519999daa70670a99e3caa074b0/check/vyos-test/d603cb4/job-output.html#l268 | 14:16 |
| mordred | pabelanger: yeah - I see it | 14:16 |
| mordred | cool (we really need to finish the base-mimimal work at some point) | 14:16 |
| pabelanger | ++ | 14:17 |
| corvus | mordred, tobiash: regarding https://review.openstack.org/650276 -- there was an original design decision with zuul that we would combine stdout/stderr so that when watching the console stream, you'd see exactly what you would see if you ran a test command locally in a shell. for example, running "tox" locally vs in zuul should produce the exact same output. | 14:24 |
| *** swest has quit IRC | 14:24 | |
| corvus | mordred, tobiash: i agree however, that's not correct from an ansible point of view | 14:24 |
| corvus | mordred, tobiash: so perhaps we should say that we've learned that we would prefer zuul to be better at running ansible at the cost of a slight discrepancy in output sequencing for simple console tasks. | 14:25 |
| tobiash | corvus: that change tries to keep that behavior for log streaming (as much as possible) while fixing the result from ansible perspective | 14:26 |
| corvus | mordred, tobiash: i raise this because i think that's the trade-off -- we're reversing a design decision (which is fine to do), but i think whenever we do that we should do it explicitly. do you think we need any more discussion about it? | 14:26 |
| tobiash | corvus: you mean more discussion in terms of a mailinglist poll? | 14:27 |
| corvus | tobiash: yes, i know -- it's as close as possible, but it won't be quite the same. it's probably close enough that it won't matter -- but when we wrote it originally, we decided not to do it that way so that the interleaving would perfectly match the shell. | 14:27 |
| mordred | corvus: yeah - I think the words you said make sense to me - it does seem like behaving more like ansible vs more like shell in this case is the better way to go with that trade-off | 14:29 |
| corvus | tobiash: perhaps? i honestly don't have an idea of how important it might be to people. or maybe we just point SpamapS at the change and if he says it's okay, we've probably got enough coverage to do it. | 14:29 |
| mordred | corvus: my guess is that most people who aren't zuul cores will likely not notice - and if it IS really important to someone that a particular bit of output have strict shell semantics - they can always run their shell task with 2>&1 as a remediation | 14:30 |
| mordred | corvus: so I think an ack from SpamapS would be sufficient | 14:31 |
| corvus | mordred: that's a good point | 14:31 |
| tobiash | corvus: if you and the folks that are around now are fine with the proposed tradeoff I or swest can send a mail on the list | 14:31 |
| corvus | SpamapS: ^ can you look at scrollback and that change? | 14:31 |
| mordred | corvus: in fact, we already 2>&1 in the devstack job :) | 14:32 |
| corvus | ha | 14:32 |
| mordred | which is really the only job in the system I'd be worried about | 14:33 |
| mordred | since it's SO heavily shell based | 14:33 |
| tobiash | corvus, mordred: what do you think about adding windows support to some roles in zuul-jobs? | 14:35 |
| tobiash | for windows we handle the workspace-sync completely different and I'd like to enhance the git based workspace sync stuff so it works with ssh-enabled windows | 14:36 |
| tobiash | and also add-build-sshkey | 14:36 |
| tobiash | is that something that would be welcomed or shall I just create private windows versions of those roles? | 14:38 |
| pabelanger | my only comment is how best to test | 14:39 |
| mordred | tobiash: I'm not opposed to it - but yeah, I'm also not sure how to ensure we don't break it if there's no testing | 14:39 |
| mordred | so I think it's a question of risk on your side that something could accidentally break the windows support | 14:39 |
| tobiash | good point | 14:40 |
| pabelanger | tobiash: you could do 3pci on the role | 14:40 |
| pabelanger | sf.io is trying to do that | 14:40 |
| pabelanger | but, that is hard to do since trusted context usage | 14:40 |
| *** mattw4 has joined #zuul | 14:41 | |
| tobiash | that would be an option, but I doubt we have the time at the moment to setup a 3pci | 14:42 |
| tobiash | ok, I think I'll fork the roles now and may upload them as a review in case someone is interested | 14:43 |
| tobiash | we still can think about integrating them at a later point | 14:43 |
| pabelanger | tobiash: at some point, I will see ansible.z.c wanting windows, so I can see myself helping with that in the future | 14:43 |
| pabelanger | err, zuul.a.c | 14:44 |
| tobiash | cool | 14:44 |
| tobiash | so you'll be interested in those roles probably | 14:44 |
| pabelanger | yah | 14:44 |
| pabelanger | HA | 14:48 |
| pabelanger | I just figured out why ara still wasn't working on zuul-executor | 14:48 |
| pabelanger | it is now missing in my zuul-executor virtualenv | 14:48 |
| pabelanger | eg: it needs to be installed both in zuul-ansible venv and zuul-executor | 14:49 |
| *** pwhalen has joined #zuul | 14:49 | |
| tobiash | venv because of callback plugin and host because of executable? | 14:50 |
| pabelanger | yah | 14:50 |
| pabelanger | I am testing it out now | 14:50 |
| *** mattw4 has quit IRC | 14:50 | |
| pabelanger | tobiash: http://git.zuul-ci.org/cgit/zuul/tree/zuul/executor/server.py#n40 ara_callbacks will always be none, since zuul-executor venv is now missing ara. I suspect we can rework that to try and load it directly from zuul-ansible venv | 14:56 |
| pabelanger | in fact, I think that has to change, because my bwrap doesn't expose path to zuul-executor virtualenv | 14:56 |
| tobiash | why does zuul need ara? | 14:57 |
| *** weshay is now known as weshay|rover | 14:57 | |
| pabelanger | it doesn,t but we load it by zuul-executor process to see if installed | 14:57 |
| pabelanger | I believe that needs to change | 14:57 |
| tobiash | http://git.zuul-ci.org/cgit/zuul/tree/zuul/executor/server.py#n1753 | 14:57 |
| tobiash | that needs to change | 14:57 |
| tobiash | I think we can add them unconditionally now as ara is part of any ansible venv | 14:57 |
| tobiash | the AnsibleManager could return the ara callbacks dir | 14:58 |
| pabelanger | http://paste.openstack.org/show/749432/ | 14:58 |
| pabelanger | that is my zuul-executor virutalenv | 14:58 |
| pabelanger | and zuul-ansible: http://paste.openstack.org/show/749433/ | 14:59 |
| corvus | it would be great if we could generalize that | 15:00 |
| pabelanger | +1 | 15:01 |
| corvus | zuul isn't supposed to require ara, and ara isn't supposed to be the only callback plugin | 15:01 |
| pabelanger | I'll start working on a patch this afternoon | 15:02 |
| corvus | pabelanger, tobiash: do i understand correctly that currently we are using the system-installed ara callbacks and ignoring the virtualenv ara? | 15:03 |
| tobiash | corvus: yes, seems so | 15:03 |
| pabelanger | yes, it looks like that | 15:03 |
| tobiash | as we install ara anyway into every ansible-venv it would make sense to use the AnsibleManager to get the path | 15:03 |
| corvus | i have mixed feelings about that. on the one hand, that's cool because it easily gives operators control. on the other hand, i can easily imagine a situation where different versions are needed for different venvs. | 15:04 |
| tobiash | that can be individual easily as every venv has its own requirements | 15:05 |
| tobiash | https://opendev.org/openstack-infra/zuul/src/branch/master/zuul/lib/ansible-config.conf | 15:05 |
| tobiash | we can easily move ara from common to specific ansible versions and require different versions if needed | 15:05 |
| tobiash | so if we'd use the ansible-manager to get the ara-path from the venv we'd get automatically the right version if they differ | 15:06 |
| pabelanger | I like that idea, because if if I installed ara into /opt/venv/zuul I _think_ I'd also need to to brwap trusted / untrusted paths in zuul.conf to bwrapped ansible-playbook to access iyt | 15:08 |
| pabelanger | it* | 15:08 |
| pabelanger | s/need to to/ need to add | 15:08 |
| pabelanger | I have to step away for 30mins, something just came up | 15:09 |
| *** hashar has quit IRC | 15:21 | |
| *** hashar has joined #zuul | 15:21 | |
| *** hashar has quit IRC | 15:32 | |
| *** hashar has joined #zuul | 16:00 | |
| pabelanger | sorry, took a little longer then I planned | 16:02 |
| openstackgerrit | Fabien Boucher proposed openstack-infra/zuul master: WIP - Pagure driver - https://pagure.io/pagure/ https://review.openstack.org/604404 | 16:12 |
| *** gtema has joined #zuul | 16:12 | |
| *** manjeets__ has joined #zuul | 16:26 | |
| *** mattw4 has joined #zuul | 16:27 | |
| *** manjeets_ has quit IRC | 16:27 | |
| SpamapS | corvus:ACK, I'll look in a bit. | 16:32 |
| pabelanger | okay, cool, ara-report working again: https://logs.zuul.ansible.com/58/58/10668b99dec43237fed195ae7d4769ab8ec392a4/check/vyos-test/fa70c20/ara-report/ | 16:44 |
| pabelanger | now that I understand the issue, I'll starting work on a patch | 16:44 |
| sshnaidm | I have an issue, one job uses secrets (cloud credentials) in specific zuul system, how can I to inherit from this job in different zuul system while "overriding" these secrets? Now when I try to run inherited job in other zuul system I get error "Unable to use secret cloud_secrets. Secrets must be defined in the same project in which they are used" | 16:49 |
| pabelanger | I guess you could try to create cloud_secrets secret in your downstream zuul, in the project where you are running the job | 16:56 |
| pabelanger | but, I'm unsure if anybody has tried that before | 16:57 |
| clarkb | you may be able to use pass to parent secrets to override the valeus in the upstream repo | 16:59 |
| *** mattw4 has quit IRC | 17:06 | |
| sshnaidm | pabelanger, that's what I did and got this error | 17:11 |
| sshnaidm | clarkb, yeah, but I need just different secrets in "child" job, not sure how it can help | 17:11 |
| *** badboy has joined #zuul | 17:11 | |
| clarkb | sshnaidm: the secret applies to the playbook in the parent job. Pass to parent allows you to define a secret in the child that the parent will use | 17:12 |
| badboy | hi guys | 17:12 |
| badboy | is it possible to handle/process a draft created in the gerrit gui? | 17:12 |
| sshnaidm | clarkb, hmm.. will try now | 17:12 |
| badboy | does zuul support this event? | 17:12 |
| clarkb | badboy: I'm not actually sure. We disable pushing drafts in our gerrit because the feature always confused people (they thought it was properly secret when it wasn't and you'd not be able to see a current patchset if newer patchset is a draft) | 17:13 |
| clarkb | badboy: are drafts a distinct event or does gerrit still send a patchset created event? if it still sends a patchset created event then probably you have to make sure the zuul user in gerrit can see those events | 17:14 |
| badboy | clarkb: I understand and agree with you but I don't have enough muscle to force 2k devs to change their habits | 17:15 |
| *** gtema has quit IRC | 17:16 | |
| badboy | clarkb: my pipeline didn't work with this draft so I guess gerrit emits some other event | 17:16 |
| clarkb | badboy: to start debugging this I would stream events using a user that can see the events for sure (like your own user then you use that user to push the draft) | 17:16 |
| clarkb | then if you see the patchset created event I think the next step is updating acls so that the zuul user can see those events globally | 17:16 |
| badboy | clarkb: roger that | 17:18 |
| sshnaidm | clarkb, is this right config of "pass-to-parent"? http://paste.openstack.org/show/749439/ | 17:23 |
| *** gtema has joined #zuul | 17:26 | |
| *** hashar has quit IRC | 17:27 | |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul master: WIP: Use zuul-ansible for ARA callback plugins https://review.openstack.org/653497 | 17:29 |
| pabelanger | tobiash: corvus: this is my first thought at getting callback info from ara^, however I suspect there is a better way. | 17:30 |
| pabelanger | dmsimard: ^might also be interested | 17:30 |
| clarkb | sshnaidm: ya I think that is right | 17:31 |
| sshnaidm | clarkb, and again the error :( "Unable to use secret cloud_secrets. Secrets must be defined in the same project in which they are used" | 17:32 |
| clarkb | hrm ok so maybe pass to parent doesn't cross project boundaries | 17:32 |
| sshnaidm | yeah, seems like that.. | 17:33 |
| Shrews | "If a secret with pass-to-parent set in a child job has the same name as a secret available to a parent job’s playbook, the secret in the child job will not override the parent" | 17:33 |
| Shrews | from https://zuul-ci.org/docs/zuul/user/config.html#secret | 17:33 |
| pabelanger | you likely need to refactor the parent job without a secret, then in upstream zuul have a child job pass the secret to parent, then your downstream zuul can parent directly to upstream parent | 17:33 |
| pabelanger | but that is just a guess, as I am unsure what the parent jobs does :) | 17:34 |
| dmsimard | pabelanger: you're in python already, is that because it's in a venv ? | 17:38 |
| pabelanger | dmsimard: issue is, we cannot load it directly from zuul-executor, because ara isn't installed into that context. It will only be in zuul-ansible virutalenv | 17:39 |
| *** jangutter has quit IRC | 17:39 | |
| tobiash | pabelanger: this is an interesting approach, suggestion inside | 17:40 |
| pabelanger | tobiash: agree, I think we need to optimize where we call that. maybe on startup like --version check | 17:41 |
| tobiash | pabelanger: the lru cache will handle that quite fine | 17:42 |
| pabelanger | cool | 17:42 |
| pabelanger | will try that out | 17:42 |
| *** manjeets__ is now known as manjeets | 17:53 | |
| *** arxcruz is now known as arxcruz|off|23 | 17:53 | |
| *** gtema has quit IRC | 18:00 | |
| *** electrofelix has quit IRC | 18:00 | |
| *** saneax has joined #zuul | 18:19 | |
| *** rfolco has quit IRC | 18:20 | |
| *** rfolco has joined #zuul | 18:21 | |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul master: Use zuul-ansible for ARA callback plugin detection https://review.openstack.org/653497 | 18:28 |
| pabelanger | tobiash: corvus: dmsimard: feedback most wanted^. that isn't the generic callback method, but think I can build a top of that if humans help guide me in the right direction | 18:28 |
| SpamapS | corvus: mordred regarding stdin/stderr .. Sorry but I have to raise some questions on https://review.openstack.org/650276 ... see comments | 18:32 |
| *** mattw4 has joined #zuul | 18:40 | |
| tobiash | SpamapS: hrm, that was not what I wanted to head, but I have to admit that your point is totally valid, our discussions so far were focused around the buildlog but separating the streams in ansible of course is backwards incompatible | 18:40 |
| tobiash | s/head/hear | 18:40 |
| tobiash | however I still think we should try to transition somehow to split streams as this is the way ansible works and the way of least surprise for users (except the users that rely on the current behavior today) | 18:45 |
| pabelanger | tobiash: I've recently started using stdout_callback = yaml for ansible-playbook, what if we allowed a zuul operator to pick the plugin for streaming? | 18:51 |
| pabelanger | then the user has access to both stdout / stderr on tasks: for example: https://logs.zuul.ansible.com/periodic-1hr/github.com/ansible-network/windmill-config/master/windmill-config-deploy/cf0c37e/job-output.html#l2551 | 18:55 |
| pabelanger | however, that would still present the same issue if we tried to stream shell tasks live | 18:56 |
| *** saneax has quit IRC | 18:58 | |
| corvus | tobiash, SpamapS: i think SpamapS suggestion is workable -- feature flag, flip the default (or, perhaps, eliminate the option) in 4.x | 19:01 |
| tobiash | corvus: makes sense | 19:01 |
| tobiash | I'll talk to swest | 19:01 |
| tobiash | corvus: how would you inject the feature flag to ansible? | 19:02 |
| tobiash | via an env var? | 19:02 |
| tobiash | like ZUUL_ANSIBLE_SPLIT_STREAMS? | 19:03 |
| corvus | tobiash: yeah, i think we do that today? | 19:03 |
| corvus | tobiash: like the zuul_log_id variable? | 19:05 |
| tobiash | I thought the zuul_log_id variable is generated inside ansible by the callback, but maybe I'm wrong | 19:05 |
| tobiash | but we already inject others like ZUUL_JOBDIR | 19:07 |
| tobiash | so that's fine | 19:07 |
| tobiash | thanks | 19:07 |
| corvus | tobiash: we may need both things -- we may need to pass it from zuul to ansible, then from ansible to command plugin | 19:08 |
| tobiash | yeah, that's right | 19:08 |
| Shrews | tobiash: corvus: i have a script running on one of our launchers that records nodepool-launcher memory usage every 30m. Going to watch that to see how that usage grows. | 19:10 |
| Shrews | maybe we can correlate it to some event in the logs | 19:11 |
| tobiash | Shrews: does nodepool log the objects in memory on sigusr2 too like zuul? | 19:11 |
| clarkb | tobiash: I think nodepool only does the thread stacktrace dump to the logs file and starts the yappi profiler if installed | 19:11 |
| clarkb | second sigusr2 will stop the yappi profiler and print its data | 19:11 |
| tobiash | yes, that's what I meant | 19:12 |
| Shrews | clarkb: it does? | 19:12 |
| clarkb | pretty sure it does | 19:13 |
| clarkb | I see the stacktrace dumping but the yappi stuff might not actually exist | 19:13 |
| clarkb | the docs say that yappi should work but it doesn't appear to be in the code | 19:14 |
| Shrews | we should change nodepool to match the docs. :) i can work on adding that | 19:18 |
| tobiash | corvus: re streams, should the feature flag on deployment, tenant or job level? | 19:26 |
| openstackgerrit | David Shrewsbury proposed openstack-infra/nodepool master: Add support for yappi and objgraph output https://review.openstack.org/653541 | 19:30 |
| *** rlandy|ruck is now known as rlandy|afk | 19:46 | |
| openstackgerrit | Fabien Boucher proposed openstack-infra/zuul master: WIP - Pagure driver - https://pagure.io/pagure/ https://review.openstack.org/604404 | 19:55 |
| Shrews | hrm, the yappi output could stand to be a bit wider | 19:59 |
| Shrews | i see no way to control that though | 19:59 |
| SpamapS | MM, TIL about darkreader.org: https://screenshots.firefox.com/EbCNqlCvKGpQVYey/review.openstack.org | 20:03 |
| SpamapS | Makes Gerrit look a lot like Gertty ;) | 20:03 |
| openstackgerrit | David Shrewsbury proposed openstack-infra/nodepool master: Add support for yappi and objgraph output https://review.openstack.org/653541 | 20:15 |
| openstackgerrit | David Shrewsbury proposed openstack-infra/zuul master: Fix for yappi output https://review.openstack.org/653549 | 20:17 |
| SpamapS | You know.. one thing that's kind of a bummer about the Dockerfile zuul has... | 20:32 |
| SpamapS | If you want to take advantage of all the named targets, it rebuilds the entire base up to that target every time you call `docker build --target foo -t foo .` | 20:32 |
| SpamapS | I wonder if we'd be better served by a Dockerfile.builder that can be tagged and referenced once, and then the current multi-target one. | 20:33 |
| clarkb | the builder is what pulls all the deps in right? | 20:33 |
| SpamapS | (this isn't just a speed-of-build thing, they all end up with their own virtual copies of the base) | 20:33 |
| SpamapS | right | 20:33 |
| SpamapS | Or, maybe a different way to say it.. I think there should be a base image that has all of the software in it, and then the targets should use `FROM builder\nFROM that-base-image\nCOPY--from=builder ...` | 20:35 |
| SpamapS | What I currently do is just make the --target zuul-executor ... and then use that for everything, so I only have to have one copy of it everywhere. | 20:36 |
| SpamapS | (customizing CMD in my kubernetes config) | 20:37 |
| clarkb | can you build all of the targets in one go to avoid that? | 20:37 |
| SpamapS | No | 20:37 |
| SpamapS | that's a deficiency in the multi-target build IMO | 20:37 |
| SpamapS | a build has only one image that it can tag at the end | 20:38 |
| corvus | tobiash: i'd say deployment; i'm not thrilled about adding a job-level switch for this | 20:38 |
| SpamapS | All those intermediates just get left as hashes. | 20:38 |
| tobiash | corvus: ++ | 20:39 |
| SpamapS | corvus:the only reason I think job-level is that it lets people make exceptions at a granular level. | 20:39 |
| SpamapS | Since you really have to audit all of your existing command/shell calls with registers to be sure the output isn't being parsed. | 20:39 |
| SpamapS | And then once you do audit a job, how do you make sure it doesn't add somethign like that while you're doing it for the rest of your jobs? | 20:40 |
| SpamapS | So I was thinking the process for users would be to audit, patch, and flip all in one go | 20:40 |
| SpamapS | per job | 20:40 |
| SpamapS | If you have to audit and flip as a site.. well.. if nothing else you need to expose to the job what the current default is so patchers can build in conditional logic. | 20:41 |
| *** pcaruana has quit IRC | 20:43 | |
| corvus | good point. i'm hoping this is a mostly theoretical issue and it's not going to be a big deal for folks, but that is a more conservative approach. | 20:43 |
| SpamapS | Me too | 20:44 |
| SpamapS | another idea, we could actually scan for command tasks that register a variable, and just start warning. | 20:45 |
| *** hashar has joined #zuul | 20:45 | |
| SpamapS | So maybe a first step is make the site-wide flag available, defaulted to current behavior, and offer a tool in the release notes "Run this against all of your roles and playbooks and it will tell you if you can flip the setting." | 20:45 |
| SpamapS | I suspect we have at least a role or two in zuul-jobs that would break. | 20:46 |
| SpamapS | Actually, if we use an environment variable to communicate from zuul -> ansible.. we could also just make that envvar known and provide instructions on how to set it for the problematic tasks. | 20:47 |
| SpamapS | That kind of skips the job-level setting. | 20:47 |
| corvus | i'm not sure that env variable will be accessible or visible to tasks in an ansible playbook, i think it would only be visible to the ansible plugin itself | 20:58 |
| SpamapS | kk, well just throwing these things out there. | 21:05 |
| *** logan- has quit IRC | 21:34 | |
| *** logan- has joined #zuul | 21:38 | |
| *** fdegir has quit IRC | 21:55 | |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul master: WIP: Support Ansible 2.8 https://review.openstack.org/631933 | 22:03 |
| pabelanger | tobiash: ^should fix up our failing tests, but I'm not sure if there is an ansible bug in 2.8 or change in functionality. A failing task in 2.5, 2.6, 2.7 now reports success in 2.8 | 22:03 |
| pabelanger | I'm going to dig more into it and ask in #ansible | 22:04 |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul master: WIP: Support Ansible 2.8 https://review.openstack.org/631933 | 22:06 |
| pabelanger | also bumpted to 2.8.0b1 | 22:08 |
| SpamapS | Interesting... Looking at reducing the zuul-executor image size.. I found this | 22:10 |
| SpamapS | http://paste.openstack.org/show/749455/ | 22:10 |
| SpamapS | Saves 247MB out of 750 .. pretty nice. | 22:10 |
| *** rlandy|afk is now known as rlandy|ruck | 23:03 | |
| *** jamesmcarthur has joined #zuul | 23:07 | |
| *** hashar has quit IRC | 23:16 | |
| *** jamesmcarthur has quit IRC | 23:23 | |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul master: WIP: Support Ansible 2.8 https://review.openstack.org/631933 | 23:44 |
| *** mattw4 has quit IRC | 23:49 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!