| pabelanger | mordred: cool, thanks | 00:00 |
|---|---|---|
| pabelanger | mordred: when you have time, executor-debug.log is showing some new warnings in callback_plugins | 00:00 |
| pabelanger | also see more Ansible output again, not sure if expected in debug log | 00:01 |
| pabelanger | could be a side affect | 00:02 |
| mordred | pabelanger: this: | 00:03 |
| mordred | f73b046] Ansible output: b" [WARNING]: could not parse environment value, skipping: ['{{ tox_environment |" | 00:03 |
| mordred | 2017-07-21 00:02:15,577 DEBUG zuul.AnsibleJob: [build: 4ee60681aa364036a9a2d080ff73b046] Ansible output: b"default(omit) }}']" | 00:03 |
| mordred | ? | 00:03 |
| mordred | (that's weird, btw) | 00:04 |
| mordred | 2017-07-21 00:02:15,557 DEBUG zuul.AnsibleJob: [build: 4ee60681aa364036a9a2d080ff73b046] Ansible output: b'skipping: [ubuntu-xenial] => {"changed": false, "skip_reason": "Conditional result was False", "skipped": true}' | 00:04 |
| pabelanger | that is new, but expected | 00:04 |
| mordred | that's weird too - I think that seems like we should log | 00:04 |
| mordred | I think we should, if we can, get both of those things into th ejob log instead of the zuul debug log | 00:05 |
| pabelanger | ++ | 00:05 |
| pabelanger | ya, I haven't seen skipping yet in job-output.txt | 00:05 |
| mordred | k. I'll get that done next | 00:05 |
| pabelanger | http://paste.openstack.org/show/616096/ | 00:06 |
| pabelanger | was the warning I saw too | 00:06 |
| mordred | jeblair: I have verified that report_url is getting properly updated in status.json - so the issue of displaying the wrong url is most likely in the status page | 00:06 |
| mordred | NoneType is fixed in that latest patch | 00:06 |
| pabelanger | mordred: 485864? | 00:07 |
| mordred | yah | 00:07 |
| pabelanger | nice | 00:07 |
| pabelanger | going to read up how we can attach job-output.txt to subunit | 00:07 |
| pabelanger | so we can see logging changes with tox -epy35 | 00:08 |
| mordred | cool | 00:08 |
| SpamapS | jeblair: should be fairly straight forward to add a concurrency limit | 00:09 |
| * SpamapS knows he's been editting a lot of code today because he tried to end that IRC comment with <ESC>:wq | 00:09 | |
| mordred | SpamapS: :) | 00:11 |
| SpamapS | and now I need to write a test playbook that writes 2MB to a job dir.. hm | 00:12 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Add missing word to docs https://review.openstack.org/485874 | 00:15 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: WIP Remove refspec https://review.openstack.org/485875 | 00:15 |
| jeblair | mordred: fixed ^ | 00:16 |
| jeblair | SpamapS: id appreciate a review from you on 485329 (and children) when you have a chance. | 00:17 |
| pabelanger | will poke at subunit logging more later, don't want to get distracted :) | 00:18 |
| SpamapS | jeblair: certainly. Almost ready to emerge from my coding cocoon. :) | 00:22 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Log skipped tasks to the job output https://review.openstack.org/485896 | 00:40 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Add spacer line after loops https://review.openstack.org/485897 | 00:40 |
| SpamapS | hrm | 00:42 |
| SpamapS | pause module does not play nice with logging | 00:42 |
| mordred | SpamapS: with the job console log? | 00:42 |
| SpamapS | mordred: with ttrun in unit tests :_P | 00:42 |
| SpamapS | I think it sends a CR or something | 00:43 |
| mordred | ah. weird | 00:43 |
| SpamapS | wait_for: delay=10 path=/ works fine | 00:47 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul feature/zuulv3: Display log url when a job completes https://review.openstack.org/485898 | 00:49 |
| mordred | jeblair: ^^ that should fix the status page url completion thing | 00:49 |
| pabelanger | +2 | 00:51 |
| jeblair | mordred: i assume we were swapping it inside the json construction (in python) before? | 00:51 |
| SpamapS | so.. | 00:53 |
| SpamapS | I think I've got this thing worked out | 00:53 |
| SpamapS | but.. my thread is still running after its stop() method because it sleeps for 1s between du and looking for the stopped flag.. | 00:54 |
| SpamapS | whitelist it? | 00:54 |
| SpamapS | or sleep a bit? | 00:54 |
| mordred | jeblair: yes - I believe that's where it was changing before | 00:54 |
| SpamapS | Feels like a good thing to check for leaked threads | 00:55 |
| mordred | pabelanger: https://review.openstack.org/#/c/483987/ needs to have the depends-on dropped | 00:55 |
| jeblair | SpamapS: i'd whitelist, but maybe we can have a list of threads we should wait a little bit longer on before raising the exception in shutdown. | 00:58 |
| jeblair | SpamapS: greylist. | 00:58 |
| *** jkilpatr has quit IRC | 00:58 | |
| SpamapS | jeblair: Yeah, these will be gone in just a tad under 1s I think. | 00:58 |
| SpamapS | actually one waits 5s on its condvar before checking | 00:59 |
| SpamapS | it's too bad there's no clean "select([condvar1, condvar2])" | 01:00 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: Monitor job root and kill over limit jobs https://review.openstack.org/485902 | 01:02 |
| pabelanger | mordred: thanks! | 01:04 |
| pabelanger | mordred: https://review.openstack.org/#/c/485834/ and https://review.openstack.org/#/c/485836/ are straightforward too | 01:07 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Display log url when a job completes https://review.openstack.org/485898 | 01:18 |
| *** isaacb_ has quit IRC | 01:22 | |
| mordred | pabelanger: that ^^ should just magically go live via puppet right? | 01:36 |
| mordred | yup | 01:43 |
| mordred | BOOYAH. status page links switch to log links now | 01:43 |
| mordred | ooh! and the gzip patch landed | 01:44 |
| mordred | so we have date links again: http://logs.openstack.org/87/483987/9/check/tox-linters/26eb683/job-output.txt.gz#_2017-07-21_01_41_16_968070 | 01:44 |
| Shrews | mordred: \o/ | 01:57 |
| mordred | Shrews: I tell you what - that log streaming is some sexy stuff | 02:00 |
| Shrews | yup | 02:00 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul-jobs master: Simplify bindep logic removing fallback support https://review.openstack.org/482650 | 02:04 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: Monitor job root and kill over limit jobs https://review.openstack.org/485902 | 03:18 |
| SpamapS | now with docs! | 03:18 |
| SpamapS | jeblair: all +3'd.. though I do think there are some little fixes we could make to the docs... it's mostly t3h awesome. | 03:44 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Check out implicit branch in timer jobs https://review.openstack.org/485329 | 03:49 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Rename tags job variable jobtags https://review.openstack.org/485845 | 03:50 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Rename uuid to build https://review.openstack.org/485851 | 03:51 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Add zuul.items to job vars https://review.openstack.org/485853 | 03:51 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Add missing word to docs https://review.openstack.org/485874 | 03:52 |
| tobiash | morning | 05:27 |
| tobiash | getting post failures after my daily deployment rebase | 05:27 |
| * tobiash is investigating | 05:27 | |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Log items in loops better https://review.openstack.org/485864 | 05:39 |
| tobiash | ah, just the uuid -> build rename bit me | 05:49 |
| *** jhesketh has quit IRC | 06:35 | |
| *** jhesketh has joined #zuul | 06:35 | |
| tobiash | jeblair: tried to import zuul-jobs into my deployment via the git driver: | 06:55 |
| tobiash | jeblair: http://paste.openstack.org/show/616126/ | 06:55 |
| tobiash | jeblair: was the git driver intended to be used as a source for job configs? | 06:59 |
| tobiash | jeblair, pabelanger: currently trying out to import zuul-jobs via a local mirror (which I have to do under a different name) | 07:06 |
| tobiash | jeblair, pabelanger: zuul refuses to start with this | 07:07 |
| tobiash | jeblair, pabelanger: http://paste.openstack.org/show/616127/ | 07:07 |
| tobiash | jeblair, pabelanger: what do you think about separating out the project section of zuul-jobs into a different repo | 07:08 |
| tobiash | jeblair, pabelanger: that would simplify consuming this repo from 3rd parties (which may have to mirror them locally) | 07:09 |
| *** amoralej|off is now known as amoralej | 07:11 | |
| SpamapS | tobiash: ahh yeah, that was a real breaking change... doh ;) | 07:19 |
| SpamapS | tobiash: yes, the git driver is specifically intended to be used as a source for things like base configs. | 07:19 |
| tobiash | SpamapS: found it quickly and the error (it was even well described in the build log, which was only available during web streaming...) | 07:20 |
| SpamapS | :) | 07:20 |
| *** hashar has joined #zuul | 07:21 | |
| SpamapS | it's a bold new world | 07:21 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul-jobs master: Rename uuid to build https://review.openstack.org/486030 | 07:46 |
| tobiash | jeblair, mordred: before restarting something you'll probably want to land ^ | 07:47 |
| SpamapS | tobiash: +3'd ... seems urgent | 08:18 |
| openstackgerrit | Merged openstack-infra/zuul-jobs master: Rename uuid to build https://review.openstack.org/486030 | 08:18 |
| tobiash | SpamapS: wait | 08:19 |
| tobiash | SpamapS: too late, I should have said together with the restart | 08:19 |
| tobiash | SpamapS: restart and land need to be the same, sorry forgot to note that | 08:19 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul feature/zuulv3: DNM: test change https://review.openstack.org/486039 | 08:22 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul-jobs master: Revert "Rename uuid to build" https://review.openstack.org/486042 | 08:24 |
| tobiash | SpamapS: now we have two possibilities, either land ^ or someone needs to restart scheduler and/or executor before the jobs work again | 08:25 |
| tobiash | SpamapS: I personally would be fine with waiting for a restart | 08:28 |
| SpamapS | tobiash: let's leave it | 08:51 |
| SpamapS | we'll agree to never never do this again | 08:51 |
| SpamapS | :) | 08:51 |
| tobiash | SpamapS: I promise to be more precise in my wording next time :) | 08:52 |
| *** jkilpatr has joined #zuul | 10:26 | |
| *** jkilpatr has quit IRC | 10:33 | |
| *** jkilpatr has joined #zuul | 11:09 | |
| *** hashar is now known as hasharAway | 11:11 | |
| *** hasharAway is now known as hashar | 11:43 | |
| pabelanger | mordred: nice work on status page | 14:14 |
| pabelanger | Hmm, jobs are failing | 14:16 |
| pabelanger | zuul.build | 14:17 |
| pabelanger | guess that is the 486030 change | 14:17 |
| pabelanger | guess we need to increase testing on zuul-jobs for those roles | 14:18 |
| pabelanger | right, that's because they are used in the trusted project | 14:19 |
| pabelanger | mordred: jeblair: going to restart zuulv3 to pick up latest variable changes | 14:23 |
| SpamapS | pabelanger: yeah that was a breaking change, not much we could do with testing of changes there | 14:23 |
| pabelanger | SpamapS: ya | 14:24 |
| pabelanger | okay, everything restarted | 14:26 |
| pabelanger | SpamapS: tobiash: https://review.openstack.org/#/c/485834 and https://review.openstack.org/#/c/485836 are ready for review if you'd like | 14:32 |
| pabelanger | playbook changes for latest zuulv3 updates | 14:32 |
| pabelanger | and removes duplicate role from being run | 14:32 |
| tobiash | pabelanger: +2 | 14:34 |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul-jobs master: Remove validate-host from unittests/pre.yaml https://review.openstack.org/485836 | 15:06 |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul-jobs master: Remove gather_facts: true https://review.openstack.org/485834 | 15:06 |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul-jobs master: WIP: Move subunit processing https://review.openstack.org/485840 | 15:06 |
| pabelanger | okay, I think we have an issue with upload-logs role | 15:19 |
| pabelanger | jeblair: is it possible for rev, newrev and oldrev to all be null? http://paste.openstack.org/show/616185/ | 15:19 |
| *** jesusaurum has joined #zuul | 15:23 | |
| *** jesusaur has quit IRC | 15:26 | |
| jeblair | tobiash: yes, i want the git driver to be usable for things like zuul-jobs. however, it hasn't kept up with the others, and i don't think it has tests yet. also, i'm not sure it works with git network urls? (it might need to clone things locally into a private area in order to work?) | 15:54 |
| jeblair | tobiash: in the tenant config, you can "include: job" for the zuul-jobs repo to tell it to only load jobs (and not the project config) | 15:55 |
| jeblair | tobiash: however, yes, i agree that we should eventually move that out of that repo to make it easier for folks to use it without needing to use include/exclude statements. but it might be more convenient to do that a little later after we've stabilized zuul-jobs a bit more. | 15:56 |
| jeblair | pabelanger: yes, newrev and oldrev are not valid values for pre-merge changes. i think i was a little sloppy yesterday in docs/code about whether those variables would be absent or null when they are not applicable. i actually don't really care -- what do you think would be best from an ansible user POV? | 15:58 |
| jeblair | mordred, SpamapS: ^ | 15:58 |
| pabelanger | having them null is find | 16:00 |
| pabelanger | absent would be more work in ansible | 16:00 |
| pabelanger | but we need to update our log_path: http://git.openstack.org/cgit/openstack-infra/zuul-jobs/tree/roles/upload-logs/tasks/main.yaml | 16:00 |
| pabelanger | now I see | 16:01 |
| jeblair | pabelanger: oh i see | 16:01 |
| pabelanger | we need to update http://git.openstack.org/cgit/openstack-infra/zuul-jobs/tree/roles/upload-logs/tasks/main.yaml#n7 | 16:01 |
| pabelanger | when zuul.newrev is not None | 16:01 |
| jeblair | pabelanger: yep. | 16:01 |
| jeblair | pabelanger: "is defined" isn't that bad... | 16:02 |
| pabelanger | right, it is defined, but null | 16:02 |
| pabelanger | so zuul.newrev[-2:] fails | 16:02 |
| jeblair | pabelanger: sorry, i meant, now that i see that there's "when: foo is defined" i'm wondering is it really easier to have them null? | 16:03 |
| pabelanger | I think we want them always defined, but they should be empty | 16:03 |
| pabelanger | s/should/could | 16:03 |
| pabelanger | that way we always have the same zuul variables in the inventory file | 16:04 |
| tobiash | jeblair: ah, missed that config detail... thx | 16:04 |
| jeblair | yeah, that might be more clear to humans | 16:04 |
| pabelanger | jeblair: otherwise, we'd likely need to do something like {{ zuul.newrev | default(None) }} when accessing it in playbooks | 16:05 |
| jeblair | pabelanger: yeeah, if we used it like that. i suspect that most uses would look more like the upload-logs role, where we decide whether we're in pre-merge or post-merge mode and do something completely different depending on that. | 16:06 |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul-jobs master: upload-logs: zuul.newrev can be none now https://review.openstack.org/486172 | 16:08 |
| jeblair | pabelanger: so we have: the argument for "None" is that it makes for more clear debugging, and in cases where it might be optional, it's easier to handle in jinja templates. the argument for "undefined" is that it's still easy to use in a conditional, but will produce an error if it's used in the wrong context (so we don't accidentally publish a "None.tar.gz" file :) | 16:08 |
| SpamapS | Not sure I agree null is better than absent in Ansible | 16:09 |
| SpamapS | jinja makes it pretty easy to deal with undefined things. | 16:09 |
| SpamapS | nulls can be sneaky | 16:09 |
| tobiash | yes, especially if you want a to use a default value with {{ foo | default(whatever) }} | 16:10 |
| tobiash | that would be harder with defined None values | 16:10 |
| pabelanger | tobiash: that is true | 16:11 |
| pabelanger | however, do we expect users to be modifying zuul variables? | 16:12 |
| jeblair | no | 16:12 |
| tobiash | I think the following would be needed for dealing with None values {{ foo if foo is not None else 'bar' }} | 16:12 |
| pabelanger | jeblair: having zuul.newref:<empty> is another option | 16:13 |
| pabelanger | then {{ foo | default(whatever) }} should work | 16:13 |
| jeblair | pabelanger: i don't understand the syntax "zuul.newref:<empty>" | 16:13 |
| tobiash | is this an ansible keyword for 'defined but actually undefined'? | 16:14 |
| pabelanger | jeblair: https://etherpad.openstack.org/p/ansible_variables | 16:15 |
| jeblair | tobiash: a second kind of null? | 16:15 |
| *** hashar is now known as hasharDinner | 16:15 | |
| pabelanger | rev is just empty, with our null or none keywork | 16:15 |
| jeblair | pabelanger: when i load that with yaml, that loads as None. | 16:15 |
| tobiash | jeblair: don't know | 16:15 |
| tobiash | ansible can be tricky with this kind of stuff | 16:16 |
| pabelanger | jeblair: I wonder why we are setting it to null | 16:16 |
| *** bhavik1 has joined #zuul | 16:16 | |
| jeblair | pabelanger: what do you mean? why is zuul setting it to null? because i programmed it to yesterday. | 16:17 |
| pabelanger | jeblair: right, at the moment it is zuul.rev: null in inventory file | 16:17 |
| pabelanger | I think null / none / <empty> all mean different things in ansible world | 16:17 |
| tobiash | tried a few weeks ago to forward a variable into a role with foo: "{{ bar | default(omit) }}" and the result was not an undefined variable in the role but something like 'omit_placeholder_<long hexstring>' | 16:17 |
| jeblair | pabelanger: no, "null" in yaml is equivalent to "None" in python. | 16:18 |
| tobiash | and <empty> a somewhat super-none? | 16:19 |
| jeblair | pabelanger: i've never heard of "<empty>". but it looks like you're not trying to say "<empty>". based on the etherpad you're using "<empty>" to mean no value present in the yaml. that's the same as null. it gets loaded into python as None. | 16:19 |
| pabelanger | jeblair: yes, that's what I was trying to say. I also confirmed null is the same for ansible too | 16:21 |
| pabelanger | jeblair: okay, so I still vote for zuul.ref = null, but the downside is what tobiash mentioned: {{ zuul.ref | default('something') }} would be harder to do | 16:24 |
| SpamapS | pabelanger: I don't expect users to be modifying zuul variables. But I do expect them to use zuul variables to construct their own values. | 16:24 |
| pabelanger | jeblair: so I think that is fine, because we don't want users modifying them | 16:24 |
| pabelanger | SpamapS: ++ | 16:25 |
| SpamapS | And it's pretty clear what the meaning of |default("thing to use when it isn't there") means. | 16:25 |
| jeblair | pabelanger: also with 'null' accidentally using None.tar.gz would be easy to do. | 16:25 |
| SpamapS | does it come out as None actually? | 16:25 |
| * SpamapS hasn't really looked | 16:25 | |
| pabelanger | I think it would be ".tar.gz" | 16:26 |
| pabelanger | but agree | 16:26 |
| jeblair | i'm counting pabelanger as one vote for null and SpamapS as one vote for undefined. | 16:26 |
| jeblair | tobiash: do you have a preference? | 16:27 |
| SpamapS | null comes out to "" | 16:27 |
| pabelanger | ya, that is what I see | 16:28 |
| jeblair | so yeah, ".tar.gz" | 16:28 |
| SpamapS | versus fatal: [localhost]: FAILED! => {"failed": true, "msg": "the field 'args' has an invalid value, which appears to include a variable that is undefined. The error was: 'dict object' has no attribute 'newrev'\n\nThe error appears to have been in '/home/clint/tmp/test.yaml': line 6, column 7, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n | 16:28 |
| SpamapS | msg: \"--{{ zuul.oldrev }}--\"\n - debug:\n ^ here\n"} | 16:28 |
| SpamapS | I like things that 'splode when I'm wrong | 16:29 |
| SpamapS | except wife.. if she did that, she'd never be unexploded... ;) | 16:29 |
| pabelanger | with OPs had on, I think it will be much easier to debug things if zuul variables are always set vs dynamically added to inventory files | 16:31 |
| SpamapS | how so? | 16:32 |
| SpamapS | how will you even know you _need_ to debug | 16:32 |
| SpamapS | if it's just "" | 16:32 |
| jeblair | pabelanger: i'm not sure i'd use the word "much". maybe "a little". but it's not too much of a stretch to say "oh, there's no newrev there. the docs say it's not there under these conditions. must be one of those conditions". | 16:33 |
| tobiash | I vote for undefined as this is the way of least surprise (at least for me) as a job author expecting |default(something) to work | 16:33 |
| jeblair | that's pretty close to "hrm, newrev is null. the docs say it's null under these conditions..." | 16:33 |
| SpamapS | Right if I see a failure because of a missing variable, I go looking for that variable's definition. If I see a file being uploaded named .tar.gz, I have to find where in the code that filename is set......... | 16:34 |
| pabelanger | sure, I can understand that | 16:34 |
| pabelanger | I'll flip back to undefined then :) | 16:35 |
| *** bhavik1 has quit IRC | 16:35 | |
| tobiash | so 3 : 0 for undefined :) | 16:35 |
| SpamapS | The downside of leaving them undefined is if somebody debug prints zuul to find out what's in it, it will be variable. | 16:36 |
| pabelanger | I mean it comes down to playbook exsploding above or .tar.gz file, maybe just having the playbook break is the better way to know there is an error | 16:36 |
| SpamapS | but I think that's still more true to the data model and thus will cause less confusion. | 16:36 |
| SpamapS | pabelanger: Right, with zuul jobs especially, I think breaking is generally better than continuing in error/confusion | 16:37 |
| *** dmsimard is now known as dmsimard|afk | 16:37 | |
| SpamapS | There are definitely domains where I'd go the other way. | 16:37 |
| pabelanger | ++ | 16:38 |
| SpamapS | https://github.com/ansible/ansible/issues/27016 <-- They fixed it! :) | 16:41 |
| pabelanger | need to read up on meta | 16:43 |
| pabelanger | never seen that before | 16:43 |
| pabelanger | SpamapS: oh, nice. That is pretty cool reset_connection | 16:44 |
| pabelanger | I was trying to think of a way of laying down /etc/bashrc and having ansible restart ssh connection | 16:44 |
| pabelanger | cool | 16:44 |
| SpamapS | pabelanger: Yeah, specifically useful for that. | 16:46 |
| pabelanger | clear_facts is cool too | 16:46 |
| SpamapS | or anything else where you need to reconnect | 16:46 |
| pabelanger | a good way to purge fact cache | 16:46 |
| tobiash | pabelanger: it's new to me also, I did exactly this by killing the ssh process on the host using a paramiko connection... reset_connection could have been so much easier... | 16:47 |
| pabelanger | Ya, same | 16:47 |
| pabelanger | basically figured I had to restart sshd | 16:47 |
| pabelanger | but not now | 16:47 |
| jeblair | SpamapS: i wrote a few words on 485902 | 16:49 |
| SpamapS | jeblair: thanks! | 16:50 |
| * SpamapS will read those words | 16:50 | |
| tobiash | I also like option 3 | 16:57 |
| tobiash | What are the plans of the zuul folks regarding ptg? Just releasing zuulv3 into the wild and fixing bugs or is there also other stuff planned? | 17:02 |
| SpamapS | jeblair: and agreed on all points. I'm glad you thought of a way to not have threads waiting on every job :) | 17:02 |
| SpamapS | jeblair: I just didn't find stopJob. :-P | 17:02 |
| SpamapS | and I forgot that the condvar waits were busy spins | 17:03 |
| tobiash | Thinking about if it makes sense for me to join | 17:03 |
| SpamapS | (was thinking a bunch of threads sitting in futex() wouldn't hurt so much) | 17:04 |
| jeblair | SpamapS: yeah, my fondest dreams involve bountiful fruit, babbling brooks, and condition objects that don't spin. | 17:08 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Undefine Zuul variables in Ansible when appropriate https://review.openstack.org/486183 | 17:09 |
| jeblair | tobiash, SpamapS, pabelanger: ^ | 17:09 |
| tobiash | jeblair: in the commit message you also mention branch and tag which are not changed in the code | 17:11 |
| tobiash | jeblair: is that intentional? | 17:11 |
| jeblair | i hesitate to potentially discuss painting a different wall of the bikeshed, but... i documented the 00000 thing in there because that's what we get from gerrit and github, so we pass it through. i could be convinced that (a) we should not document it since it's just something we get from the underlying tech. or (b) that we should actually suppress it and make *our* interface to create and delete based on undefined values. that has the slight advantage ... | 17:12 |
| jeblair | ... of potentially being more compatible with potential future systems, at the cost of being something different than what people are doing now in jobs. | 17:12 |
| jeblair | tobiash: yes -- branch and tag already had the correct behavior (they only appear as attributes on objects where they are guaranteed to be set to actual values) | 17:13 |
| tobiash | jeblair: ok, +2 | 17:13 |
| jeblair | tobiash: i guess maybe i should have written the commit message differently :) | 17:13 |
| jeblair | but i did *think* about them when making the change :) | 17:13 |
| tobiash | jeblair: about the bikeshedding thing: undefining on 00000... could make it easier for the job to check for absense | 17:15 |
| pabelanger | jeblair: +2 | 17:16 |
| tobiash | (which I think is the meaning of the 0000... thing) | 17:16 |
| jeblair | tobiash: yeah, you get 0000..1234 if you create, and 1234..0000 if you delete a ref. | 17:18 |
| tobiash | jeblair: so in an ansible like interface I personally would have them undefined | 17:19 |
| jeblair | perhaps there is a reason based on git functionality that both gerrit and github use 0000.... that may be worth looking into | 17:19 |
| jeblair | tobiash: i agree | 17:19 |
| SpamapS | jeblair: it would appear py3 uses sem_wait() for it | 17:20 |
| jeblair | https://github.com/git/git/commit/f65fdf04a13d2252de8b2b4b161db7c43f2c28ad | 17:21 |
| jeblair | so yeah, 0000 does come from git. so we could change the iterface for user convenience, but i'm a little more hesitant to mask something about git than i am about gerrit/github. | 17:22 |
| tobiash | jeblair: well git itself also changes the user interface to "push origin :refs/tags/foo" | 17:23 |
| tobiash | jeblair: we might consider this as an implementation detail of git | 17:24 |
| jeblair | tobiash: i don't follow | 17:24 |
| tobiash | jeblair: the user interface in git is mainly the command line client where you don't do 'git push origin 0000:foo' | 17:24 |
| jeblair | SpamapS: do you happen to have a link to the py3 source handy? | 17:24 |
| pabelanger | tobiash: big task for PTG will be move zuulv3 into production for openstack-infra. I suspect we'll be writing a lot of ansible | 17:24 |
| jeblair | SpamapS: for condition | 17:25 |
| jeblair | tobiash: well, we're on the receiving side of the git push. so we have, in some form, received a git pack with instructions to create a tag. both gerrit and github transmit information about those instructions fairly faithfully, including the values that git supplied. | 17:28 |
| jeblair | oh here it is https://github.com/python/cpython/blob/3.6/Lib/threading.py | 17:29 |
| tobiash | jeblair: right, I'd consider this as the wire protocol where the jobs (dealing more with the git commandline client) could be seen more as the users | 17:30 |
| tobiash | jeblair: so that's the basis for my argumentation | 17:30 |
| jeblair | tobiash: yeah, makes sense. | 17:30 |
| tobiash | jeblair: but I'm also fine with the other option | 17:30 |
| SpamapS | jeblair: I do... | 17:31 |
| SpamapS | jeblair: it's pretty deep within the bowels | 17:32 |
| SpamapS | jeblair: ultimately, you end up here https://github.com/python/cpython/blob/aa0aa0492c5fffe750a26d2ab13737a1a6d7d63c/Python/thread_pthread.h#L334 | 17:32 |
| jeblair | tobiash: i do kind of want to change 0000 to undefined because i think it will be a better experience for people writing jobs who may not be, as you say, familiar with the git wire protocol. i just want to be very careful with choosing to mask something about git. making git "friendlier" could easily lead us down a long road. :) | 17:32 |
| jeblair | SpamapS: ah thanks | 17:33 |
| tobiash | jeblair: yeah it's better to think before about that :) | 17:33 |
| jeblair | tobiash: i think i'll go ahead and write a change to collect opinions | 17:34 |
| *** jkilpatr has quit IRC | 17:36 | |
| *** jkilpatr has joined #zuul | 17:40 | |
| tobiash | sounds good | 17:41 |
| SpamapS | jeblair: stracing and ltracing shows nothing happening .. just sem_wait... so maybe py3 fixed it? | 17:42 |
| SpamapS | (not that this changes what we should do, just helps us understand things) | 17:42 |
| jeblair | SpamapS: yay! yeah, i think if we don't need the extra threads we shouldn't add them. but i'm happy if python threading is better. | 17:43 |
| SpamapS | so.. I don't see the busy wait in py2 either | 17:48 |
| SpamapS | so maybe my test code isn't demonstrating the problem | 17:48 |
| jeblair | oh hrm :/ | 17:49 |
| SpamapS | http://paste.openstack.org/show/616194/ | 17:49 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Undefine Zuul variables in Ansible when appropriate https://review.openstack.org/486183 | 17:50 |
| SpamapS | user0m0.016s | 17:50 |
| SpamapS | doesn't look busywait to me :-P | 17:51 |
| jeblair | hrm, i wonder if it was event and not condition | 17:52 |
| * jeblair alters test program | 17:52 | |
| jeblair | okay, event with a timeout is a busy wait. | 17:54 |
| jeblair | (event without timeout is not busy) | 17:55 |
| jeblair | same thing for condition. | 17:55 |
| jeblair | SpamapS: so specifying a timeout for either threading or condition, in py2, causes busy wait. something like 10 hertz regardless of the length of the timeout. | 17:57 |
| jeblair | SpamapS: so specifying a timeout for either event or condition, in py2, causes busy wait. something like 10 hertz regardless of the length of the timeout. [corrected] | 17:57 |
| pabelanger | is http://pythonhosted.org/watchdog/ something we might be able to use? Python API library and shell utilities to monitor file system events. I am not sure if we can get the required info from inotify however | 17:57 |
| SpamapS | jeblair: interesting. | 17:58 |
| jeblair | SpamapS: it looks like py3 is better even with a timeout. | 18:01 |
| SpamapS | I've never actually looked at the benefits of Event vs. Condition | 18:02 |
| SpamapS | ah yeah, py3 event does not busy wait on select()'s | 18:02 |
| jeblair | SpamapS: it looks like under py3, for both events and conditions, there's no busy waiting even with a timeout. | 18:02 |
| SpamapS | \o/ | 18:02 |
| jeblair | happy days | 18:03 |
| SpamapS | but still... if we have a timeout on every job we have 3-4 threads per job.. | 18:04 |
| SpamapS | so yeah.. best to just use the stopJob | 18:04 |
| jeblair | ++ | 18:04 |
| jeblair | pabelanger: i want to say we thought about inotify but didn't think it would work. maybe clarkb recalls details. | 18:05 |
| pabelanger | maybe because: Inotify does not support recursively watching directories, meaning that a separate inotify watch must be created for every subdirectory | 18:06 |
| SpamapS | What would you inotify on? | 18:07 |
| * SpamapS lost the context, but has a lot of inotify experience. | 18:07 | |
| pabelanger | I was curious if you could caclucate the directory size with inotify over du | 18:08 |
| pabelanger | but I too am not certain | 18:08 |
| SpamapS | Not sure it would be anymore efficient. | 18:09 |
| SpamapS | du is going to walk the structure, which will all be in RAM, every second or so. | 18:10 |
| SpamapS | inotify would be cramming events in constantly. | 18:10 |
| pabelanger | true, was mostly seeing if there was an existing library to consure | 18:10 |
| SpamapS | Now, a perpetual du.. | 18:10 |
| pabelanger | also, I know I've asked before but cannot remember. What was the issue with LVM per jobdir? | 18:10 |
| SpamapS | that doesn't fork.. just loops on du'ing.. would be a tad more efficient. | 18:11 |
| SpamapS | LVM would need root to manage. | 18:11 |
| SpamapS | Or setuid helpers | 18:11 |
| pabelanger | right, that would be it | 18:11 |
| SpamapS | complicates deploying executors in containers | 18:11 |
| SpamapS | lots of stuff ;) | 18:11 |
| SpamapS | bwrap might have done the latter though | 18:11 |
| SpamapS | (though it's supposed to work without privileges, I think that takes newer kernels) | 18:11 |
| pabelanger | oh, nice | 18:12 |
| SpamapS | I think this is the lightest weight thing we can do by ourselves.. | 18:13 |
| SpamapS | and then we can look at teaching nodepool to talk to container schedulers which might make "run playbooks on a 'node'" a real thing. | 18:13 |
| SpamapS | One could make an argument that with bubblewrap running on scaled out executors, zuul _is_ a container scheduler though ;) | 18:14 |
| pabelanger | schedulers all the way down! | 18:15 |
| pabelanger | jeblair: okay to restart zuulv3 to pick up 486183? | 18:18 |
| jeblair | pabelanger: please! | 18:20 |
| pabelanger | zuulv3.o.o restarted | 18:22 |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul feature/zuulv3: DNM - multinode testing https://review.openstack.org/486195 | 18:39 |
| *** jkilpatr has quit IRC | 18:47 | |
| *** jkilpatr has joined #zuul | 18:50 | |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul-jobs master: invert add-build-sshkey logic https://review.openstack.org/486203 | 19:00 |
| pabelanger | jeblair: how do I go about testing the base-test playbook in project-config? | 19:02 |
| pabelanger | https://review.openstack.org/#/c/486199/ for example | 19:02 |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul-jobs master: DNM - invert add-build-sshkey logic https://review.openstack.org/486203 | 19:08 |
| pabelanger | I guess something like | 19:08 |
| tobiash | pabelanger: commented on ^ right before there was an update | 19:09 |
| pabelanger | tobiash: right, i thought about that, but we'd have to do it for all command. I think the better option is just to run that role on localhost, rather then having all hosts include it | 19:11 |
| pabelanger | https://review.openstack.org/#/c/486199/ for example | 19:12 |
| pabelanger | tobiash: you can see the current issue with https://review.openstack.org/#/c/486195/ | 19:13 |
| pabelanger | group-inventory test | 19:13 |
| tobiash | pabelanger: yea, saw it already | 19:14 |
| tobiash | pabelanger: will this delegate to all but localhost work even if the playbook is running against localhost? | 19:14 |
| pabelanger | I think it should | 19:15 |
| pabelanger | but want to test | 19:15 |
| pabelanger | I'm not sure !localhost is needed, since all doesn't apply to it | 19:15 |
| pabelanger | but added it to be safe | 19:15 |
| tobiash | pabelanger: I still think the more expected behavior from a user point of view is to run against all nodes and restrict key generation (and agent stuff) to localhost with once | 19:15 |
| pabelanger | right, this would do the same thing, just invert the logic | 19:16 |
| pabelanger | all nodes really only need to get new authoized file | 19:16 |
| pabelanger | not tell localhost to run the command | 19:16 |
| tobiash | pabelanger: yes, but would be more less surprising if you just run the role from an different playbook | 19:17 |
| pabelanger | well, add-build-sshkey right now is only usable in a trusted playbook, because of delegate_to bits. | 19:19 |
| pabelanger | removing delete_to localhost means we could start to use this playbook in untrusted jobs, if somebody wanted too | 19:19 |
| pabelanger | but, I'd like to experiment with it first and see how it preforms, and currently means we need to land project-config change | 19:21 |
| tobiash | pabelanger: sure | 19:22 |
| *** amoralej is now known as amoralej|off | 19:26 | |
| tobiash | jeblair: wasn't there a change that every job inherits from base if not specified? I'm not sure but I think I read something about this topic here some time ago. | 19:30 |
| tobiash | hrm, don't find it, I've probably wrong memory about this | 19:33 |
| *** dmsimard|afk is now known as dmsimard | 19:35 | |
| jeblair | tobiash: story 2001110 not yet implemented | 19:36 |
| pabelanger | tobiash: here is some code I use today which is similar: http://git.openstack.org/cgit/openstack/windmill/tree/playbooks/bastion.yaml it should almost be the same | 19:37 |
| tobiash | pabelanger: ah, so you treat localhost as bastion host then | 19:38 |
| tobiash | jeblair: ah there it was | 19:38 |
| pabelanger | tobiash: yup, I wrote most of that code with zuulv3 in mind! So, my logic for bastion will likely be removed when added as zuulv3 job | 19:39 |
| *** hasharDinner is now known as hashar | 19:56 | |
| *** jkilpatr has quit IRC | 20:03 | |
| jeblair | pabelanger: i don't think we have a general restriction on delegating to localhost | 20:05 |
| jeblair | (in untrusted playbooks) | 20:05 |
| jeblair | in an untrusted playbook, you can run some stat and file commands on localhost, but that's it. | 20:06 |
| jeblair | pabelanger: i don't think inverting the ssh playbook logic would change any of that. | 20:07 |
| jeblair | pabelanger: to put that another way, it's not the "delegate_to" option, that's a problem, it's "run a command on localhost" that's the problem. | 20:07 |
| pabelanger | jeblair: right, but ATM, you wouldn't be able to use the role to say setup ssh between 2 multinodes (if you wanted that for some reason). But in this case, I do think it make more sense to limit that role to localhost only via a playbook | 20:10 |
| pabelanger | we'd have to add run_once to all the delegate_to: localhost tasks | 20:11 |
| jeblair | pabelanger: all we need to do for that is to copy the private key to the remote node. | 20:11 |
| pabelanger | jeblair: we also ssh-add -D | 20:12 |
| pabelanger | so, there would be a race between 2 nodes | 20:12 |
| pabelanger | and both would do that step | 20:12 |
| jeblair | pabelanger: we could add it to this role, but i think it might be best to do it in its own role. in that case, it's just one task to be run on all the nodes. | 20:12 |
| jeblair | pabelanger: i don't understand what "ssh-add -D" has to do with inter-node ssh | 20:12 |
| pabelanger | let me get a log of the problem and pastebin it | 20:13 |
| jeblair | (the reason i think setting up the private key on remote nodes should be its own role is so that the base job remains safe to run on long-running nodes) | 20:14 |
| pabelanger | right now, we only want add-build-sshkey role to be run once, across all nodes, but that doesn't happen | 20:15 |
| pabelanger | http://zuulv3.openstack.org/static/stream.html?uuid=330519b1ee974d91a1330e772a5d979c&logfile=console.log | 20:15 |
| jeblair | pabelanger: well, yes, i understand that. | 20:15 |
| jeblair | i've read your patches and commented on them. | 20:15 |
| pabelanger | okay, but I believe you are saying we do not need run_once for ssh -D commands too? | 20:16 |
| jeblair | pabelanger: nope never said that. we'll need run_once for all the delegate_to: localhost commands. | 20:16 |
| pabelanger | okay, that clears things up a little. | 20:17 |
| pabelanger | however, that is more ansible code in our playbooks. If we inverted, it would be less | 20:18 |
| jeblair | i don't think lines of code is always the best measure of clarity | 20:18 |
| pabelanger | sure, I just find it more ackward this way. Let me get patch | 20:19 |
| jeblair | pabelanger: there's a very simple test to apply here. who should control the set of hosts the key gets installed on? the playbook author or the role author? | 20:20 |
| pabelanger | I would say playbook | 20:20 |
| jeblair | pabelanger: then i think that suggests we should stick with the current structure and fix it with run_once | 20:21 |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul-jobs master: Only run once our delegate_to locahost commands https://review.openstack.org/486217 | 20:23 |
| pabelanger | jeblair: sure, there are 2 ways to do it. We can keep going on this route. | 20:23 |
| jeblair | ^+2 | 20:25 |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul-jobs master: Fix stat check for add-build-sshkey https://review.openstack.org/486219 | 20:29 |
| pabelanger | jeblair: ^ also fixes a typo which should help prevent the issue | 20:29 |
| jeblair | pabelanger: oh, i wonder if we should just merge that instead? | 20:30 |
| pabelanger | ya, either / both likely work | 20:30 |
| pabelanger | dealers choice! | 20:30 |
| jeblair | pabelanger: what's the "failed_when: false" supposed to do? | 20:31 |
| jeblair | maybe that was expected to cause zuul_temp_ssh_key_stat to be undefined... | 20:31 |
| pabelanger | ya, think that is right | 20:32 |
| jeblair | oh, is the logic just backwards? | 20:32 |
| pabelanger | I wonder if we don't need it. need to do a quick test if we stat an file that does exist | 20:33 |
| jeblair | oh, hrm, it looks like "failed_when: false" might tell ansible never to consider this task failed | 20:34 |
| pabelanger | ya, stat on not existing file works | 20:35 |
| pabelanger | stat.exist == false | 20:35 |
| pabelanger | so, not sure why we need that logic | 20:35 |
| jeblair | okay so i think your patch is good | 20:36 |
| pabelanger | we should check if zuul_temp_ssh_key variable is define and not none | 20:36 |
| pabelanger | to avoid it being empty | 20:36 |
| jeblair | isn't it in the defaults file? | 20:36 |
| pabelanger | yup, so we are protected a little | 20:37 |
| jeblair | pabelanger: i merged 219. let's try it out. :) | 20:37 |
| pabelanger | k | 20:37 |
| jeblair | well, it's in the queue at least | 20:37 |
| pabelanger | want me to rebase? | 20:37 |
| jeblair | pabelanger: oh it depends on the other one | 20:37 |
| jeblair | pabelanger: yeah | 20:38 |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul-jobs master: Fix stat check for add-build-sshkey https://review.openstack.org/486219 | 20:38 |
| openstackgerrit | Merged openstack-infra/zuul-jobs master: Fix stat check for add-build-sshkey https://review.openstack.org/486219 | 20:40 |
| pabelanger | I still think we might have a little race condition | 20:42 |
| pabelanger | Ya, because we don't have stragegy free | 20:43 |
| pabelanger | so both hosts will run the task at the same time | 20:43 |
| pabelanger | so, we also need run_once | 20:43 |
| pabelanger | or add run_once to the file check | 20:43 |
| pabelanger | Yup, failed | 20:44 |
| pabelanger | jeblair: so we also need 486217 | 20:44 |
| jeblair | neat | 20:45 |
| openstackgerrit | Merged openstack-infra/zuul-jobs master: Only run once our delegate_to locahost commands https://review.openstack.org/486217 | 20:46 |
| SpamapS | ah derp.. abandoned while I was reviewing. ;) | 20:46 |
| SpamapS | that will serve me right for reviewing before finishing reading backscroll | 20:46 |
| jeblair | SpamapS: was your review "i think we should use run_once" by any chance? | 20:48 |
| SpamapS | no | 20:50 |
| SpamapS | I am super confused by the whole thing | 20:50 |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul feature/zuulv3: DNM - multinode testing! https://review.openstack.org/486195 | 20:50 |
| SpamapS | args: { creates: "{{ zuul_temp_ssh_key }}" } | 20:50 |
| SpamapS | would have been my attempted solution | 20:50 |
| pabelanger | ssh -d would then have been the next issue | 20:50 |
| SpamapS | run_once for that would work | 20:50 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove refspec https://review.openstack.org/485875 | 20:51 |
| pabelanger | right, there is multiple ways to fix it | 20:51 |
| SpamapS | but even then, I think just some clever fail handling | 20:51 |
| SpamapS | let the "key is already gone" be a non-fail | 20:51 |
| *** jkilpatr has joined #zuul | 20:52 | |
| pabelanger | why do we log [Zuul] Log Stream did not terminate in the console.log? | 20:53 |
| jeblair | pabelanger: i don't think we've fixed the underlying bug which causes us to spuriously emit that yet. once we do, i think that would be handy to have in the log. :) | 20:55 |
| jeblair | (because it should never happen unless things are going wrong) | 20:55 |
| pabelanger | jeblair: okay, so we should be stopping zuul_stream between plays? | 20:56 |
| jeblair | pabelanger: yes. that's currently only happening when nothing is being sent | 20:58 |
| pabelanger | ack, thanks | 20:58 |
| pabelanger | so, we have a little issue with tox log publishing over multi nodes | 20:59 |
| pabelanger | both are attempting to rsync in the same directory | 20:59 |
| pabelanger | like we might need to create a new subdir for each node | 20:59 |
| pabelanger | let me see if I can get that working | 21:00 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Use undefined values instead of 40 zeroes https://review.openstack.org/486225 | 21:01 |
| SpamapS | Ali baba and the 40 zeroes... | 21:01 |
| tobiash | jeblair: I think I observed this stream did not terminate on shell tasks with ansible parse errors (e.g. undefined variables) | 21:04 |
| jeblair | okay, that's our bikeshed from this morning up for color selection. I'm in no rush to land that one. | 21:04 |
| jeblair | tobiash: those would also probably produce no output on the stream i guess? | 21:05 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul feature/zuulv3: Fix broken project config in dynamic config test https://review.openstack.org/486226 | 21:05 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul feature/zuulv3: Don't ignore inexistent jobs in dynamic config https://review.openstack.org/486227 | 21:05 |
| tobiash | jeblair: yes, these produce just an ansible error | 21:05 |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul-jobs master: Store tox logs by inventory_hostname https://review.openstack.org/486228 | 21:07 |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul feature/zuulv3: DNM - multinode testing https://review.openstack.org/486195 | 21:08 |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul-jobs master: Support multi node jobs for tox logs https://review.openstack.org/486228 | 21:23 |
| *** _ari_ is now known as _ari_|gone | 21:33 | |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul-jobs master: Support multi node jobs for tox logs https://review.openstack.org/486228 | 21:36 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove refspec https://review.openstack.org/485875 | 21:40 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_REFNAME https://review.openstack.org/486232 | 21:43 |
| pabelanger | cool, multinode logs working | 21:44 |
| pabelanger | http://logs.openstack.org/95/486195/3/check/group-inventory/9279283/ | 21:44 |
| pabelanger | http://logs.openstack.org/28/486228/3/check/tox-linters/ab40fa7/ for single node jobs | 21:45 |
| pabelanger | not sure if we want to dynamically change tox folder or not | 21:45 |
| pabelanger | jeblair: mordred: SpamapS: tobiash: would love some feedback on: review.openstack.org/486228 | 21:46 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_OLDREV and ZUUL_NEWREV https://review.openstack.org/486233 | 21:49 |
| tobiash | pabelanger: +2 with comment | 21:52 |
| * tobiash has eod now | 21:54 | |
| pabelanger | tobiash: thanks, replied | 21:55 |
| pabelanger | have a good weekend | 21:55 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_COMMIT https://review.openstack.org/486235 | 21:55 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_REF https://review.openstack.org/486236 | 21:55 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_PATCHSET https://review.openstack.org/486240 | 22:13 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_CHANGE https://review.openstack.org/486241 | 22:13 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Fix the rendering of item entries https://review.openstack.org/486242 | 22:13 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_CHANGE_IDS https://review.openstack.org/486243 | 22:13 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_CHANGES https://review.openstack.org/486245 | 22:25 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_BRANCH https://review.openstack.org/486246 | 22:25 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_VOTING and add zuul.voting https://review.openstack.org/486247 | 22:25 |
| *** hashar has quit IRC | 22:27 | |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_URL https://review.openstack.org/486249 | 22:32 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_PIPELINE https://review.openstack.org/486250 | 22:32 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_PROJECT https://review.openstack.org/486251 | 22:32 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_UUID https://review.openstack.org/486252 | 22:32 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_CHANGE_IDS https://review.openstack.org/486243 | 22:38 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_CHANGES https://review.openstack.org/486245 | 22:38 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_VOTING and add zuul.voting https://review.openstack.org/486247 | 22:38 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_BRANCH https://review.openstack.org/486246 | 22:38 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_URL https://review.openstack.org/486249 | 22:38 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_PROJECT https://review.openstack.org/486251 | 22:38 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_PIPELINE https://review.openstack.org/486250 | 22:38 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_UUID https://review.openstack.org/486252 | 22:38 |
| pabelanger | Hmm, I am not seeing any post-run info in job-output.json, is that to be expected? | 22:48 |
| pabelanger | actually, looks like it is just post-logs that I do not see | 22:48 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_VOTING and add zuul.voting https://review.openstack.org/486247 | 23:04 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_URL https://review.openstack.org/486249 | 23:04 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_PROJECT https://review.openstack.org/486251 | 23:04 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_PIPELINE https://review.openstack.org/486250 | 23:04 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove ZUUL_UUID https://review.openstack.org/486252 | 23:04 |
| jeblair | pabelanger: i think that makes sense -- the json file is only updated at the end of the play, so necessarily the last one will be missing entirely | 23:05 |
| jeblair | pabelanger: (unlike the text log, where we at least get the lines up to the point where the upload happens) | 23:05 |
| pabelanger | jeblair: okay | 23:08 |
| pabelanger | I'm trying to find the best way to get our jobdir.root from an ansible playbook, and haven't been able to find something I like | 23:09 |
| jeblair | pabelanger: what do you need it for? | 23:10 |
| pabelanger | jeblair: I was looking to rework http://git.openstack.org/cgit/openstack-infra/zuul-jobs/tree/roles/validate-host/tasks/main.yaml#n16 in favor of just publishing the infro directly from fact-cache. Kinda like we do with inventory_file | 23:12 |
| pabelanger | not a major issue atm | 23:12 |
| jeblair | pabelanger: how do we copy the inventory file now? | 23:13 |
| pabelanger | jeblair: from localhost playbook using the {{ inventory_file }} magic variable | 23:14 |
| pabelanger | thats returns the path | 23:14 |
| jeblair | pabelanger: is there a {{ fact_cache }} magic variable? :) | 23:14 |
| pabelanger | no :( | 23:14 |
| pabelanger | was looking at source code | 23:14 |
| pabelanger | if I knew the location of ansible.cfg, I could use the lookup function | 23:15 |
| jeblair | pabelanger: isn't the fact cache json? | 23:15 |
| pabelanger | jeblair: ya, that is true | 23:16 |
| jeblair | pabelanger: so we'd be doing about as much processing as we're doing now | 23:16 |
| pabelanger | ya | 23:16 |
| pabelanger | okay, so not much to change then | 23:16 |
| pabelanger | okay, think I am done for the week | 23:17 |
| pabelanger | enjoy weekend | 23:18 |
| openstackgerrit | Merged openstack-infra/zuul-jobs master: Remove gather_facts: true https://review.openstack.org/485834 | 23:18 |
| openstackgerrit | Merged openstack-infra/zuul-jobs master: Remove validate-host from unittests/pre.yaml https://review.openstack.org/485836 | 23:19 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Use undefined values instead of 40 zeroes https://review.openstack.org/486225 | 23:19 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Log skipped tasks to the job output https://review.openstack.org/485896 | 23:29 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!