| *** jamielennox|away is now known as jamielennox | 00:02 | |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul feature/zuulv3: sql-connection: make _setup_tables staticmethod https://review.openstack.org/466455 | 01:02 |
|---|---|---|
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul feature/zuulv3: [RFC] Zuul Dashboard https://review.openstack.org/466561 | 01:02 |
| tristanC | Hello folks, is the meeting tomorrow (monday 2200UTC) still planned? | 01:14 |
| tristanC | Would you mind if I add to the agenda a couple of requests for comments, namely static node support and a jobs dashboard ? | 01:15 |
| clarkb | yes I beliece only last week's meeting was cancelled | 01:16 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Re-enable F405 pep8 errors https://review.openstack.org/466285 | 01:36 |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul feature/zuulv3: Zuul Dashboard https://review.openstack.org/466561 | 01:48 |
| *** jamielennox is now known as jamielennox|away | 02:00 | |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul feature/zuulv3: RFC: Zuul Dashboard https://review.openstack.org/466561 | 02:01 |
| *** adam_g has quit IRC | 02:24 | |
| *** adam_g has joined #zuul | 02:25 | |
| *** adam_g has quit IRC | 02:32 | |
| *** adam_g has joined #zuul | 02:35 | |
| *** jhesketh_ is now known as jhesketh | 03:08 | |
| *** adam_g has quit IRC | 03:24 | |
| *** adam_g has joined #zuul | 03:24 | |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul master: launcher: ensure builder scripts are removed https://review.openstack.org/464519 | 03:46 |
| *** Cibo_ has joined #zuul | 03:53 | |
| *** jamielennox|away is now known as jamielennox | 03:53 | |
| *** adam_g has quit IRC | 04:30 | |
| *** adam_g has joined #zuul | 04:32 | |
| *** isaacb has joined #zuul | 04:59 | |
| *** isaacb has quit IRC | 05:41 | |
| *** isaacb has joined #zuul | 06:33 | |
| *** isaacb has quit IRC | 06:33 | |
| *** adam_g has quit IRC | 06:42 | |
| *** adam_g has joined #zuul | 06:43 | |
| *** DangerousDaren has joined #zuul | 06:56 | |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul master: launcher: add Jenkins credentials-binding support https://review.openstack.org/466611 | 07:07 |
| *** Cibo_ has quit IRC | 07:55 | |
| *** Cibo_ has joined #zuul | 08:36 | |
| *** adam_g has quit IRC | 08:54 | |
| *** adam_g has joined #zuul | 08:55 | |
| *** Cibo_ has quit IRC | 09:48 | |
| *** adam_g has quit IRC | 09:54 | |
| *** adam_g has joined #zuul | 09:55 | |
| *** adam_g has quit IRC | 10:09 | |
| *** adam_g has joined #zuul | 10:10 | |
| *** hashar has joined #zuul | 10:16 | |
| *** adam_g has quit IRC | 10:19 | |
| *** adam_g has joined #zuul | 10:23 | |
| *** jkilpatr has quit IRC | 10:31 | |
| *** adam_g has quit IRC | 10:32 | |
| *** adam_g has joined #zuul | 10:35 | |
| *** hashar has quit IRC | 10:44 | |
| *** adam_g has quit IRC | 10:48 | |
| *** adam_g has joined #zuul | 10:49 | |
| *** jkilpatr has joined #zuul | 10:57 | |
| *** lennyb_ has quit IRC | 11:24 | |
| *** lennyb has quit IRC | 11:24 | |
| *** lennyb has joined #zuul | 11:28 | |
| *** lennyb_ has joined #zuul | 11:29 | |
| *** lennyb has quit IRC | 11:29 | |
| *** lennyb_ has quit IRC | 11:29 | |
| *** lennyb has joined #zuul | 11:30 | |
| Shrews | FYI, test_multi_driver.TestGerritAndGithub appears to be flapping: http://logs.openstack.org/86/466286/1/gate/gate-zuul-python35/7ffcf01/testr_results.html.gz | 11:33 |
| Shrews | jlk? ^^^ | 11:33 |
| Shrews | err, test_multiple_project_gerrit_and_github, rather | 11:34 |
| mordred | tristanC: I left some comments on the dashboard patch - overall I think the idea is a great one, so I hope they come across that way | 11:35 |
| tristanC | mordred: that's much appreciated! Thank you for such fast comments :-) | 11:43 |
| Shrews | tristanC: your nodepool YAML logging change duplicates work from jamielennox (https://review.openstack.org/445656). Not sure why he hasn't picked that up, but could you two work together on that? | 11:45 |
| tristanC | Shrews: oops, I forgot to look at open reviews, let me abandon my duplicate | 11:47 |
| mordred | tristanC: if you feel like it, you could probably rebase jamie's to nudge that along | 11:52 |
| tristanC | sure, I guess he wouldn't mind | 11:54 |
| tobiash | hi | 11:54 |
| tobiash | regarding the python3 work on zuul, nice :) | 11:54 |
| tobiash | but what I'm asking myself is how does that work together with ansible? | 11:54 |
| tobiash | is ansible already working with that? | 11:55 |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Allow loading logging config from yaml https://review.openstack.org/445656 | 11:56 |
| Shrews | tobiash: ansible should mostly work with py3 (mostly module dependent, i think). https://docs.ansible.com/ansible/python_3_support.html | 11:56 |
| tobiash | I get an error when trying to install zuul into a py3 only alpine container: http://paste.openstack.org/show/610164/ | 11:56 |
| tristanC | isn't ansible executed through subprocess? | 11:57 |
| Shrews | i don't think we've done actual real life usage in a py3 environment yet, though | 11:57 |
| tobiash | tristanC: yes, but zuul injects some modules to catch e.g. local actions for untrusted jobs | 11:58 |
| mordred | also - running zuul in python3 doesn't mean that the remote ansible execution will be python3 | 12:03 |
| mordred | tobiash: oh - fun. that definitely looks like a ton of fun | 12:04 |
| mordred | (that paste) | 12:04 |
| tobiash | mordred: RUN cd /opt/zuul-source && . /opt/zuul/bin/activate && python3 setup.py install | 12:04 |
| tobiash | that seems to work... | 12:04 |
| tobiash | :) | 12:04 |
| mordred | tobiash: WEIRD | 12:05 |
| openstackgerrit | dongwenjuan proposed openstack-infra/nodepool master: 'print' is a function in python3 https://review.openstack.org/466706 | 12:06 |
| * mordred just -2'd that ^^ btw | 12:14 | |
| Shrews | mordred: good response. thx | 12:18 |
| tobiash | first try to run a py3 scheduler: http://paste.openstack.org/show/610166/ | 12:32 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Read all Gerrit events from poll interruption https://review.openstack.org/466453 | 12:36 |
| Shrews | pabelanger: looks like we have a problem with chocolate on nl01: http://paste.openstack.org/show/610167/ | 12:36 |
| Shrews | i wonder if production is seeing the same error | 12:38 |
| Shrews | yup | 12:39 |
| tobiash | mordred: regarding py3, _ssh in gerritconnection returns bytes in py3 which breaks all comparisons :( | 12:40 |
| tobiash | easy fix would be to decode stdout and stderr to utf8 in the _ssh method | 12:41 |
| tobiash | would you agree? | 12:41 |
| tobiash | with that the scheduler at least starts up and receives events now correctly :) | 12:42 |
| mordred | tobiash: yah -that seems reasonable to me - Shrews ? (I think you're beating us to actually trying to _run_ in py3 - so thanks! :) ) | 12:48 |
| tobiash | :) | 12:49 |
| tobiash | scheduler seems to trigger also jobs already | 12:49 |
| tobiash | but behaves a bit weird | 12:49 |
| tobiash | check voted with Verified=1 and Verified=-2 at the same time... | 12:49 |
| tobiash | /s/Verified=-2/Verified=-1/ | 12:50 |
| tobiash | Patch Set 12: Verified+1 Verified-1 | 12:50 |
| tobiash | Build succeeded. | 12:50 |
| mordred | tobiash: hrm. that does seem ... not quite correct | 12:53 |
| tobiash | mordred: looks like the user name is encoded differently | 12:53 |
| tobiash | the py3 zuul couldn't remove the py2 zuul's vote | 12:53 |
| tobiash | so at the end there was verified-1 from an earlier run | 12:54 |
| tobiash | removing votes seems not to work | 13:02 |
| *** Cibo_ has joined #zuul | 13:10 | |
| *** rcarrillocruz has quit IRC | 13:11 | |
| mordred | tobiash: why do I get the feeling that we're going to find quite a few edge cases in encoding? | 13:14 |
| tobiash | mordred: ah, this one was actually a typo in my pipeline config (reports verified instead of Verified) | 13:16 |
| mordred | PHEW | 13:25 |
| mordred | Shrews: didn't we implement more than one node of a given name in a node request at some point? | 13:25 |
| mordred | Shrews: like, so that a use can say "give me an ubuntu named controller and 2 centos named compute" ? | 13:26 |
| Shrews | mordred: yeah, that's supported in v3 | 13:26 |
| mordred | Shrews: k. I thought so - I was just reviewing tobiash's patch for fixing the inventory we write out- and noticed that we're not taking that into accout which means we're not writing any group info to the file | 13:26 |
| Shrews | mordred: oh, different node "names"? hmmm, i know we do that on "types" | 13:26 |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/zuul master: Ensure build.start_time is defined onBuildCompleted https://review.openstack.org/466732 | 13:27 |
| Shrews | mordred: nodepool doesn't really care much about node "names" | 13:27 |
| Shrews | i think that's more a zuul-side thing, yeah? | 13:28 |
| mordred | oh - piddle. looking at the code I think there's something we missed here | 13:29 |
| Shrews | mordred: zuul justs asks for nodes of various types. it doesn't pass along names for those in the request | 13:30 |
| mordred | yah - I think it's fine from the nodepool side ... | 13:30 |
| tobiash | \o/ first working (check) job with py3 scheduler and executor :) | 13:32 |
| mordred | tobiash: NICE!!!! | 13:32 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul feature/zuulv3: Add Dockerfile https://review.openstack.org/465912 | 13:40 |
| tobiash | updated dockerfile for python3 ^^^ | 13:41 |
| tobiash | (and moved to contrib) | 13:41 |
| *** Cibo_ has quit IRC | 13:45 | |
| mordred | tobiash, pabelanger, jeblair: I think it might be worth discussing Dockerfile at today's meeting - I totally hear pabelanger's concern, but I also want to make sure we're in a good position to collaborate on Dockerfile - since I hear people like those sorts of things | 13:55 |
| mordred | I'm not sure if the right solution for us would be a zuul-docker repo, having the Dockerfile in the zuul repo or what - same questions with nodepool - and then there are questions in my mind about if we wanted to make a docker file for builder/launcher | 13:57 |
| mordred | it's not how were deploying it in infra right now - but clearly there is interest from folks in running it in that manner - so it seems like a topic we should at least be able to figure out what our git repo answer is | 13:57 |
| *** mmedvede has quit IRC | 13:58 | |
| tobiash | mordred: good idea, I have to check if I can attend (the meeting is at midnight for me) | 14:01 |
| *** mmedvede has joined #zuul | 14:01 | |
| *** hashar has joined #zuul | 14:01 | |
| Shrews | i don't really like them in the official repo, since it implies this is an officially supported way to deploy, when really it's just a convenience thing | 14:02 |
| Shrews | but i may be weird | 14:02 |
| tobiash | I'm ok with having it in-repo or out-of repo, but I like the idea of having a somewhat 'official or reference' public repo containing the dockerfiles so collaboration would be simplified | 14:06 |
| mordred | tobiash: yah - I thnk I can probably proxy for you if it's too late for you to be there | 14:16 |
| mordred | Shrews: I think that's a valid concern ... I think _eventually_ we would want to have an 'officially supported' story for container deployment- but I'm pretty sure that won't be a thing we 'support' in the next couple of months | 14:17 |
| mordred | Shrews: I mostly want to make sure that we have a place where people can collaborate on getting that to be a thing before we're fully ready to consider it a 'real' thing | 14:18 |
| *** hashar has quit IRC | 14:25 | |
| jlk | what time is the meeting? I really need to put it into my calendar | 14:45 |
| clarkb | jlk: http://eavesdrop.openstack.org/#Zuul_Meeting | 14:46 |
| clarkb | jlk: there is a little ics file you can use there | 14:46 |
| jlk | oh good, thanks. And I should be available at that time too | 14:46 |
| pabelanger | mordred: same, I don't think zuul proper is the place for Dockerfiles, but maybe docker-zuul or other repo would be okay. Its the same reason we'd add ansible bit into ansible-role-zuul and not main repo | 14:48 |
| mordred | pabelanger: ++ I imagine that's probably the right idea - but seems like a quick 5 minute conversation during the meeting can get us all on the same page | 14:48 |
| *** DangerousDaren has quit IRC | 14:58 | |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Python3: Use exec for self._activate_virtualenv() https://review.openstack.org/466070 | 15:24 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Wrap map() in list() for python3 https://review.openstack.org/466069 | 15:24 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Python3: RuntimeError: dictionary changed size during iteration https://review.openstack.org/466049 | 15:24 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Python3: encode / decode data as utf8 https://review.openstack.org/466065 | 15:24 |
| *** Cibo_ has joined #zuul | 15:40 | |
| *** Cibo_ has quit IRC | 15:44 | |
| jeblair | i'm seeing the py35 tests fail a lot in the github driver tests during the repo GC leak assertion at the end | 16:03 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: merger/executor: configure source connections only. https://review.openstack.org/466506 | 16:04 |
| jeblair | this is where we assert that there aren't any git.Repo objects that have somehow leaked (we run the GC and then examine all active objects to see if there are any git.Repo objects) | 16:04 |
| jeblair | obviously a lot of behavior around deallocation/GC will have changed in v3. yet, this seems to only be affecting the github tests so far... | 16:05 |
| jeblair | 2017-05-22 12:32:12,824 zuul.test DEBUG Leaked git repo object: <git.Repo "/tmp/tmp.1RIk82c0iv/tmpw7g93ox4/zuul-test/upstream/org/project/.git"> | 16:06 |
| jeblair | that tells us it's the "upstream" git repo object that leaked at least... the intersection of that plus the github tests suggests maybe something in the fake github framework? | 16:07 |
| SpamapS | interesting | 16:39 |
| SpamapS | jeblair: just out of curiosity I'm following your hunch. | 16:48 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Temporarily(?) add some debug statements around git repo creation https://review.openstack.org/466810 | 16:49 |
| jeblair | SpamapS: ^ nothing is jumping out at me, so i sprinkled some more debug statements to try to catch it | 16:50 |
| SpamapS | Seems like it creates a lot of repo objects when a singleton would do. But maybe that's just me. | 16:50 |
| SpamapS | well not a singleton | 16:50 |
| SpamapS | but a single repo per FakeGithubPullRequest | 16:50 |
| SpamapS | jeblair: yeah that's what I was thinking would be next too.. trace each one through. Also maybe wrap and monkeypatch git.Repo with a logging __init__ and __del__ | 16:52 |
| jeblair | SpamapS: that would have been less typing than that patch ^ :) | 16:52 |
| jeblair | SpamapS: the repo objects are treated as instantly disposable everywhere because gitpython doesn't re-read some parts of the git database if they change under it (eg, if the underlying repo is repacked and a large object file is replaced with a new one) | 16:53 |
| jeblair | so it's generally "create a repo object, do one operation, discard" | 16:54 |
| SpamapS | yeah that'd do it | 16:55 |
| *** Cibo_ has joined #zuul | 17:00 | |
| jeblair | jlk, mordred: revised 449390 lgtm | 17:13 |
| jeblair | pabelanger: typo in https://review.openstack.org/466360 | 17:15 |
| pabelanger | jeblair: thanks, will fix shortly | 17:21 |
| jeblair | pabelanger: see comment in https://review.openstack.org/466376 | 17:26 |
| pabelanger | jeblair: not sure I follow, could you rephrase | 17:30 |
| jeblair | pabelanger: we're working to create a standard library of jobs that multiple ci systems can share. it's okay for those jobs to use the "zuul_workspace_root" variable. | 17:33 |
| pabelanger | I disagree, I think we should avoid the usage of global variables in our roles. I think a better practice would be to have playbooks should pass in variables that are needed | 17:35 |
| jeblair | pabelanger: or put another way, if the goal of the 'run-tox' role is to run tox inside of zuul, it's okay for the role to use zuul variables. the only reason to remove zuul variables from the tox role would be if we wanted run-tox to be used outside of zuul. | 17:35 |
| pabelanger | agree, I think now, we should lean towards all roles being run anywhere | 17:36 |
| jeblair | pabelanger: i believe we have already discussed and agreed that, in the case of "zuul_workspace_root", we would make an exception since it's going to be very widely used. that's why we gave it a nice long prefix to avoid namespace collisions. | 17:36 |
| pabelanger | Ah, I understood we'd use it for playbooks, and continue to pass it into our roles | 17:37 |
| SpamapS | I don't believe Ansible is built for sharing outside narrow concerns. | 17:38 |
| jeblair | pabelanger: isn't it going to get very repetitive and verbose to add <<workspace: "{{ zuul_workspace_root }}/src/{{ zuul.project.canonical_name }}">> to every role that does anything? | 17:38 |
| SpamapS | so keeping roles super pure like that isn't actually helping anyone. It DOES help to not have a bazillion global vars. | 17:39 |
| SpamapS | So an exception or three for the things that every role uses are a good idea. | 17:39 |
| jeblair | https://review.openstack.org/466377 shows us what the playbooks will look like with that change: https://review.openstack.org/466377 | 17:39 |
| SpamapS | I'm still concerned about include_role | 17:39 |
| jeblair | SpamapS: i think we have agreed not to use it | 17:40 |
| pabelanger | jeblair: we can make that a job variable or share playbook vars.yaml file | 17:41 |
| jeblair | SpamapS: here's the change which previously had include_role and now has role arguments: https://review.openstack.org/466360 | 17:41 |
| pabelanger | but, if we plan on sharing roles with galaxy or other users, I think we should avoid having a role depend on a global variable, it should only reference something local or passed in | 17:41 |
| SpamapS | jeblair: oh good I'm just out of date. :) | 17:41 |
| SpamapS | me gusta | 17:42 |
| jeblair | pabelanger: i'm not sure i understand "we can make that a job variable or share playbook vars.yaml file"....? | 17:43 |
| *** Cibo_ has quit IRC | 17:44 | |
| SpamapS | pabelanger: that's just the thing. IMO, galaxy is a waste of our time. | 17:46 |
| SpamapS | Ansible roles just weren't architected for sharing. | 17:46 |
| pabelanger | jeblair: http://paste.openstack.org/show/610258/ | 17:47 |
| pabelanger | playbooks that share common variables, we can use vars_files for them | 17:47 |
| jeblair | (we might end up wanting to use galaxy to distribute the zuul standard library at some point, but as mordred has noted, it has some technical obstacles for that right now, and in the mean time, we kind of expect other zuuls to be able to just point at the stdlib git repos, so i agree, we don't need to focus on that right now) | 17:47 |
| pabelanger | SpamapS: I disagree, I am using roles from galaxy today | 17:48 |
| jeblair | SpamapS: [having agreed with you on that ^ in the zuul context, i'm not sure i'd agree "ansible roles weren't architected for sharing" -- i mean, that's the unit of sharing in ansible, right? there's lots of roles sucessfully being shared in general] | 17:49 |
| SpamapS | If I had been able to use any galaxy roles for real work without vendoring and fixing them, I'd think they're useful. | 17:50 |
| jeblair | SpamapS: point taken. :) | 17:50 |
| jeblair | pabelanger: and the vars.yaml file will be read by all of those playbooks, i take it? | 17:51 |
| pabelanger | jeblair: yes | 17:53 |
| pabelanger | I think it is possible we are going to want to share data (variables) between playbooks. To avoid copypasta | 17:54 |
| jeblair | pabelanger: so what if we added that variable there (but call it zuul_project_workspace rather than tox_workspace) and then had the tox (and similar) roles use a workspace var which defaults to zuul_project_workspace? | 17:56 |
| jeblair | pabelanger: does that strike a balance between "this role is primarily designed for zuul" but also doesn't require zuul as part of the api contract? | 17:57 |
| SpamapS | pabelanger: typically set_fact is used to share between roles. Or is there another way I'm not aware of? | 17:59 |
| pabelanger | jeblair: and so I follow, why default to zuul_project_workspace in the role | 18:03 |
| jeblair | pabelanger: so that we don't have to add a boilerplate <<workspace: "{{ zuul_workspace_root }}/src/{{ zuul.project.canonical_name }}">> to every invocation of a role that was designed to "run tox for the current project" | 18:05 |
| *** rcarrillocruz has joined #zuul | 18:11 | |
| pabelanger | okay, I am a little confused. I thought we wanted to pass variables into a role, this is why did this with envlist: http://paste.openstack.org/show/610263/ to avoid reading it from global vars: http://paste.openstack.org/show/610264/ | 18:13 |
| jeblair | pabelanger: that was a different variable. with a different scope. for a different purpose. | 18:15 |
| jeblair | pabelanger: if a role needs an argument to provide some context-specific piece of information, let's pass it in. but this isn't especially context specific -- there's an obvious default global value we can use here and it makes things much easier to follow. | 18:20 |
| pabelanger | jeblair: that to mean seems confusing... however, we could just do: http://paste.openstack.org/show/610265/ | 18:23 |
| jeblair | pabelanger: why did you move the envlist argument out of the role argument? | 18:23 |
| pabelanger | because I am struggling to see the difference of scoping between workspace and envlist | 18:24 |
| jeblair | pabelanger: workspace is something that is used by every tox job, and every makefile job, and every ant job, and it will always be the same. it's the same whether you run "make test" or "make tarball". it's the same whether you run "tox -epy27" or "tox -ep35". however, envlist is different for different jobs. where workspace is fundamental to all uses of the role, envlist alters the behavior of the role so it can be used in different jobs ... | 18:26 |
| jeblair | ... for different purposes. | 18:26 |
| jeblair | pabelanger: i'm not sure we can write hard and fast rules yet. we have a lot of options and we have to weigh a lot of factors as we decide what to use. we want the jobs to be easy for non-specialist developers to create and edit. we want to be able to share content across different zuul installations. and we want to make good API decisions so we don't back ourselves into a corner in the future. | 18:30 |
| pabelanger | yes, my main concern is, because openstack-zuul-jobs and openstack-zuul-roles are over 2 repos, if start using global variables, it is going to be difficult to work with. Even now, it has been some frustrations trying to manage the CRD in making these changes. This is why I am pushing back a little and force us to pass all variables in, so we can just look at one side of the repo and see what is happening. | 18:33 |
| jeblair | pabelanger: perhaps we should merge them into one repo? we may not be gaining much by having them separate... | 18:35 |
| pabelanger | However, I understand we want things to be easy. And if we think people won't have much ansible experience for making changes to our jobs, then a single repo might be better | 18:35 |
| *** harlowja has joined #zuul | 18:37 | |
| jeblair | pabelanger: and in general, i don't think we should use many global variables. but we have a bunch of roles here that are, basically, designed for a certain context, so this one seems like it might be worthwhile. | 18:38 |
| pabelanger | The gain for me, was to share our openstack-zuul-roles. But, maybe we are moving forward too fast on that | 18:38 |
| jeblair | pabelanger: oh we're going to share it, it's just that we're going to share it with other zuul users | 18:39 |
| jeblair | er, not openstack-zuul-roles | 18:39 |
| jeblair | zuul-jobs | 18:39 |
| jeblair | i don't think we expect openstack-zuul-roles to be shared, except maybe by openstack third-party ci ops. | 18:39 |
| jeblair | (this is getting confusing because we haven't yet created the other repos which we do want to share) | 18:41 |
| *** harlowja has quit IRC | 18:43 | |
| *** Cibo_ has joined #zuul | 18:45 | |
| jeblair | pabelanger: so, we've been at this for an hour and 15 minutes... do we have a plan? | 18:46 |
| pabelanger | jeblair: we can abandon 466376 | 18:52 |
| pabelanger | it already has the correct workspace currently | 18:52 |
| jeblair | pabelanger: okay. i think moving that to the per-role defaults file so it could be overridden would be an improvement. and i also think that setting it as a global variable to avoid that repitition would be okay as well. | 18:55 |
| Shrews | maybe we should make the py35 job nv for a while until we sort out the random fail issues there? | 19:06 |
| jeblair | Shrews: maybe, though i've only spent about 10 minutes looking into it so far... i'd like us to at least take a stab at fixing it first... | 19:13 |
| jeblair | (i'm not sure how much time other folks have had to look into it) | 19:13 |
| Shrews | sure, just throwing it out for consideration | 19:14 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Remove uncalled test code https://review.openstack.org/464276 | 19:16 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Fix inventory vars containing spaces https://review.openstack.org/465072 | 19:18 |
| jlk | hello again. | 19:48 |
| mordred | look it's a jlk | 19:51 |
| jlk | OH good, I get to continue my rebase. | 20:07 |
| jlk | jeblair: to make this rebase easier, I'm going to pull your driver specific requires commit into my stack. | 20:19 |
| jeblair | jlk: i think my change doesn't depend on anything outstanding, so you should just need to rebase on it, right? (ie, you shouldn't need to change 466105 at all?) | 20:20 |
| jlk | I think it's getting changed slightly because due to a mishap I just rebased on the tip of feature/zuulv3 | 20:21 |
| jlk | not "changed" per se, just rebased. | 20:21 |
| jlk | I could probably figure out a way out of this to not do that | 20:21 |
| jeblair | jlk: hrm... it's not a small change... it might be worth it so we don't have to comb through it again :) | 20:24 |
| jlk | yeah. | 20:24 |
| pabelanger | Shrews: okay, infracloud-chocolate should be coming backonline | 20:24 |
| jlk | working it out | 20:24 |
| jeblair | jlk: also, you and mordred like it... maybe we can ask clarkb or pabelanger to give it a quick once-over for whether the concept is okay (can probably skip detailed code review at this point) and merge it? | 20:26 |
| jlk | oh that'd work even better actually | 20:26 |
| jeblair | pabelanger, clarkb: if you have a moment to look at https://review.openstack.org/466105 to make sure the idea is okay, that'd be great :) | 20:26 |
| jlk | yes please, clarkb pabelanger can you look at https://review.openstack.org/#/c/466105/5 | 20:26 |
| Shrews | pabelanger: awesome | 20:26 |
| jlk | oh haha | 20:26 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Temporarily(?) add some debug statements around git repo creation https://review.openstack.org/466810 | 20:26 |
| jeblair | SpamapS: ^ i did the init monkeypatch | 20:27 |
| jeblair | clarkb, pabelanger: https://review.openstack.org/#/c/466105/5/tests/fixtures/config/requirements/reject/git/common-config/zuul.yaml is the change in a nutshell :) | 20:28 |
| clarkb | jeblair: and if you had a github block and a gerrit block zuul will apply the one appropriate for where the event originated? | 20:31 |
| jlk | yeah, it looks at the event source. | 20:31 |
| jlk | well, by which I mean | 20:32 |
| clarkb | that makes sense to me at first pass | 20:32 |
| jeblair | clarkb: for the source of the change, rather than event -- this also helps us in the case of, say, a hypothetical IRC trigger enquing a gerrit change (since the irc trigger doesn't know what a gerrit is). but the pipeline can still say "the change needs these things..." | 20:32 |
| jlk | https://review.openstack.org/#/c/466105/5/zuul/driver/github/githubtrigger.py | 20:32 |
| jlk | the github trigger adds the github filter | 20:33 |
| jeblair | yes, true, events are affected as well | 20:33 |
| jeblair | so it's both things -- we add per-trigger subclasses of EventFilter to handle trigger events (which, in the zuul.yaml, were already separated by connection). and we also add per-source subclasses of RefFilter (which, to date, was not separated by connection in the zuul.yaml, so we also do that) | 20:35 |
| jeblair | the first thing is mostly an internal code change; the second thing is a user-facing change | 20:35 |
| jeblair | (and actually adds new capabilities) | 20:35 |
| SpamapS | jeblair: and now you have to recheck that over and over until it fails? | 20:36 |
| jeblair | SpamapS: i guess; or merge it and see if we catch it on other outstanding changes | 20:36 |
| pabelanger | jeblair: jlk: Seems straightforward | 20:37 |
| jeblair | SpamapS: i am now trying to figure out where to put blank lines to make pep8 happy | 20:38 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Temporarily(?) add some debug statements around git repo creation https://review.openstack.org/466810 | 20:39 |
| SpamapS | jeblair: perhaps in the pep8.py file that complains about such things? Oh wait that would just make me happy. ;) | 20:41 |
| jeblair | not just you | 20:42 |
| SpamapS | are we zuul meeting today? | 20:50 |
| jeblair | SpamapS: yes | 20:51 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Quote message when reporting to Gerrit https://review.openstack.org/466345 | 20:52 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Temporarily(?) add some debug statements around git repo creation https://review.openstack.org/466810 | 20:52 |
| SpamapS | coo | 20:52 |
| SpamapS | l | 20:52 |
| pabelanger | jeblair: I think we need our first trusted playbook, I would like to try using https://gist.github.com/cliffano/9868180 to make the ansible logs more human readable. | 21:00 |
| jeblair | pabelanger, mordred: it's true the ansible logs are not readable right now, but maybe because of a bug in the callback plugin | 21:02 |
| jeblair | pabelanger, mordred: unfortunately, i have to do some work before the meeting and can't discuss this right now. perhaps mordred can chime in on what's wrong. | 21:03 |
| mordred | jeblair, pabelanger: just getting off a call - will lok in just a sec | 21:08 |
| jlk | jeblair: looks like you were able to tickle the leak! | 21:21 |
| jlk | so, has anybody tried running zuuls test suite using zetcd instead of zookeeper? | 21:24 |
| mordred | jlk: not that I'm aware of, no | 21:25 |
| SpamapS | indeed it looks like is right after "Resuming queue processing" | 21:28 |
| * SpamapS hasn't looked at what that means | 21:28 | |
| Shrews | jlk: is there a reason to? | 21:36 |
| jlk | curiosity | 21:36 |
| jlk | If folks already have an etcd cluster, they may not want to introduce a zookeeper cluster. | 21:36 |
| mordred | jlk: yah - I'm hoping most of them will just decide to run zuul in their k8s and that the zk portion will just be a happy pod that gets spun up for them as part of their helm chart... | 21:49 |
| mordred | jlk: but that also may be me trying to deploy words incorrectly | 21:49 |
| jlk | zk takes some thinking | 21:50 |
| jlk | like, replication, location diversity, etc.. | 21:50 |
| jlk | Sure you can use k8s stuff to do that, but if you're _already_ doing that for etcd, adding the zuul data into etcd would be a far more efficient path. | 21:50 |
| mordred | jlk: yah. I think the real trick with a zetcd would be locking - since we're using it for that purpose. I'm pretty sure a zk layer on etcd will get the kv tree store part right | 21:52 |
| mordred | but I'd be concerned about edge conditions around locking | 21:52 |
| jlk | yeah, it's early beta, I have no idea what rough edges are. | 21:52 |
| jlk | but I barely have an idea of what zookeeper is to begin with | 21:53 |
| SpamapS | mordred: if you read the way zetcd is being developed and tested.. I trust it to DTRT | 21:55 |
| SpamapS | Not sure I'd bet my DC on it. But I'd run it if I couldn't get ZK deployed. | 21:55 |
| SpamapS | They didn't just toss it out there. | 21:56 |
| jeblair | jlk: we decided early on to pick *one* dlm and design for it. i do not want to support etcd like openstack supports postgresql. | 21:56 |
| jlk | or if you already have etcd and needed some zk functionality. | 21:56 |
| SpamapS | I'm going to CoreOS fest next week (hopefully) and I'm going to hunt down the folks working on it. | 21:56 |
| jlk | jeblair: I don't think we should. | 21:56 |
| jlk | jeblair: I'm merely curious if our workload would function on the zetcd implementation of zookeeper. | 21:56 |
| jeblair | jlk: which? pick one, or support more than one poorly? :) | 21:56 |
| SpamapS | jeblair: unfortunately for us, we picked ZK just before etcd got as good as / better than zk ;) | 21:57 |
| jlk | jeblair: I don't think we (zuul) should support anything abut zookeeper | 21:57 |
| jeblair | jlk: yeah, i don't mean to dismiss the question. :) mostly just wanted to (re)state the intention there so we don't end up sending mixed signals | 21:57 |
| mordred | I agree with jlk and jeblair - although I also am curious whether our workload would function | 21:57 |
| jeblair | jlk: if $folks want to try it out, that's cool. and if $lots_of_folks say it's great and that's the way to go, we can revisit. :) | 21:58 |
| jeblair | SpamapS: yeah, by the time we're ready to consider a switch, there will be lots of good data and track records. :) | 21:58 |
| jeblair | (i like my data stores to have a certain patina) | 21:59 |
| clarkb | fwiw you shouldn't colocate your etcds anyways (because there aren't acls aiui) so you'll have to deploy and figure all that stuff out multiple times regardless | 21:59 |
| jeblair | mordred, pabelanger: let me know when you're both around and we can chat about the ansible log. | 21:59 |
| jlk | clarkb: okay fair, but if you're already using etcd, then you've got templates for deploying your etcds | 22:00 |
| SpamapS | etcd has an RBAC system | 22:00 |
| rbergeron | are we talking about the new random zetcd project thing? | 22:00 |
| SpamapS | but no ACL IIRC | 22:00 |
| SpamapS | rbergeron: yeah | 22:00 |
| rbergeron | I KNEW IT | 22:00 |
| jlk | sorry I tossed a distraction bomb in the channel | 22:01 |
| SpamapS | I think it's the etcd folks' way to try and take over the DLM world ;) | 22:01 |
| * SpamapS notes the time | 22:01 | |
| rbergeron | jlk: distraction bomgs surrounded by squirrels? | 22:01 |
| rbergeron | wow, bombs, bongs, whategver. HEY it's meeting time, and we're all here, and i'm not at a conference for the first time in | 22:01 |
| jlk | indeed | 22:01 |
| rbergeron | um | 22:01 |
| clarkb | SpamapS: oh neat, is that new in v3 too? | 22:01 |
| rbergeron | yeah. | 22:01 |
| rbergeron | like | 22:01 |
| jeblair | zuul meeting in #openstack-meeting-alt | 22:02 |
| jamielennox | Shrews, tristanC: oh - i thought all those yaml logging patches had been merged already | 22:07 |
| jamielennox | will finish that up today | 22:07 |
| *** jkilpatr has quit IRC | 22:08 | |
| clarkb | docs say 2.1 was version that added it | 22:11 |
| *** Cibo_ has quit IRC | 22:27 | |
| *** jkilpatr has joined #zuul | 22:27 | |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Add bubblewrap to bindep / test-setup.sh https://review.openstack.org/461849 | 22:42 |
| jeblair | pabelanger, mordred: i have to EOD at the end of the meeting. let's discuss ansible_log.txt tomorrow? | 22:53 |
| mordred | kk | 22:56 |
| pabelanger | jeblair: sure | 22:56 |
| pabelanger | So, it seems we cannot load any external roles in zuulv3-dev.o.o atm, unless they are in zuul tenant configuration? | 22:57 |
| pabelanger | I cannot see if galaxy support has been added | 22:57 |
| pabelanger | or external git source | 22:58 |
| * jlk notes that it's somewhat difficult to find the zuul mailing list link | 23:03 | |
| jeblair | pabelanger: galaxy support has not been added | 23:03 |
| rbergeron | jlk: i don't thin kthere's a separate zuul mailing list? | 23:03 |
| jlk | that could be why | 23:03 |
| rbergeron | i just ship things to openstack-infra and openstack-devel when i send the zuul update | 23:03 |
| rbergeron | i suspect at some point (once zuul is "not just for openstack") we might get to needing that, but pretty sure we're not at that point yet | 23:04 |
| jeblair | jlk: it is not in the readme. please feel free to add. :) | 23:04 |
| rbergeron | most zuul q's go to =infra | 23:04 |
| rbergeron | jeblair: is there an actual separate list? | 23:04 |
| jeblair | rbergeron: yep, that's how i see it. | 23:04 |
| jeblair | rbergeron: nope. openstack-infra for now. until it becomes too awkward. | 23:05 |
| rbergeron | okay -- that's what i thought. just couldn't quite parse what ou said to jesse -- i guess the summary is "document that openstack-infra is the place to mail for now" if that's not clear | 23:05 |
| rbergeron | ? | 23:05 |
| jlk | correct | 23:05 |
| rbergeron | (unless it already is written that way) | 23:05 |
| jeblair | sorry. short reply was too short. :) | 23:06 |
| rbergeron | woot. okay, well, i.. apparently have to make a boatload of grilled cheese for hungry bottomless-stomached teenagers. sigh | 23:06 |
| rbergeron | hugs y'all | 23:06 |
| jeblair | rbergeron: toodles. | 23:06 |
| jeblair | i have to eod now too | 23:07 |
| Shrews | rbergeron: grilled cheese with sliced hotdogs (http://www.seriouseats.com/recipes/2015/02/chili-cheese-dogs-grilled-cheese-recipe.html) | 23:08 |
| Shrews | rbergeron: you're welcome | 23:08 |
| Shrews | Oh, next Monday is memorial day. Should we have a zuul meeting then? | 23:28 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: Add SSH Agent Primitives and usage https://review.openstack.org/462712 | 23:28 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: Add support for bwrap https://review.openstack.org/453851 | 23:28 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Add javascript license information https://review.openstack.org/466521 | 23:42 |
| rbergeron | shrews: i dont kniw whether to cheer or gag ;) | 23:47 |
| clarkb | rbergeron: tuna melts are a good less gaggy option | 23:48 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!