| === 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 | ||
| 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 | 11:31 |
| === verterok` is now known as verterok | ||
| 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:19 |
| 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:21 |
| jamespage | marcoceppi, | 13:51 |
| jamespage | ack | 13:51 |
| stub | marcoceppi: Is all-machines.log or equivalent available anymore from CI runs? I can't see a link to them any more. | 14:10 |
| marcoceppi | stub: they should be | 14:27 |
| marcoceppi | stub: where are you looking? | 14:27 |
| jose | arosales, marcoceppi: hey guys, wanted to check everything was going good wrt tasks? | 14:28 |
| stub | marcoceppi: http://review.juju.solutions/review/2370 - just a link to jenkins logs | 14:48 |
| marcoceppi | stub: yes, this is a known deficiency. THe results still get logged to the vapour.ws site | 14:51 |
| 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 | 14:52 |
| stub | marcoceppi: ahh, ta. | 15:00 |
| === Makyo is now known as Guest54187 | ||
| === kwmonroe_ is now known as kwmonroe | ||
| 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:00 |
| 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:21 |
| 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:37 |
| 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:38 |
| 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:39 |
| lazypower | bloodearnest: so far i've seen a lot of use of tox to isolate all that in a venv | 16:40 |
| 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:41 |
| 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:42 |
| 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:47 |
| bloodearnest | lazypower, by default, I assume charm build will merge all non-special directories in the final output? | 16:49 |
| bloodearnest | where special I guess = reactive, maybe hooks? | 16:50 |
| lazypower | bloodearnest, when merging, it still overwrites unless its metadata.yaml or config.yaml | 16:54 |
| bloodearnest | lazypower, ack | 16:57 |
| jose | marcoceppi: ping re: PSA | 17:22 |
| 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:23 |
| marcoceppi | not yet, we may be producing one for work with code-in | 17:24 |
| jose | oh awesome | 17:24 |
| 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:16 |
| tvansteenburgh | jrwren: almost http://reports.vapour.ws/charm-test-details/charm-bundle-test-parent-3834 | 20:47 |
| jrwren | tvansteenburgh: thanks for the notice. *grumble* at it failing still :) | 20:48 |
| 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:17 |
| stokachu | and what is the format for defining both the compression kind and quality, is it compession.type=gzip,0? | 21:18 |
| marcoceppi | stokachu: that's example fail | 21:41 |
| marcoceppi | stokachu: it should be compression.kind=gzip in the example | 21:42 |
| stokachu | marcoceppi: ah! | 21:51 |
| stokachu | now that makes sense | 21:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| marcoceppi | cory_fu: well, my thought was layers that presented options would provide jsonschema in them so that it'd be explicit | 21:55 |
| 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:56 |
| cory_fu | Charm-tools could do the validation, then, at build time, too | 21:57 |
| marcoceppi | cory_fu: right | 21:57 |
| 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 | 21:59 |
| stokachu | though im not sure why the revisions aren't being updated to match what is in bzr | 22:00 |
| cory_fu | marcoceppi: Still otp? | 22:29 |
| marcoceppi | yes | 22:29 |
| cory_fu | kk | 22:29 |
| 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:31 |
| 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:32 |
| marcoceppi | cory_fu: https://gist.github.com/marcoceppi/ca36655cb917b16d0681 | 22:52 |
| marcoceppi | something like that? | 22:52 |
| marcoceppi | cory_fu: actually, just updated it | 22:53 |
| cory_fu | marcoceppi: I like that a lot | 22:56 |
| cory_fu | I also like that Alot | 22:56 |
| marcoceppi | I hug Alot | 22:56 |
| 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 |
| === bladernr` is now known as bladernr | ||
| 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:57 |
| 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 | 22:58 |
| 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:00 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| stokachu | cory_fu: ah ok | 23:12 |
| marcoceppi | cory_fu: let me try to produce a quick py example | 23:12 |
| 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:16 |
| marcoceppi | cory_fu: I wrote my thoughts at the bottom of the gist: https://gist.github.com/marcoceppi/ad318d081e3b30857819 | 23:37 |
| marcoceppi | cory_fu: if you'd like I can open an issue on charm-tools to discuss further | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!