[11:31] <jamespage> 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] <jamespage> cjwatson asked me to look on Friday, but the test failures had been dropped due to archiving of older results I think
[13:19] <marcoceppi> 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] <marcoceppi> 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] <jamespage> marcoceppi,
[13:51] <jamespage> ack
[14:10] <stub> marcoceppi: Is all-machines.log or equivalent available anymore from CI runs? I can't see a link to them any more.
[14:27] <marcoceppi> stub: they should be
[14:27] <marcoceppi> stub: where are you looking?
[14:28] <jose> arosales, marcoceppi: hey guys, wanted to check everything was going good wrt tasks?
[14:48] <stub> marcoceppi: http://review.juju.solutions/review/2370 - just a link to jenkins logs
[14:51] <marcoceppi> stub: yes, this is a known deficiency. THe results still get logged to the vapour.ws site
[14:52] <marcoceppi> stub: http://reports.vapour.ws/all-bundle-and-charm-results/cassandra
[14:52] <marcoceppi> http://reports.vapour.ws/charm-test-details/charm-bundle-test-parent-3785
[15:00] <stub> marcoceppi: ahh, ta.
[16:00] <roadmr> 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] <jrwren> 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] <bloodearnest> 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] <lazypower> 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] <tvansteenburgh> jrwren: i queued another test on lxc
[16:39] <bloodearnest> lazypower, right. Is there a standard place to put test dependencies in the layer?
[16:40] <lazypower> bloodearnest: so far i've seen a lot of use of tox to isolate all that in a venv
[16:41] <bloodearnest> 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] <lazypower> yeah, the files being overriden by the top layer that generates the built charm will be the holder of any overriden files
[16:42] <bloodearnest> lazypower, where will <layer>/unit_tests/* end up in the built charm dir structure?
[16:42] <lazypower> that dir will, yes
[16:42] <lazypower> but if there is say a <layer>/unit_tests/01-thing.py  in both layers
[16:42] <lazypower> the top most layer will override the 01-thing.py in the lower layer
[16:42] <bloodearnest> right
[16:47] <lazypower> 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] <jrwren> tvansteenburgh: thanks.
[16:49] <bloodearnest> lazypower, by default, I assume charm build will merge all non-special directories in the final output?
[16:50] <bloodearnest> where special I guess = reactive, maybe hooks?
[16:54] <lazypower> bloodearnest, when merging, it still overwrites unless its metadata.yaml or config.yaml
[16:57] <bloodearnest> lazypower, ack
[17:22] <jose> marcoceppi: ping re: PSA
[17:23] <marcoceppi> jose: yes
[17:23] <jose> 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] <jose> or do some MPs
[17:24] <marcoceppi> not yet, we may be producing one for work with code-in
[17:24] <jose> oh awesome
[20:16] <asanjar> kwmonroe: sorry pal, i thought you had it
[20:16] <kwmonroe> no worries asanjar -- i was building myself out of sparktc github.. pre-built bins are fine by me!
[20:47] <tvansteenburgh> jrwren: almost http://reports.vapour.ws/charm-test-details/charm-bundle-test-parent-3834
[20:48] <jrwren> tvansteenburgh: thanks for the notice. *grumble* at it failing still :)
[21:17] <stokachu> 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] <stokachu> and what is the format for defining both the compression kind and quality, is it compession.type=gzip,0?
[21:41] <marcoceppi> stokachu: that's example fail
[21:42] <marcoceppi> stokachu: it should be compression.kind=gzip in the example
[21:51] <stokachu> marcoceppi: ah!
[21:51] <stokachu> now that makes sense
[21:52] <cory_fu> Hey, so I have a proposal for charm layers that I'd like to get feedback on.
[21:52] <marcoceppi> cory_fu: shoot
[21:53] <cory_fu> 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] <cory_fu> So you'd have layer.yaml contain: includes: ['layer:apache-php']; options: apache: packages: [...]
[21:54] <marcoceppi> cory_fu: oh, I like that, then what every key under option would be automatically prefixed?
[21:54] <cory_fu> Instead of having a separate apache.yaml
[21:54] <stokachu> created a PR https://github.com/juju/docs/pull/751 for that doc fix
[21:54] <cory_fu> Automatically prefixed?
[21:55] <marcoceppi> cory_fu: well, my thought was layers that presented options would provide jsonschema in them so that it'd be explicit
[21:56] <marcoceppi> ie, apache-php layer would define the schema which it supported
[21:56]  * marcoceppi strawmans
[21:56] <cory_fu> That sounds intriguing.  What would that look like?
[21:57] <cory_fu> Charm-tools could do the validation, then, at build time, too
[21:57] <marcoceppi> cory_fu: right
[21:59] <stokachu> heres my ghost charm using the latest wheelhouse support https://jujucharms.com/u/adam-stokes/ghost/trusty/8
[21:59] <marcoceppi> bleh, the apache-php layer doesn't quite fit the mold, but almost done
[21:59] <stokachu> went from 334 files to 72 \o/
[21:59] <marcoceppi> cory_fu: give me 10 min, otp
[22:00] <stokachu> though im not sure why the revisions aren't being updated to match what is in bzr
[22:29] <cory_fu> marcoceppi: Still otp?
[22:29] <marcoceppi> yes
[22:29] <cory_fu> kk
[22:31] <cory_fu> 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] <cory_fu> 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] <marcoceppi> cory_fu: https://gist.github.com/marcoceppi/ca36655cb917b16d0681
[22:52] <marcoceppi> something like that?
[22:53] <marcoceppi> cory_fu: actually, just updated it
[22:56] <cory_fu> marcoceppi: I like that a lot
[22:56] <cory_fu> I also like that Alot
[22:56] <marcoceppi> I hug Alot
[22:57] <marcoceppi> 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] <marcoceppi> and maybe replace "provides" with "defines" as provides is used in the charm ecosystem
[22:57] <marcoceppi> best not to conflate the two
[22:57] <cory_fu> Agreed on the last bit
[22:57] <adam_g> ERROR error checking if provisioned: subprocess encountered error code 1   <- is there any way to get debug info on the subprocess failure ?
[22:58] <cory_fu> jsonschema doesn't have support for validated lists?
[22:58] <marcoceppi> cory_fu: no idea
[22:58] <marcoceppi> cory_fu: apparently it does
[23:00] <marcoceppi> 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] <cory_fu> Agreed
[23:00] <marcoceppi> 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] <cory_fu> 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] <marcoceppi> cory_fu: you mean the golang libraries, or how it looks as an implementation?
[23:08] <cory_fu> How it looks as an implementation
[23:08] <marcoceppi> cory_fu: the apache-plugin charm would be a good start ;)
[23:09] <cory_fu> Specifically, I'm wondering how the action.yaml contents are used as / injected into a schema
[23:09] <marcoceppi> cory_fu: they are the schema, each parent item defines a params and that params is the schema
[23:09] <marcoceppi> we'd remove the parent key (action name) and just have a schema, more or less what's in the gist
[23:10] <marcoceppi> cory_fu: O
[23:10] <marcoceppi> 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] <cory_fu> So, looking at the example in that last link, the contents of "properties" is what we'd be filling in, right?
[23:11] <marcoceppi> cory_fu: no, not quite
[23:11] <cory_fu> So I guess we can just wrap it in {'type': 'object', 'properties': schema}
[23:12] <stokachu> cory_fu: ah ok
[23:12] <marcoceppi> cory_fu: let me try to produce a quick py example
[23:16] <cory_fu> 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] <marcoceppi> cory_fu: I wrote my thoughts at the bottom of the gist: https://gist.github.com/marcoceppi/ad318d081e3b30857819
[23:40] <marcoceppi> cory_fu: if you'd like I can open an issue on charm-tools to discuss further