| lazyPower | bdx yep, $LAYER_PATH and $INTERFACE_PATH | 00:23 |
|---|---|---|
| tiagogomes | Hi all, does JuJu boostrapped on OpenStack requires Swift? | 09:55 |
| gnuoy | jamespage, got a sec for https://code.launchpad.net/~gnuoy/charms/trusty/nova-compute/1515570/+merge/277556 ? | 10:18 |
| stub | tvansteenburgh: Bootstrap is failing in the lxc test runner (ERROR there was an issue examining the environment: cannot use 37017 as state port, already in use) | 12:20 |
| tvansteenburgh | stub: thanks, will fix | 13:22 |
| icey | has anybody made a custom hook for juju before? | 13:57 |
| icey | outside of juju core that is | 13:57 |
| jrwren | icey: I don't even know what that means. When would it trigger? :) | 14:12 |
| icey | as a result of juju-run :) | 14:13 |
| jrwren | icey: how would that differ from an action? | 14:13 |
| icey | expanding on an idea that came out of the sprint | 14:13 |
| icey | it woudn't really, except that the user shouldn't be calling it, another charm would be :-D | 14:14 |
| jrwren | icey: how would that differ from a realtion? :] | 14:14 |
| icey | this charm would have no relations | 14:15 |
| icey | it woulkd interct with potentially every other charm deployed | 14:15 |
| jrwren | why not? | 14:15 |
| icey | IF the other charm had defined this hook | 14:15 |
| jrwren | ah, there is the implicit relation, right? | 14:15 |
| icey | in essence, it would be an advanced service health monitor | 14:15 |
| jrwren | i can't see how this differs from a relation. | 14:15 |
| jrwren | IMO you have just defined relation. | 14:15 |
| icey | can I have one side of a relation run a command on the other service? | 14:16 |
| icey | there's relation-joined, relation-departing | 14:16 |
| jrwren | yes? | 14:16 |
| icey | but not relation-run? | 14:16 |
| icey | itr should run every update-status | 14:16 |
| jrwren | well, both run. | 14:16 |
| icey | it* | 14:16 |
| jrwren | relation-changed | 14:17 |
| jrwren | so update-status would change the relation state causing the relation-changed to run | 14:17 |
| icey | thaat could be a lot of bouncing back and forth | 14:17 |
| jrwren | what is update-status? do you mean maintenance status? | 14:17 |
| icey | update-status is a hook that runs regularly | 14:18 |
| icey | update-status provides constant feedback to the user about the status of the service the charm is modeling. The charm is run by Juju at regular intervals, and gives authors an opportunity to run code that gets the “health” of the service or services. | 14:18 |
| jrwren | ah cool, i've not used that. maybe I should :) | 14:18 |
| icey | yeah, in essence I'm working on a beefed up version of that, and charm authors can define both health checking functionality and potentially remediation for issues | 14:19 |
| jrwren | sounds very interesting. | 14:19 |
| icey | examples coming from storage charms: hard drive becomes unhealthy, system can remove the hard drive, run tests against it, and maybe re-add it | 14:19 |
| icey | if that fails, alert a human to intervene | 14:19 |
| jrwren | we are currently using nrpe for health checking and the nrpe subordinate and nrpe module in charmhelpers makes it simple and great. | 14:20 |
| icey | my coworker has been lightly discussing it with someone on the core team and they like it, we're going to talk about it more but I figure maybe I can hack together a super basic version :) | 14:20 |
| icey | so far it's working out but I wondered if anybody had done anything similar | 14:20 |
| jrwren | icey: I think you can. update-status could change relation data which would cause relation-changed to execute. That gives you what you need afaict. | 14:21 |
| icey | I really don't want to have to add a relation to it; it also works just fine by adding the juju-client layer to the charm | 14:22 |
| icey | if we have to add relations, it becomes something that the administrator must add all of the relations when it can be done through juju itself | 14:22 |
| jrwren | i see. yeah. | 14:26 |
| beisner | hi all. juju 1.25.2 is in ppa:juju/proposed. today i'll be flipping our openstack charm testing lab to use that version for test automation. | 14:28 |
| tiagogomes | Hi all, does JuJu boostrapped on OpenStack requires Swift? | 14:30 |
| beisner | hi tiagogomes, i don't believe it is expressly required. two links for reference: | 14:33 |
| beisner | https://jujucharms.com/docs/1.25/config-openstack | 14:33 |
| beisner | https://jujucharms.com/docs/1.25/howto-privatecloud | 14:33 |
| tiagogomes | thanks. I have seen those, but I when I try to bootrap juju I got an "caused by: the configured region "RegionOne" does not allow access to all required services, namely: compute, object-store. access to these services is missing: object-store" error | 14:36 |
| mgz | beisner: yell if you see anything fun with 1.25.2 | 14:49 |
| beisner | mgz, thx sir. i've just done a global force of all uosci jobs to proposed 1.25.2. it'll get some serious exercise as we're in charm freeze/testing. | 14:49 |
| mgz | since I added extra validation to our OS-deployer job we've had intermittent failures due to the env not finishing all relations, but that should hopefully just be master | 14:49 |
| beisner | mgz, our automation calls `juju-wait -v` immediately after juju-deployer exits. that has resolved the testing-too-soon issue for us. | 14:51 |
| beisner | we found that arbitrary sleep times are racy, given the undercloud load varies. | 14:52 |
| beisner | but i can't point at a single case where juju-wait failed to wait 'til the deployment, hooks, relations, etc., were actually-done. | 14:52 |
| beisner | so that's a cool tool. +100 stub | 14:52 |
| beisner | +1000 even | 14:52 |
| mgz | beisner: my version is similar to that, but also looks at the workload-status reported by the charms | 14:54 |
| mgz | well, instead really. | 14:54 |
| beisner | mgz, yeah in our amulet tests we don't use juju-wait, we wait for extended workload state as well. which is arguably the best way. for the charm to announce: ok, i'm ready now. | 14:55 |
| mgz | indeed, but relies on charm sanity | 14:55 |
| beisner | yep | 14:55 |
| lazyPower | oi, our charms are sane | 14:55 |
| mgz | :P | 14:55 |
| lazyPower | what are you insinuating mgz? ;) | 14:55 |
| aisrael | tvansteenburgh: Should this merge request be showing up in the queue? It's been reviewed as needs fixing but the original author hasn't responded since then: https://code.launchpad.net/~brad-marshall/charms/trusty/memcached/add-monitors-relation/+merge/276958 | 15:36 |
| aisrael | tvansteenburgh: also, item 2391 in the queue is a dead link | 15:39 |
| tvansteenburgh | aisrael: 2391 removed | 15:41 |
| aisrael | ta | 15:41 |
| tvansteenburgh | aisrael: i'll have to look into the other thing, just not right this sec | 15:41 |
| aisrael | tvansteenburgh: No worries. Just wanted to make sure it was on your radar. | 15:42 |
| icey | anybody have thoughts on testing an action that would require removing parts of a unit and multiple minutes for any differences to become visible | 16:30 |
| stub | icey, jrwren : You don't need update-status. You can call the juju-run tool from a cronjob running on the unit to do stuff in a hook context. | 16:32 |
| mbruzek | cory_fu_: marcoceppi, lazyPower, any other charmers, can I get a review on the charm-helpers update: https://code.launchpad.net/~mbruzek/charm-helpers/host-docstrings/+merge/282788 | 17:26 |
| bdx | marcoceppi: do have a example of layer-django being consumed? | 17:30 |
| bdx | marcoceppi: I've created `anyapp` to test with here -> https://github.com/jamesbeedy/anyapp | 17:31 |
| bdx | and django-nginx charm here http://bazaar.launchpad.net/~jamesbeedy/charms/trusty/django-nginx/dev/files | 17:32 |
| bdx | marcoceppi: what I'm wondering is how you are setting up your django project <-> what params you are setting in your django.yaml | 17:34 |
| lazyPower | i'm pretty sure marco is travelling today bdx, replys may be latent. | 17:43 |
| lazyPower | thanks for the PR btw :) | 17:43 |
| bdx | lazyPower: ok. cool. yea... about that ... I'm testing it out a bunch as well .... not sure its fully there yet ... but I think I'm making some good headway... http://bazaar.launchpad.net/~jamesbeedy/charms/trusty/django-nginx/dev/view/head:/reactive/django_nginx.py | 17:49 |
| lazyPower | nice | 17:49 |
| bdx | lazyPower: the @when hook will only execute when all states are met right? | 17:50 |
| lazyPower | yep | 17:51 |
| bdx | lazyPower: but will it execute everytime the states are met? | 17:51 |
| lazyPower | yep | 17:51 |
| lazyPower | unless you add a @when_not to prevent it from running | 17:51 |
| lazyPower | or something to that effect | 17:52 |
| bdx | so then using the only_once hook will ensure that it only runs one time, no matter how many times the states are satisfied in the @when? | 17:52 |
| lazyPower | good question, i'm not sure :) | 17:53 |
| lazyPower | I've not used only_once | 17:53 |
| tiagogomes | Hi, when JuJu 1.25 will be released? Will it be part of ubuntu 16.04 ? | 18:01 |
| lazyPower | tiagogomes 1.25.0 is already out as stable | 18:02 |
| lazyPower | 1.26.0-alpha is the current dev release, with 2.0 on the horizon | 18:02 |
| tiagogomes | lazyPower ah thanks | 18:03 |
| icey | I'm adding an action to a charm and I'm not entirely sure how to test it; it changes a config in a running program, the easiest way I've thought of testing it is to query that the config value is changed. If I add testing for the functionality exposed by the configuration, I'm testing the underlying software as part of the charm tests, would that be desired? | 18:14 |
| stub | I think it is desired. You do want to test the underlying software, because you need to confirm that the process you are using to change the configuration is correct (eg. you are remembering to send a HUP signal to reload, or that this particular setting requires the daemon bounced) | 18:19 |
| stub | You could test that you changed the config and maybe issued a reload command, but that doesn't mean it actually works. | 18:20 |
| stub | icey: ^ | 18:20 |
| lazyPower | o/ stub | 18:20 |
| stub | o/ | 18:20 |
| stub | Off into the night in a tick | 18:21 |
| icey | well, the program I'm using lets us send in cluster config through the program itself, and I can query the program to validate that the configuration changed stub | 18:21 |
| icey | testing the underlying functionality would require me removing a disk, waiting (10+ minutes) for the disk to be marked down, bring the disk back up, trigger the action, kill the disk, wait longer than the first time to make sure it is not marked down | 18:22 |
| icey | so, 20+ minutes of waiting? | 18:22 |
| icey | and the program, ceph, will report the config to me if it is set | 18:22 |
| stub | Right. Removing disks isn't possible in most automated test frameworks, so that is right out. Setting the config value and reading it back from ceph (not just looking at the config files) seems good. | 18:23 |
| bdx | stub: yes!!!! | 18:24 |
| icey | yeah, it's not a config file thing, it's literally telling ceph `ceph osd set nodown` | 18:24 |
| icey | stub: thanks~! | 18:24 |
| bdx | stub: you just touched on something near and dear to my heart | 18:25 |
| bdx | stub: removing/replacing ceph disks is a danger zone | 18:26 |
| bdx | stub: this is an area that needs help from the MAAS team | 18:26 |
| stub | The kernel guys might be able to help you fake a failed disk if you really want (if ln -s /dev/random /dev/sdb2 doesn't do the trick) | 18:27 |
| bdx | stub: if you replace/remove a disk in ceph, maas will assume a different drive for sda | 18:27 |
| bdx | you also have to reboot the node | 18:28 |
| bdx | but | 18:28 |
| bdx | stub: ^ is a huge issue for me right now | 18:29 |
| bdx | I have done alot of DR testing with ceph/maas | 18:29 |
| bdx | maas would need to recommission the node to be able to account for a new/replaced disk | 18:31 |
| icey | bdx stub we're working on making the ceph experience better with juju, including updating / replacing disks | 18:31 |
| icey | it's on our roadmap :) | 18:32 |
| bdx | thats a relief | 18:32 |
| bdx | the CIO of my company keeps bugging me about it | 18:32 |
| bdx | he knows its not a thing | 18:32 |
| bdx | I have been able to work around it by manually altering maasdb | 18:33 |
| aisrael | stub: Is the cassandra work you've done ready-ready to go? https://code.launchpad.net/~stub/charms/trusty/cassandra/ensure-thrift/+merge/279869 | 18:43 |
| stub | aisrael: Yes. Just been resending it to the CI system for laughs. | 18:44 |
| aisrael | stub: CI always needs something to do. :D | 18:45 |
| stub | Good timing if you are reviewing - that branch was about to go into production ;) | 18:45 |
| aisrael | stub: Yup, I am reviewing. So far, so good. | 18:46 |
| icey | so, I'm noticing that the update-status hook doesn't seem to actually exist in any documentation yet? | 18:56 |
| stub | icey: No, but I already opened an issue on that and it is being added. | 18:57 |
| icey | ok, just wanted to make sure it was ok stub, thanks! | 18:57 |
| mbruzek | bdx: I just got back from lunch and I am going to review your tls/k8s pull requests after my meeting | 18:59 |
| bdx | mbruzek: sweet! its small, just swapped out your local chdir | 19:06 |
| bdx | but the tls one is a little bigger | 19:06 |
| icey | is there a recommended way to run actions in a functional test? | 19:08 |
| tvansteenburgh | icey: https://github.com/juju/amulet/blob/master/amulet/deployer.py#L362 | 19:10 |
| icey | thanks tvansteenburgh, I just found the PR that added that :) | 19:11 |
| icey | it's funny when google shows the PR before the actual file :-P | 19:14 |
| pmatulis | mbruzek: fyi, https://github.com/juju/docs/pull/801 , comments welcome | 20:08 |
| mbruzek | pmatulis: I am taking a look now | 20:08 |
| mbruzek | pmatulis: I see what I was looking for on line 54! | 20:13 |
| mbruzek | still reading | 20:13 |
| pmatulis | mbruzek: thanks for the comments | 20:54 |
| mbruzek | pmatulis: thanks for sending me the link | 20:54 |
| bdx | anyone have luck with GitUrlFetchHandler or install_remote from charmhelpers.fetch ? | 21:01 |
| natefinch | rick_h_: you around? | 21:06 |
| mbruzek | bdx how did you run the tls tests? http://paste.ubuntu.com/14510918/ I am getting an assertion error on the test_ca() method | 21:06 |
| mbruzek | bdx I see a /tmp/server.crt, but not a /tmp/ca | 21:07 |
| mbruzek | .crt | 21:07 |
| bdx | mbruzek: ooo mbruzek, my bad, here | 21:46 |
| mbruzek | no problem I am fixing it | 21:46 |
| mbruzek | and setting up the repo to run these tests every push | 21:47 |
| bdx | niceee | 21:52 |
| lazyPower | 'eating broccoli' ;) | 21:53 |
| === ericsnow is now known as ericsnow-afk | ||
| lazyPower | bdx: Landed your class + tests with some refactoring | 22:32 |
| lazyPower | give a look at master | 22:32 |
| lazyPower | bdx https://travis-ci.org/mbruzek/layer-tls | 22:33 |
| mbruzek | bdx: we had to rewrite the tests to pass. | 22:33 |
| lazyPower | not really i mean | 22:34 |
| lazyPower | we took his high level abstract, and then made it red2green | 22:34 |
| bdx | lazyPower, mbruzek: nice! | 22:35 |
| bdx | I knew the tests would need a little love | 22:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!