| jamielennox | jeblair: re variants, i agree i don't want everything global. In repo will stop the v2 job name spread, but i would say that applying extra selectors to a single project is exactly the reason i would expect that the same job name can be specified multiple times within a project job list as multiple jobs, rather than refinements of the first | 00:00 |
|---|---|---|
| jamielennox | but i'm more interested in the second point | 00:00 |
| jamielennox | "implied project variants are the only way to modify a job defined in another project" | 00:01 |
| jamielennox | i'm not sure I understand why this is something we would want | 00:01 |
| * jamielennox has some cycles to spare if someone wants to point me at a task | 00:07 | |
| jamielennox | dont want to add much more to that github stack until some merges | 00:08 |
| jeblair | jamielennox: you can use the same job multiple times in a project so that you can say "run devstack on trusty on the stable branch; run devstack on xenial on the master branch". it isn't really intended to run the same job multiple times with different content -- that's different jobs. to go back to your example "tox" isn't sufficiently descriptive for a job. if you say to a user "the tox job succeeded" the next question is "which tox job?", ... | 01:00 |
| jeblair | ... so "tox-py27" and "tox-py35" are more useful job names. | 01:00 |
| jamielennox | jeblair: but job.name there is the unique component, so i can't just change that to describe a new job | 01:02 |
| jamielennox | although i guess i can via parent: instead of name: | 01:02 |
| jeblair | jamielennox: right, i think in your example, tox-py27 with 'parent: tox' makes sense -- you can even use the same playbook and just have it use a job variable for the environment selection. | 01:03 |
| jamielennox | i didn't intend to turn this into a multi-day debate, just something i wasn't expecting to be caught by | 01:03 |
| jamielennox | yea, so i think it'd be useful to catch and raise validation error if you have the same job.name defined multiple times in a project section | 01:04 |
| jeblair | jamielennox: heh, with folks at summit and folks not, everything is multi-day. it's worth working through this :) and hopefully our standard library will have really good examples for people to follow. | 01:05 |
| jamielennox | i can't think of any valid case why people would do that instead of define it all in one job section and it was a surprise | 01:05 |
| jeblair | jamielennox: (yes -- though only if they have the same selectors; i do still think we need to be able to have project-specific selectors, which means they have to be able to appear more than once, but just with different selection criteria) | 01:06 |
| jeblair | next week i think we'll be ready to start working on standard lib / shared jobs in earnest | 01:06 |
| jamielennox | jeblair: ok, so that's what i'm not sure about with the selectors - and i don't know if i can still access my old commit | 01:09 |
| jamielennox | but to me {{ tox_env_name }} would be a distinguishing selector | 01:09 |
| jeblair | jamielennox: by selector, i mean something that decides whether the job should run. for instance, a branch selector. so if a job shows up more than once, it should look like: "[{devstack: {branch: stable, nodes: trusty}}, {devstack: {branch: master, nodes: xenial}}]". so only one of those gets run. | 01:11 |
| jamielennox | jeblair: yea, ok | 01:13 |
| jamielennox | so yea, i'm happy with a validation error for now so that if this becomes a bigger problem in future we can do something about it and non break backwards compatibility | 01:14 |
| jeblair | jamielennox: yeah, i think this is going to work well most of the time, but we probably need to make sure that either via docs, examples, config comments, etc, we convey some of these concepts | 01:15 |
| jamielennox | jeblair: i assume it's rather late and you don't want to get into a conversation about tenant backends? | 01:17 |
| jeblair | jamielennox: yeah, i need to retire for the evening | 01:18 |
| jamielennox | jeblair: no worries, in the meantime though do you have anything on the v3 path needing picked up? | 01:19 |
| jamielennox | i don't want to grow that github tree any further | 01:20 |
| pabelanger | o/ | 01:22 |
| * SpamapS has been making good progress on py3 in-flight | 01:35 | |
| SpamapS | a few of the suites even pass | 01:35 |
| SpamapS | going to be quite a few patches though | 01:36 |
| SpamapS | in fact most of my problems are now in zk and mysql I think | 01:37 |
| SpamapS | jamielennox: you can grab anything unassigned in https://storyboard.openstack.org/#!/board/41 | 01:42 |
| SpamapS | Todo is the more important stuff | 01:42 |
| jamielennox | SpamapS: i was actually looking for that again cause i couldn't find my bookmark | 01:43 |
| jamielennox | turning up at storyboard.openstack.org and trying to find that is not intuitive | 01:43 |
| SpamapS | nope it's pretty hard to find there ;) | 01:44 |
| pabelanger | I am learning that a dict.values() returns a view in python3, not a list | 01:54 |
| pabelanger | now we get to do list(dict.values()) | 01:54 |
| SpamapS | pabelanger: correct | 02:03 |
| SpamapS | quite a few of those in my patch stream | 02:04 |
| SpamapS | we do a lot of foo.values()[0] in zuul | 02:04 |
| pabelanger | SpamapS: Ah, I have been doing list(dict.values) because we actually check to see isinstance list | 02:05 |
| SpamapS | that's sometimes needed too | 02:05 |
| SpamapS | a few places we return .values() from a method and it's more appropriate to return a list. | 02:06 |
| SpamapS | pabelanger: I'm pretty close to having tox -epy35 return 0 | 02:11 |
| SpamapS | with a lot of skips | 02:11 |
| SpamapS | and depending on gear.Text* which is effectively going to be ggear0.8 I think | 02:11 |
| pabelanger | cool, I hope to continue with nodepool tomorrow | 02:12 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Ensure zookeeper_servers is a list https://review.openstack.org/463880 | 02:12 |
| pabelanger | I think that is all I will do this evening | 02:12 |
| SpamapS | It would be great if we can get them gated on py3 soon so the websocket stuff can land | 02:12 |
| *** Cibo has quit IRC | 02:26 | |
| *** jamielennox has quit IRC | 04:34 | |
| *** jamielennox has joined #zuul | 04:34 | |
| * SpamapS has a py3k patch bomb | 04:41 | |
| SpamapS | that passes tox -epy35 | 04:41 |
| SpamapS | (skipping a few really hard ones for py3) | 04:41 |
| SpamapS | INCOMING | 04:45 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: Use gear Text interface https://review.openstack.org/461468 | 04:46 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: Copy dirs to handle __pycache__ in py3 https://review.openstack.org/463890 | 04:46 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: fix imports in py3 https://review.openstack.org/463891 | 04:46 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: py3 Changes in __del__ for gitpython https://review.openstack.org/463892 | 04:46 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: hashlib error https://review.openstack.org/463893 | 04:46 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: make Job and ZuulRole hashable https://review.openstack.org/463894 | 04:46 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: None does not compare to int https://review.openstack.org/463895 | 04:46 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: Fixes for test_model in py3 https://review.openstack.org/463896 | 04:46 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: writing yaml to disk needs bytes https://review.openstack.org/463897 | 04:46 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: view changes for py3 https://review.openstack.org/463898 | 04:46 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: Encoding changes in tests for py3 https://review.openstack.org/463899 | 04:46 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: base64 changes for py3 https://review.openstack.org/463900 | 04:46 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: misc py3 changes https://review.openstack.org/463901 | 04:46 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: fix webapp tests for py3 https://review.openstack.org/463902 | 04:46 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: skip py3 failing tests https://review.openstack.org/463903 | 04:46 |
| SpamapS | jeblair: if you want that squashed ^^ I'd understand. :) | 04:46 |
| SpamapS | figured this allows topical reviewer load | 04:46 |
| *** bhavik1 has joined #zuul | 06:50 | |
| *** DangerousDaren has joined #zuul | 07:39 | |
| *** hashar has joined #zuul | 08:29 | |
| *** isaacb has joined #zuul | 08:52 | |
| *** smyers has quit IRC | 09:04 | |
| *** hashar has quit IRC | 09:07 | |
| *** Cibo has joined #zuul | 09:08 | |
| *** smyers has joined #zuul | 09:15 | |
| *** Cibo has quit IRC | 09:17 | |
| *** Cibo has joined #zuul | 09:27 | |
| *** Cibo has quit IRC | 11:05 | |
| *** bhavik1 has quit IRC | 11:15 | |
| *** jkilpatr has joined #zuul | 12:09 | |
| *** jkilpatr has quit IRC | 12:41 | |
| *** patrickeast has quit IRC | 12:43 | |
| *** patrickeast has joined #zuul | 12:43 | |
| dmsimard | pabelanger: should I create something in storyboard for nodepool boot from volume ? | 12:55 |
| *** dkranz_ has quit IRC | 13:15 | |
| pabelanger | dmsimard: I'd like to find jeblair this morning and chat about it | 13:30 |
| dmsimard | pabelanger: ok | 13:30 |
| *** zaro has quit IRC | 13:38 | |
| *** zaro has joined #zuul | 13:39 | |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Sort flavors with operator.itemgetter('ram') https://review.openstack.org/463998 | 13:58 |
| pabelanger | Shrews: ^ I am open to suggests for sorting flavors :) I managed to look to mordred and shade for some hints | 13:58 |
| jeblair | pabelanger, mordred, Shrews, SpamapS, jamielennox, jlk, fungi, clarkb: i won't be able to attend monday's zuul meeting; do others want to have it or should we cancel it? | 14:01 |
| clarkb | I can go either way. Monday is looking like expense report day for me | 14:04 |
| pabelanger | no objection to skipping | 14:04 |
| *** yolanda has quit IRC | 14:14 | |
| *** yolanda has joined #zuul | 14:16 | |
| *** dkranz_ has joined #zuul | 14:21 | |
| fungi | i'm in favor of skipping. i _could_ make it but expect to be pretty burned out monday | 14:33 |
| jeblair | SpamapS: py3k stack reviewed; couple of comments, mostly +2s. thanks! | 14:47 |
| *** isaacb has quit IRC | 14:56 | |
| pabelanger | nodepool.tests.test_launcher.TestLauncher.test_lost_requests appears to be flapping | 15:13 |
| *** isaacb has joined #zuul | 15:16 | |
| mordred | pabelanger: maybe we should just shift nodepool to using the method that shade has | 15:32 |
| mordred | pabelanger: I'll try to make a patch tomorrow | 15:32 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Ensure zookeeper_servers is a list https://review.openstack.org/463880 | 15:34 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Sort flavors with operator.itemgetter('ram') https://review.openstack.org/463998 | 15:34 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Replace dict.iteritems() with dict.items() for python3 https://review.openstack.org/464026 | 15:34 |
| pabelanger | mordred: danke | 15:34 |
| jlk | jeblair: I won't likely make it if there were a meeting. | 15:36 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Update exception message handling for python3 https://review.openstack.org/464034 | 15:59 |
| SpamapS | jeblair: \o/ thanks! | 16:06 |
| * SpamapS +1's cancelling monday zuul meeting | 16:07 | |
| *** isaacb has quit IRC | 16:09 | |
| jeblair | jlk: i've left a few more more reviews on the github stack | 16:13 |
| *** jkilpatr has joined #zuul | 16:18 | |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Switch to next(generator) for python3 https://review.openstack.org/464040 | 16:22 |
| * jlk sits down, cracks nuckels, and prepares to read Jim's reviews. | 16:29 | |
| SpamapS | jeblair: heh, one more attribute needed text'ing on gear. :-P | 16:30 |
| * SpamapS adds exception | 16:30 | |
| jlk | jeblair: if you're okay with all the URLs changing with v3, then I could see doing away with status_urL_with_change config entry and always putting the change in the status URL. | 16:42 |
| jlk | although... I'm not so sure the gerrit driver makes use of status_url | 16:42 |
| jlk | jeblair: I think you removed it in 60af7f42d0cd24539c8d408a73a7bdbe6ce6e485 | 16:44 |
| openstackgerrit | David Shrewsbury proposed openstack-infra/zuul feature/zuulv3: WIP: Add web-based console log streaming https://review.openstack.org/463353 | 16:44 |
| Shrews | flake8 seems to have suddenly developed an aversion to async code | 16:44 |
| *** Cibo_ has joined #zuul | 16:51 | |
| *** jkilpatr has quit IRC | 16:55 | |
| SpamapS | Shrews: it realized the futility of python | 16:56 |
| Shrews | hrm, it seemed to start complaining when i changed to the 3.5 asyncio style | 16:57 |
| jlk | hrm, anybody here familiar with the jquery.zuul.js file willing to lend me a hand? | 16:59 |
| Shrews | and pep8/flake8 are pinned in g-r | 16:59 |
| Shrews | grrr | 16:59 |
| Shrews | but zuul isn't beholden to g-r, right? | 17:00 |
| Shrews | so now i'm not sure where zuul gets its versions of those from, b/c the latest certainly aren't being installed | 17:02 |
| Shrews | oh, from hacking | 17:10 |
| Shrews | well poo | 17:10 |
| *** DangerousDaren has quit IRC | 17:12 | |
| SpamapS | woot, 4 more tests enabled by fixing flake8 problems | 17:14 |
| Shrews | jeblair, mordred: well, it seems 'hacking' does not yet support py 3.5, but it is a goal for pike (https://governance.openstack.org/tc/goals/pike/python35.html). So I guess I'm going to have to go back to the pre-3.5 version of asyncio syntax. :( | 17:22 |
| jesusaur | jlk: oh, that removal of status_url kinda changes how we want to handle the github status link | 17:22 |
| jlk | yeah | 17:22 |
| SpamapS | hrm | 17:23 |
| jlk | I'm now looking at the pipeline start-message config, which is right in the pipeline | 17:23 |
| jlk | but... given that end users can define their own pipelines, that gets .... weird. | 17:23 |
| SpamapS | playing with py3 brings up an interesting question about whether or not to try and enable binary secrets. pretty sure right now if somebody encrypts a binary private key it will explode. | 17:23 |
| SpamapS | (since we're all JSON based and JSON can't really handle non-utf8) | 17:25 |
| clarkb | Shrews: or just dont use hacking? | 17:25 |
| clarkb | Shrews: we explicitly ignore all hacking rules anyways so its jjst a simple install linters thing | 17:26 |
| Shrews | clarkb: well, that's a possibility of course. | 17:26 |
| clarkb | but we can install directly instead without losing anything | 17:26 |
| Shrews | seems like a good discussion for the zuul meeting that we are not having :) | 17:27 |
| jesusaur | jlk: yeah, my change originally added support for status_url in the pipeline and fall back to the old status_url in zuul.conf, but maybe now what we want is a pipeline-level success-url? | 17:28 |
| * jesusaur needs to re-learn the config paths | 17:28 | |
| SpamapS | jeblair: any thoughts on binary secrets? I think at this point we're going to have to have people hand them to us base64 encoded, but we might be able to retool our internal json message passing to do that for everything and then we can take small binary blobs as secrets. | 17:29 |
| jlk | well, we could probably re-use the pipeline level start-message as the URL. But the problem I see with any pipeline level thing is that pipelines are now usable by more than one connection | 17:30 |
| jlk | jesusaur: pipeline level configs cover the whole pipeline, but what we'd really want is connection level settings for this, since the URL could differ per-connection? Dunno. Maybe not. | 17:30 |
| jlk | actually probably not since they'd all come back to zuul in some way | 17:31 |
| jesusaur | would it be too ugly to add a github-status-url setting to the pipeline, which only gets used in the context of a github connection? | 17:32 |
| jesusaur | hm, but then again there's the issue of users possibly making their own pipelines, which gets weird | 17:33 |
| jlk | I think this is the same quandary that jamielennox was having | 17:34 |
| jlk | it does feel like we need something more centrally configured for this | 17:34 |
| jesusaur | it seems to me like it should be a connection-level setting | 17:35 |
| jlk | so perhaps in the [connection] block we add a status_url | 17:35 |
| jlk | at least for github driver | 17:35 |
| jlk | we get self.driver and self.connection as reporter attributes | 17:36 |
| SpamapS | users making their own pipelines? can you elaborate? | 17:37 |
| SpamapS | pipelines are only in config repos | 17:37 |
| jlk | ah | 17:37 |
| jlk | what all can be loaded from a untrusted-projects ? | 17:38 |
| jlk | So we could do this as a connection level setting in our config, or a pipeline level setting | 17:40 |
| jlk | one is more "DRY" than the other | 17:40 |
| SpamapS | job and project configs | 17:41 |
| SpamapS | you can load what jobs to run, and make jobs parented on existing jobs | 17:41 |
| SpamapS | incoming rebase | 17:42 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: skip py3 failing tests https://review.openstack.org/463903 | 17:42 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: fix webapp tests for py3 https://review.openstack.org/463902 | 17:42 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: misc py3 changes https://review.openstack.org/463901 | 17:42 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: base64 changes for py3 https://review.openstack.org/463900 | 17:42 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: Encoding changes in tests for py3 https://review.openstack.org/463899 | 17:42 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: view changes for py3 https://review.openstack.org/463898 | 17:42 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: writing yaml to disk needs bytes https://review.openstack.org/463897 | 17:42 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: Fixes for test_model in py3 https://review.openstack.org/463896 | 17:42 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: Use gear Text interface https://review.openstack.org/461468 | 17:42 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: None does not compare to int https://review.openstack.org/463895 | 17:42 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: make Job and ZuulRole hashable https://review.openstack.org/463894 | 17:42 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: py3 hashlib error https://review.openstack.org/463893 | 17:42 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: py3 Changes in __del__ for gitpython https://review.openstack.org/463892 | 17:42 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: fix imports in py3 https://review.openstack.org/463891 | 17:42 |
| openstackgerrit | Clint 'SpamapS' Byrum proposed openstack-infra/zuul feature/zuulv3: Explicitly decode decrypted secrets for py3 https://review.openstack.org/464049 | 17:42 |
| SpamapS | now only 10 tests disabled for py3 | 17:42 |
| jlk | SpamapS: so we're trying to find a home for a configuration of what URL to put in the github status body we send up at start/success/failure. | 17:43 |
| jlk | SpamapS: it used to be based on status_url in zuul config, but that got dropped in v3 | 17:43 |
| jlk | seemingly dropped in favor of pipeline.start_message | 17:43 |
| SpamapS | ahh | 17:43 |
| SpamapS | so it's unstructured now | 17:43 |
| SpamapS | feels like a thing that would be in zuul config really | 17:44 |
| SpamapS | when would it differ per-pipeline or per-connection? | 17:44 |
| jlk | that's what I'm trying to think through | 17:44 |
| jlk | for _our_ needs, we point back to the zuul status engine, with change identifiers so that the status page can show something. | 17:46 |
| jlk | or later, we point to our logs host to show the logs dump | 17:46 |
| jlk | eventually we may point to a page that will stream the jobs/logs, a la Travis | 17:46 |
| jlk | but I am not being imaginative enough to think through when it would differ on a single pipeline per connection, or differ across all the pipelines at all. | 17:47 |
| SpamapS | yeah | 17:48 |
| SpamapS | I think it goes in zuul's conf file | 17:48 |
| jlk | that seems to tie reporter back to scheduler, which jeblair was trying to undo | 17:49 |
| jlk | re 60af7f42d0cd24539c8d408a73a7bdbe6ce6e485 | 17:50 |
| jlk | well sorry I take that back | 17:50 |
| jlk | If we put it in the [connection] block then we have ready access to it without having to go through self.sched.config.get, it'd be in self.connection.connection_config.get | 17:51 |
| jlk | I'm not sure if that semantic is enough for jim or not | 17:51 |
| SpamapS | nor I, but it feels silly to have something that is site-specific be duplicated on every connection. That said, how many github connections will there be? ;-) | 17:52 |
| jlk | depends on if we want to support multiple GHEs with a single Zuul backend | 17:52 |
| *** Cibo_ has quit IRC | 17:54 | |
| jlk | I think I'm going to comment in the change and move on. | 17:56 |
| * SpamapS is trying to shake off the "we're so close" feeling that the last 36 hours of py3 hacking has produced | 17:57 | |
| jlk | haha | 17:57 |
| * jeblair catches up | 18:37 | |
| jeblair | SpamapS: re binary secrets -- maybe we should treat *all* secrets as binary | 18:37 |
| jeblair | SpamapS: zuul deosn't care what they are, so we never actually need to decode them | 18:38 |
| SpamapS | jeblair: right, but we do have to put them into ansible's vars. | 18:38 |
| SpamapS | which implies json and thus can't be binary | 18:38 |
| jeblair | SpamapS: json or yaml? | 18:39 |
| SpamapS | that's a great question | 18:39 |
| SpamapS | json is used internally | 18:39 |
| SpamapS | but we get to yaml things | 18:39 |
| SpamapS | and I don't know how or if yaml handles binary data | 18:39 |
| jeblair | SpamapS: if we're using pyyaml to write ansible vars files, it should dtrt (which is, in the case of binary data, do an automatic base64 thing) | 18:40 |
| jeblair | SpamapS: so i think the work would mostly be to make sure that we treat them all as binary internally in zuul, and make sure that makes it across the json bridge between scheduler and executor correctly | 18:41 |
| SpamapS | interesting.. | 18:41 |
| SpamapS | python3 happily dumps binary data into yaml | 18:41 |
| SpamapS | er | 18:41 |
| SpamapS | python2 | 18:41 |
| jlk | erm | 18:41 |
| jlk | wait | 18:41 |
| jlk | You can put base64 things into ansible vars | 18:42 |
| SpamapS | !!binary | | 18:42 |
| openstack | SpamapS: Error: "!binary" is not a valid command. | 18:42 |
| SpamapS | f0VMRgIBAQAAAAAAAAAAAAIAPgABAAAAsCVAAAAAAABAAAAAAAAAADDEAAAAAAAAAAAAAEAAOAAJ | 18:42 |
| SpamapS | yaml does it like that | 18:42 |
| jeblair | yeah that's the thing :) | 18:42 |
| jlk | in fact, there is Ansible filters for going in/out of base64 | 18:42 |
| SpamapS | but then i thought modules read json | 18:42 |
| jlk | {{ foo|b64decode }} | 18:43 |
| * SpamapS pokes at this with a stick | 18:43 | |
| jlk | SpamapS: you'd probably decode it on the way _into_ the module. | 18:43 |
| jlk | module: | 18:43 |
| jlk | arg_that_is_secret: "{{ secret_var|b64decode }}" | 18:43 |
| jeblair | (i'll try to catch up on the status url thing, but it will take me a minute) | 18:44 |
| jlk | I digested into a review comment for you | 18:45 |
| SpamapS | jlk: Yeah I'm looking at how this mechanically works now | 18:45 |
| jlk | oooh hey, with ANsible 2.3 you can now have a single encrypted variable in an otherwise unencrypted YAML file | 18:47 |
| jeblair | jlk: oh thanks... going to read | 18:48 |
| SpamapS | does not work well | 18:49 |
| SpamapS | http://paste.openstack.org/show/609390/ | 18:49 |
| SpamapS | that playbook, with a binary fed in via a yaml file, produces the text representation | 18:50 |
| SpamapS | as in, the file has b'\x00...' in it | 18:50 |
| jlk | oh so when you do content: that gets double processed | 18:50 |
| jlk | so it's... weird | 18:50 |
| jlk | so you may need to go ahead and re |b64encode it | 18:50 |
| SpamapS | eh, no | 18:52 |
| SpamapS | the data in the variable is real binary data | 18:52 |
| SpamapS | not b64 encoded | 18:52 |
| jlk | oh. hrm. | 18:52 |
| jlk | I think... | 18:52 |
| SpamapS | I bet this doesn't work | 18:52 |
| jlk | I think you have to b64 encode it don't you? | 18:52 |
| SpamapS | yep | 18:52 |
| SpamapS | b64 encode it inside playbook, so feeding it to module works | 18:53 |
| jlk | I meant get it b64 encoded in the yaml. | 18:53 |
| SpamapS | and then there's probably some kind of "don't do that" in ansible docs | 18:53 |
| SpamapS | Realistically our target here is passwords and OAUTH-style tokens | 18:54 |
| jlk | https://github.com/ansible/ansible/issues/13794 | 18:54 |
| jlk | also relevant https://github.com/ansible/ansible-modules-extras/pull/142 | 18:56 |
| SpamapS | yeah | 18:56 |
| SpamapS | wow, old pull | 18:58 |
| jlk | heh | 18:58 |
| jlk | looks like later they just added the ability for the copy module to copy around vaulted files | 18:58 |
| SpamapS | UGH | 18:59 |
| SpamapS | vault is super lame :( | 18:59 |
| SpamapS | that's fairly disappointing | 18:59 |
| jlk | could be worse, could be Barbican | 18:59 |
| SpamapS | If it was Hashicorp vault, yay | 18:59 |
| SpamapS | but it's ansible vault | 18:59 |
| SpamapS | which is meh | 18:59 |
| jeblair | well, we're not looking at using vault right now, right? all we want to do is put some (not secret from ansible's pov) data in a vars file | 19:00 |
| SpamapS | I think what we may need to do is have two types | 19:01 |
| SpamapS | something to tell zuul to base64 encode it when putting it in the variables | 19:01 |
| jlk | Are we writing a tool for people to use to encrypt the data? | 19:01 |
| SpamapS | jlk: yeah | 19:01 |
| jlk | question | 19:01 |
| jlk | could we not _always_ base64 encode the data then? | 19:02 |
| jeblair | SpamapS: howe about if you want the secret base64 encoded, you base64 encode it. | 19:02 |
| jlk | is there a downside to base64 encoding non-binary content, so long as the decode works on the other side? | 19:02 |
| SpamapS | jeblair: I'm fine with that, but it severely limits the key size we can store in our current size limited PKCS container | 19:02 |
| SpamapS | I think it might even preclude 1024bit keys | 19:03 |
| SpamapS | but I could be wrong | 19:03 |
| * SpamapS didn't do the math | 19:03 | |
| jeblair | SpamapS: okay, so what's wrong with splatting the binary data into the vars file? | 19:04 |
| SpamapS | jeblair: does not work, due to issue 13794 noted above, in ansible | 19:04 |
| SpamapS | they'll utf-8 encode the binary data | 19:04 |
| SpamapS | (confirmed here on my laptop) | 19:04 |
| jeblair | how would you use ansible to write an ssh private key file? | 19:06 |
| SpamapS | base64 encode it, decode on the other end. | 19:06 |
| jlk | You can copy it | 19:06 |
| jlk | you'd use the copy module without using the 'content' method of that module | 19:06 |
| SpamapS | or yeah if you have it as a file | 19:06 |
| jlk | our problem is that we're trying to pass it through variables | 19:07 |
| SpamapS | the problem really is there's no way to access vars without jinja' | 19:07 |
| jeblair | so there's no way to pass binary data into ansible as a variable and have that end up in a file | 19:07 |
| jlk | straight binary, I don't think so | 19:07 |
| jeblair | switching hats for a second: yowza that is... something we do *all the time* in puppet :( | 19:08 |
| SpamapS | yeah I think it's pretty broken that it's not possible | 19:08 |
| jlk | we could be missing something, opening a convo in #ansible-devel | 19:08 |
| jeblair | (still with infra hat on (not zuul): i guess you could write a module to do that) | 19:09 |
| jlk | yeah, that module got rejected | 19:10 |
| jlk | and looking to try an dmake the copy module's content method have a "handle binary" way of operating seemed to fall over. | 19:10 |
| jlk | SEEMS like it's a jinja2 limitation | 19:10 |
| SpamapS | pretty sure modules receive their input as json | 19:11 |
| SpamapS | so this may just be impossible if there's nothing in that json interface that automatically b64's | 19:11 |
| jeblair | SpamapS: assuming jlk doesn't come back with new magic, i think you are right, we may need a zuul-internal workaround :( | 19:12 |
| jeblair | jlk, jesusaur: replied on 446782 | 19:19 |
| SpamapS | jeblair: might be worth pushing it forward in parallel in ansible | 19:19 |
| jeblair | SpamapS: ++ | 19:19 |
| SpamapS | jeblair: that would make me feel better about a janky internal workaround | 19:19 |
| SpamapS | a plugin might get it done | 19:21 |
| jlk | question | 19:26 |
| jlk | We're reading the user's yaml file to find the secrets and decode them | 19:26 |
| jlk | then we expose them as a variable ourselves | 19:27 |
| jlk | couldn't we, at the point of decyrpting them, take the step to base64 encode them, so that Ansible will be able to handle them more easily? | 19:27 |
| SpamapS | yeah I think that may actually be the way to go | 19:28 |
| jeblair | but optional, right? since "mypassword" is not something that should necessarily be base64 encoded when passed to ansible | 19:28 |
| SpamapS | I think we could just base64 encode the value _if_ it won't utf8 decode | 19:28 |
| SpamapS | which is a bit janky | 19:28 |
| jlk | well | 19:29 |
| jlk | I think it's like "the price of using this mechanism" | 19:29 |
| jlk | it's much easier to tell a user that everything encrypted will be base64 encoded | 19:29 |
| jeblair | SpamapS: well, i think the playbooks need to know which to expect, so a binary string that accidentally utf8 encodes would surprise the user | 19:29 |
| jlk | kind of like how everything slurped will be base64 encoded | 19:29 |
| jlk | http://docs.ansible.com/ansible/slurp_module.html | 19:29 |
| jeblair | jlk: but then we are placing extra requirements on top of what one would normally expect in a playbook... | 19:30 |
| SpamapS | jeblair: there's literally no way to get that binary string into their ansible except base64 encoded. | 19:30 |
| SpamapS | oh | 19:30 |
| SpamapS | n/m | 19:30 |
| jeblair | jlk: iow, an openstack playbook that expected plain-text username/password creds would not work | 19:30 |
| SpamapS | I read your assertion backwards | 19:30 |
| SpamapS | jeblair: yeah that's a very good point | 19:30 |
| jlk | hrm. | 19:30 |
| jlk | I see what you mean | 19:30 |
| SpamapS | so what if we make secrets vars always have a _b64 variant | 19:30 |
| SpamapS | the non _b64 variant of truly binary data will be bonghits | 19:31 |
| jlk | I think that still fails | 19:31 |
| SpamapS | it will be double-utf8-encoded | 19:32 |
| jlk | because the variable _name_ would change based on context (CI or not, encrypted or not) | 19:32 |
| jlk | so running your playbook outside of CI would be awkward | 19:32 |
| jeblair | we could do something like that for the secret name in zuul though (maybe that's what SpamapS meant?) | 19:32 |
| jlk | maybe I took the objection too far | 19:33 |
| jlk | do we expect that the variable name doesn't change inside of zuul? | 19:33 |
| jeblair | secret: name: foo; .... auth: secret: foo / auth: secret: foo_64 | 19:33 |
| jeblair | er, my suggestion has the problem of applying the transformation to all the elements of a secret (which is a collection of variables). that's probably not desirable. | 19:34 |
| jlk | so with vault, if your file is decrypted or encrypted the variable names do not change | 19:34 |
| jlk | and the variable values do not change | 19:34 |
| jeblair | i wonder if the !!secret data type might be the best place to put the switch | 19:35 |
| jeblair | nope, that's not good either | 19:35 |
| jlk | which makes it somewhat convenient to run the playbooks in multiple locations | 19:35 |
| jlk | is what we are designing working the same? | 19:35 |
| SpamapS | it will cost very little to go ahead and feed every secret in twice, once as a utf-8 string (convenient but possibly corrupted) and once as a base64 encoded version (larger, requires decoding, but always exactly what you encrypted) | 19:35 |
| jeblair | jlk: yeah, when you say "secret: foo: bar" you get an ansible variable named "foo" with content var | 19:35 |
| SpamapS | it will be a bit painful to discover this | 19:36 |
| jeblair | SpamapS: though that impinges on the way a user would write a playbook | 19:36 |
| SpamapS | jeblair: I feel that ansible impinges on the way a user would write a playbook that needs binary variables | 19:36 |
| jeblair | :) | 19:37 |
| jlk | jeblair: hrm, I think that means replicating outside of zuul is hard, because something else will have to make that variable name shift of "secret.foo.bar" to just "foo.bar" | 19:37 |
| jeblair | jlk: i may not follow. i was trying to say that we're trying to pass through names unmunged. | 19:38 |
| jlk | I feel like we'd better serve our users if they could run the playbook with an unencrypted vars file the same way it would be ran inside zuul encrypted | 19:38 |
| jeblair | jlk: that is the intent, and i think that's the case. | 19:38 |
| jlk | so "secret: foo: bar" goes in the project or job or pipeline def? | 19:38 |
| SpamapS | I think thus far I would prefer one of thse two: 1) all decrypted things are passed as base64 encoded values 2) all decrypted things are passed as a string, and a _b64 base64 encoded version. | 19:39 |
| * jlk should go read the spec | 19:39 | |
| jeblair | jlk: a secret is a top level config object, and is then referenced in a job. oh, i do think we include the secret name in the variable name. so i may have answered your question wrong, sorry. | 19:40 |
| jeblair | SpamapS: i have a third option | 19:41 |
| jlk | either of you have a link to the spec? | 19:41 |
| jeblair | it's just the zuulv3 spec | 19:41 |
| jeblair | SpamapS: https://etherpad.openstack.org/p/OodXAsk1oM | 19:42 |
| jeblair | SpamapS: we have a 'data' field in the secret object. we can add 'base64-data' to indicate that the fields within there should be written to ansible vars file as base64 | 19:43 |
| jeblair | so that's an extra flag we can just pass all the way through to the executor and it can do what's appropriate when it writes it | 19:43 |
| SpamapS | jeblair: feels less magical and more predictable than my ideas. :) | 19:44 |
| SpamapS | and less annoying than (1) | 19:44 |
| jlk | so the spec assumes that the secrets are defined within the zuul yaml file, with their encrypted data there directly | 19:45 |
| jlk | and if a user wants to test locally, they'd have to write out their own vars file with the unencrypted data, in a hash that matches what zuul would provide | 19:46 |
| jeblair | jlk: i'm open to changing the variable naming scheme. i think i agree with you on that; i worry about collisions being more likely, but maybe that's outweighed by your point. | 19:46 |
| jlk | what if there was a radically different approach? | 19:47 |
| jlk | maybe this was already thought through | 19:47 |
| pabelanger | ohai | 19:47 |
| jlk | but model it slightly more like valut | 19:47 |
| jlk | vault. | 19:47 |
| jlk | The secrets for a repo get put into a vars YAML file. That file can be wholly encrypted by our tool, and decrypted by Zuul | 19:48 |
| jlk | one-shot encrypt/decrypt of the whole thing | 19:48 |
| SpamapS | jlk: I think that's pretty simple to build into the encryption tool | 19:48 |
| jlk | then ansible is ran with -e secrets-file.yaml | 19:48 |
| SpamapS | but you can't decrypt what's in there | 19:48 |
| SpamapS | it's encrypted to US | 19:49 |
| jlk | in this model, the variable structure never changes, it's just stored in-repo encrypted. | 19:49 |
| jlk | SpamapS: I think that's fine | 19:49 |
| jlk | because locally you'd have the shadow un-encrypted version | 19:49 |
| jlk | update it locally, run the encrypter, commit the result | 19:49 |
| jlk | git ignore the unencrypted one | 19:49 |
| SpamapS | right, that's pretty much how it works now | 19:50 |
| jlk | but yeah I see how that's a problem (like with vault) in that you can't easily see the variable names | 19:50 |
| jlk | well | 19:50 |
| SpamapS | though it would be nice to basically just run zuul-encrypt-secrets -e @vars.yaml --encrypt-var password and have it just edit .zuul.yaml | 19:50 |
| jlk | in my model, the end user decides what format to use in the YAML | 19:50 |
| jlk | be it binary, base64, whatever | 19:50 |
| jlk | what goes in is exactly what they expect on the other side | 19:51 |
| jlk | because we would encrypt the _file_ rather than trying to parse, encrypt, decrypt, re-create the same structure. | 19:51 |
| SpamapS | jlk: I see your point | 19:51 |
| jeblair | jlk: jobs need to request secrets though, which means we still need a zuul named data structure | 19:51 |
| jeblair | so we're doing double entry across files | 19:51 |
| SpamapS | however, we will more quickly run afoul of the size limitations if we start encryptiong base 64 strings and not actual binary blobs. | 19:52 |
| jlk | do jobs need to request _specific_ secrets, or just access to secrets at all? | 19:52 |
| jeblair | jlk: specific | 19:52 |
| jlk | okay, that throws a wrench into my model | 19:52 |
| jlk | do we have use cases for such granular exposure? | 19:53 |
| jeblair | jlk: dropping the excess hierarchy may be the simplest thing (it makes the hand-created vars file more obvious) | 19:53 |
| SpamapS | cncf-demo-aws cncf-demo-azure ? | 19:53 |
| jeblair | jlk: yes, should be in the spec, lemme look | 19:53 |
| jlk | still trying to understand | 19:55 |
| jlk | a job can only request a secret that's defined in teh same repo | 19:55 |
| jlk | so presumably you've got control of both (the repo and the job, thus the secret too) | 19:55 |
| jlk | is specific secret exposure a feature to reduce an attack surface of something? | 19:56 |
| SpamapS | yes, we don't want secrets to be exposed to untrusted playbooks :) | 19:56 |
| jeblair | jlk: hrm, i don't see that called out in the spec. at any rate, we might have a lot of secrets in a trusted repo, yet have varying levels of trust of the jobs in that repo. we might have a job we trust with gerrit creds but not pypi creds. we need the jobs to request only the secrets they need so we're not exposing them unecessarily. | 19:56 |
| SpamapS | jlk: not sure what case you're making? | 19:56 |
| jlk | oh I think I get it now | 19:57 |
| jlk | the code you're calling from the job shouldn't necessarily have access to every secret in the repo. | 19:57 |
| jeblair | right | 19:57 |
| jeblair | i have to move my biological containment vessel to another location now | 19:57 |
| jlk | even though the same human controls the repo, has access to all the secrets, and wrote the job | 19:57 |
| SpamapS | we might put more sensitive secrets on a different node type | 19:58 |
| SpamapS | yeah I have to get some lunch | 19:58 |
| jlk | yeah, I could see doing separate files for each level of secrets | 19:58 |
| jlk | but that's forcing things into my model, for less good reasons | 19:58 |
| jlk | (job could request which _file_ of secrets, and only those files would be decrypted) | 19:59 |
| jlk | basically what I'm trying to find is a good way for humans without the existence of zuul to easily run the playbooks | 19:59 |
| jlk | to replicate what CI is doing for debugging purposes | 19:59 |
| SpamapS | jlk: it's also worth noting that you can have job-only roles that coerce the secrets into the variables that are in your unencrypted version with set_fact... | 19:59 |
| SpamapS | include a set of tasks for that when: local_thing is undefined and zuul.secret.thing is defined | 20:00 |
| SpamapS | I do think it's a good idea to make the conversion from local-unencrypted to .zuul.yml really smooth | 20:00 |
| jlk | We could probably make that a feature of the encryption too | 20:01 |
| jlk | tool | 20:01 |
| * SpamapS cracks his knuckles with his own ruler for using .yml | 20:01 | |
| SpamapS | ok... screen break | 20:01 |
| jlk | so running it locally just @unencrypted.yaml and you'll have the same variable names | 20:01 |
| jlk | same, lunch | 20:02 |
| jeblair | SpamapS, jlk: if you think about yaml file manipulation, you may want to look at the existing encrypt-secrets.py in zuul/tools and especially system-config/tools/hieraedit.py | 20:11 |
| *** jkilpatr has joined #zuul | 20:27 | |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: WIP: debug test_lost_request failures https://review.openstack.org/464075 | 20:27 |
| jeblair | i'm probably going to be mostly unavailable until about wednesday | 20:27 |
| *** hashar has joined #zuul | 20:28 | |
| pabelanger | jeblair: I promise not to write any craxy playbooks | 20:29 |
| pabelanger | crazy* | 20:29 |
| Shrews | pabelanger: we need to wait for the image before starting the launcher (for the flapping test) | 20:34 |
| Shrews | http://logs.openstack.org/40/464040/1/check/nodepool-coverage-ubuntu-xenial/755b1ff/console.html#_2017-05-11_16_29_53_904794 | 20:35 |
| Shrews | so we have a race on the builder getting the image ready, and the launcher making sure there are images there to satisfy the request | 20:35 |
| Shrews | funny we are only now seeing that | 20:36 |
| pabelanger | Shrews: That is what I think too. For now, I added waitfornodes() to see how that worked, but maybe we need waitforimages() too? | 20:36 |
| Shrews | pabelanger: waitfornodes is too late in the process | 20:36 |
| pabelanger | Shrews: yes, that is what I thought | 20:36 |
| pabelanger | so, let me see about adding waitforimage check | 20:37 |
| Shrews | we need to not do pool.start() *until* waitforimage returns | 20:37 |
| pabelanger | k | 20:37 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Add waitForImage to test_lost_request https://review.openstack.org/464075 | 20:40 |
| pabelanger | Shrews: ^ right? | 20:40 |
| pabelanger | I'll stack my py3 changes on that too, | 20:43 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Rename nodepool.py to launcher.py https://review.openstack.org/463807 | 20:45 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Ensure zookeeper_servers is a list https://review.openstack.org/463880 | 20:46 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Use six.moves.urllib for python3 compat https://review.openstack.org/463595 | 20:46 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Update exception message handling for python3 https://review.openstack.org/464034 | 20:46 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Sort flavors with operator.itemgetter('ram') https://review.openstack.org/463998 | 20:46 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Use raise Exception for python3 https://review.openstack.org/463594 | 20:46 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Replace dict.iteritems() with dict.items() for python3 https://review.openstack.org/464026 | 20:46 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Switch to next(generator) for python3 https://review.openstack.org/464040 | 20:46 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Fix imports for python3 https://review.openstack.org/463808 | 20:46 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Remove FakeFile from fakeprovider.py https://review.openstack.org/463587 | 20:46 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: Python 3.x incompatible use of print operator https://review.openstack.org/463586 | 20:46 |
| pabelanger | looks like nodepool.tests.test_commands.TestNodepoolCMD.test_delete_now is a little flappy too | 20:55 |
| pabelanger | http://logs.openstack.org/95/463595/4/check/nodepool-coverage-ubuntu-xenial/63d6712/console.html#_2017-05-11_20_51_05_908868 | 20:55 |
| *** dkranz_ has quit IRC | 20:59 | |
| pabelanger | best I can tell, zk.getNode() is returning no data | 21:18 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool feature/zuulv3: DNM - TestNodepoolCMD.test_delete_now failure https://review.openstack.org/464083 | 21:25 |
| *** hashar has quit IRC | 21:35 | |
| jlk | (bringing convo here) jamielennox what was it you were saying that needed to be tenant specific for the URL we were talking about? | 21:50 |
| jesusaur | jlk: i think he was saying it was the webapp (which aiui is primarily the status.json endpoint, and not the whole js app) | 21:55 |
| jesusaur | jlk: so thinking about this a little more, i guess we want to be able to set two different urls: we want to point at the zuul webapp when the status is 'pending' and then we want to point at the logs host when the status is either 'success' or 'failure' | 22:02 |
| jesusaur | does that seem right? | 22:02 |
| jlk | for now, for us, yes. Eventually for us I suspect we'll point to a single URL, and that single URL will be a webapp that can show the status of the job and click throughs for live logs as the jobs start | 22:03 |
| SpamapS | jlk: I kind of want that app to be status.json++ | 22:07 |
| SpamapS | There's nothing Bonny specific about any of that. | 22:08 |
| SpamapS | or github specific | 22:08 |
| jlk | sure, depends on if we want our own branding skin on it though | 22:08 |
| jlk | (this is the Horizon problem) | 22:08 |
| jamielennox | jlk: mostly i was wondering if we wanted to make things per-pipeline | 22:08 |
| jamielennox | SpamapS: i expect zuul will publish a status.json (or something) that we would render independantly | 22:09 |
| jlk | I couldn't come up with a good reason, but that doesn't mean a good reason isn't out there | 22:09 |
| jamielennox | i would happily expose whatever visualization that zuul has, but it wouldn't be the "Bonny" interface | 22:09 |
| SpamapS | so... | 22:10 |
| SpamapS | I'd prefer that we focus our dev on Zuul's webapp | 22:10 |
| SpamapS | Skinning it so people know they're looking at us is indeed something I'd want to do. | 22:11 |
| jesusaur | jamielennox: i think thats how the current status.json works, the 'webapp' just exposes a json blob, and then that gets read and rendered by the js in zuul/etc/status/public_html | 22:11 |
| SpamapS | But log streaming, links to PR's, general overview, all things in Zuul now. | 22:11 |
| SpamapS | so given that, I think there's basically one value: what's the URL base to find the zuul webapp? And then secondary to that is "where did we stuff logs?" | 22:12 |
| SpamapS | We had a discussion yesterday about possibly having zuul read a JSON file from the job's work directory that could have artifact/log paths in it, and feed that to any jobs depending on this one. | 22:13 |
| SpamapS | (an in-person discussion) | 22:13 |
| jesusaur | and maybe rather than try to figure out how to add the logs url as a status_url, we should try to add the logs url to the js that renders the status? | 22:14 |
| jamielennox | so zuul will do streaming of job results and such, but it's not (AFAIK) ever looking to provide you like a nice web gui | 22:14 |
| jamielennox | so it would be nice to have more concept of buildset handling (though maybe that's just a reporter) | 22:15 |
| jamielennox | but what we need for github is still that url that represents a buildset, rather than an individual build that zuul is set up for now | 22:16 |
| jlk | Style question: | 22:16 |
| jlk | http://paste.openstack.org/show/609396/ | 22:17 |
| Shrews | pabelanger: yes, that looks correct. the delete flap is a known thing and is a race within kazoo itself. we're kind of hoping to try out using kazoo read locks to prevent that, if we can ever get the change merged into kazoo | 22:21 |
| jlk | nobody wants a bike shed opportunity? :) | 22:25 |
| SpamapS | jlk: I like to pass my None's through to where they can do the most damage if unhandled ;) | 22:26 |
| jlk | hah, thankfully format() is pretty chill about them | 22:26 |
| jlk | ed = 'foo {something} bar {jerk}' | 22:26 |
| jlk | In [17]: ed.format(something='derp', jerk=foo.get('baz')) | 22:27 |
| jlk | Out[17]: 'foo derp bar None' | 22:27 |
| SpamapS | jlk: I count that as "the most damage" | 22:27 |
| jlk | any of you familiar with how the status json filters work? | 22:33 |
| *** jamielennox is now known as jamielennox|away | 22:42 | |
| *** harlowja has quit IRC | 22:57 | |
| *** harlowja has joined #zuul | 22:57 | |
| *** jamielennox|away is now known as jamielennox | 23:22 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!