=== FourDollars_ is now known as FourDollars === marcoceppi_ is now known as marcoceppi === plars-holiday is now known as plars === cprov_ is now known as cprov === Guest53163 is now known as zz_Guest53163 === psivaa-afk is now known as psivaa === Makyo is now known as Guest57414 === JoseeAntonioR is now known as jose === zz_Guest53163 is now known as CyberJacob === CyberJacob is now known as Guest23029 === Guest23029 is now known as CyberJacob === ahasenac` is now known as ahasenack [11:31] marcoceppi, hey - is it possible to re-trigger the review queue tests for https://code.launchpad.net/~cjwatson/charms/trusty/ubuntu-repository-cache/xz-indexes/+merge/277880 ? [11:31] cjwatson asked me to look on Friday, but the test failures had been dropped due to archiving of older results I think === verterok` is now known as verterok [13:19] jamespage: restarted, but the results do disappear after a few days, but they are premenantly recorded here: http://reports.vapour.ws/charm-test-details/charm-bundle-test-parent-3650 [13:21] jamespage: it looks like the tests need to be fixed to use the better format of amulet.sentry['service'][0] instead of hard-coding '/0' [13:51] marcoceppi, [13:51] ack [14:10] marcoceppi: Is all-machines.log or equivalent available anymore from CI runs? I can't see a link to them any more. [14:27] stub: they should be [14:27] stub: where are you looking? [14:28] arosales, marcoceppi: hey guys, wanted to check everything was going good wrt tasks? [14:48] marcoceppi: http://review.juju.solutions/review/2370 - just a link to jenkins logs [14:51] stub: yes, this is a known deficiency. THe results still get logged to the vapour.ws site [14:52] stub: http://reports.vapour.ws/all-bundle-and-charm-results/cassandra [14:52] http://reports.vapour.ws/charm-test-details/charm-bundle-test-parent-3785 [15:00] marcoceppi: ahh, ta. === Makyo is now known as Guest54187 === kwmonroe_ is now known as kwmonroe [16:00] hey juju folks :) what's a good way to get the last X lines of log from a unit? juju ssh $UNIT_ID sudo cat /var/log/juju/unit-$UNIT_TAG.log feels kludgy, and juju debug-log -i $UNIT_ID --limit=100 -n 100 can block if there are less than 100 lines in the log file :( [16:21] charmers: any advice on these failure? http://juju-ci.vapour.ws:8080/job/charm-bundle-test-lxc/1534/console from http://review.juju.solutions/review/2357 I recall something about broken test env on that day. If no advice, can you please rerun those tests, assuming env is fixed? [16:37] reactive question: where do I put my layer's unit tests, and do I run them in the layer, or in the built charm? [16:38] bloodearnest: unit tests belong in the unit_tests directory in the layer, and should be runnable by both the layer and the built charm for completeness [16:39] jrwren: i queued another test on lxc [16:39] lazypower, right. Is there a standard place to put test dependencies in the layer? [16:40] bloodearnest: so far i've seen a lot of use of tox to isolate all that in a venv [16:41] lazypower, right, that's what I would do for a normal charm. Unsure about how different layers would combine the setup/running of their unit_tests in the built charm [16:42] yeah, the files being overriden by the top layer that generates the built charm will be the holder of any overriden files [16:42] lazypower, where will /unit_tests/* end up in the built charm dir structure? [16:42] that dir will, yes [16:42] but if there is say a /unit_tests/01-thing.py in both layers [16:42] the top most layer will override the 01-thing.py in the lower layer [16:42] right [16:47] bloodearnest - might also be worth the effort to ping the list with that question, and shake out some outliers that have thought but haven't asked yet [16:47] tvansteenburgh: thanks. [16:49] lazypower, by default, I assume charm build will merge all non-special directories in the final output? [16:50] where special I guess = reactive, maybe hooks? [16:54] bloodearnest, when merging, it still overwrites unless its metadata.yaml or config.yaml [16:57] lazypower, ack [17:22] marcoceppi: ping re: PSA [17:23] jose: yes [17:23] marcoceppi: is there currently a list of charms that are holding that hardcoded pattern? if so, is it public? I'd like to go in and fix some of those if possible [17:23] or do some MPs [17:24] not yet, we may be producing one for work with code-in [17:24] oh awesome [20:16] kwmonroe: sorry pal, i thought you had it [20:16] no worries asanjar -- i was building myself out of sparktc github.. pre-built bins are fine by me! [20:47] jrwren: almost http://reports.vapour.ws/charm-test-details/charm-bundle-test-parent-3834 [20:48] tvansteenburgh: thanks for the notice. *grumble* at it failing still :) [21:17] so for actions.yaml the example schema https://jujucharms.com/docs/1.25/authors-charm-actions shows the use of compression.type=gzip, how does juju know that those properties are mapped to kind and quality? [21:18] and what is the format for defining both the compression kind and quality, is it compession.type=gzip,0? [21:41] stokachu: that's example fail [21:42] stokachu: it should be compression.kind=gzip in the example [21:51] marcoceppi: ah! [21:51] now that makes sense [21:52] Hey, so I have a proposal for charm layers that I'd like to get feedback on. [21:52] cory_fu: shoot [21:53] We'd been recommending base, runtime, etc. layers use yaml files for config options. But this could lead to a lot of small yaml files with various names. So I was thinking instead we could have an "options" section in layer.yaml [21:54] So you'd have layer.yaml contain: includes: ['layer:apache-php']; options: apache: packages: [...] [21:54] cory_fu: oh, I like that, then what every key under option would be automatically prefixed? [21:54] Instead of having a separate apache.yaml [21:54] created a PR https://github.com/juju/docs/pull/751 for that doc fix [21:54] Automatically prefixed? [21:55] cory_fu: well, my thought was layers that presented options would provide jsonschema in them so that it'd be explicit [21:56] ie, apache-php layer would define the schema which it supported [21:56] * marcoceppi strawmans [21:56] That sounds intriguing. What would that look like? [21:57] Charm-tools could do the validation, then, at build time, too [21:57] cory_fu: right [21:59] heres my ghost charm using the latest wheelhouse support https://jujucharms.com/u/adam-stokes/ghost/trusty/8 [21:59] bleh, the apache-php layer doesn't quite fit the mold, but almost done [21:59] went from 334 files to 72 \o/ [21:59] cory_fu: give me 10 min, otp [22:00] though im not sure why the revisions aren't being updated to match what is in bzr [22:29] marcoceppi: Still otp? [22:29] yes [22:29] kk [22:31] stokachu: Revisions on jujucharms.com don't match bzr revisions because the charm revision tracks number of times ingested, which happens at periodic intervals and could include many bzr revs [22:32] Once we have `juju publish`, the charm revs will make a lot more sense, since it will track how many times you ran `juju publish` [22:52] cory_fu: https://gist.github.com/marcoceppi/ca36655cb917b16d0681 [22:52] something like that? [22:53] cory_fu: actually, just updated it [22:56] marcoceppi: I like that a lot [22:56] I also like that Alot [22:56] I hug Alot [22:57] cory_fu: the "parent" key would just be the layer name. I'm not sure how this would work for the sites key other than make sites an open-ended object [22:57] and maybe replace "provides" with "defines" as provides is used in the charm ecosystem [22:57] best not to conflate the two === bladernr` is now known as bladernr [22:57] Agreed on the last bit [22:57] ERROR error checking if provisioned: subprocess encountered error code 1 <- is there any way to get debug info on the subprocess failure ? [22:58] jsonschema doesn't have support for validated lists? [22:58] cory_fu: no idea [22:58] cory_fu: apparently it does [23:00] cory_fu: since we already use jsonschema for actions.yaml it'd be great to keep that pattern going with this and maybe convince core that config.yaml should move to it as well ;) [23:00] Agreed [23:00] cory_fu: either way, I like the idea. It gives better visibility into the layer and provides a build time lint for validation, +1 [23:07] marcoceppi: Can you point me to an example of how jsonschema is used to use definitions in actions.yaml to validate params (or a similar example)? [23:08] cory_fu: you mean the golang libraries, or how it looks as an implementation? [23:08] How it looks as an implementation [23:08] cory_fu: the apache-plugin charm would be a good start ;) [23:09] Specifically, I'm wondering how the action.yaml contents are used as / injected into a schema [23:09] cory_fu: they are the schema, each parent item defines a params and that params is the schema [23:09] we'd remove the parent key (action name) and just have a schema, more or less what's in the gist [23:10] cory_fu: O [23:10] cory_fu: I'd imagine this would come into play eventuall, https://pypi.python.org/pypi/jsonschema but maybe I'm not understanding the question [23:11] So, looking at the example in that last link, the contents of "properties" is what we'd be filling in, right? [23:11] cory_fu: no, not quite [23:11] So I guess we can just wrap it in {'type': 'object', 'properties': schema} [23:12] cory_fu: ah ok [23:12] cory_fu: let me try to produce a quick py example [23:16] marcoceppi: Alas, I have to run, but send me the pastebin when you have it done. I think I'm seeing it now, but I'm not certain [23:37] cory_fu: I wrote my thoughts at the bottom of the gist: https://gist.github.com/marcoceppi/ad318d081e3b30857819 [23:40] cory_fu: if you'd like I can open an issue on charm-tools to discuss further