[00:29] `juju unexpose` doesn't seem to be doing anything; digitalocean via JuDO, I'm tailing the unit log and I just see "got service change" "no new charm event" [00:32] it changes the value of "exposed" for the service in `juju status` [00:32] I have multiple services running on a single machine, but the other services are also not exposed [00:33] it's trusty/wordpress [00:33] open-ports shows 80/tcp [00:34] juju 1.23-alpha1-utopic-amd64 cilent [00:34] client* [00:37] http://paste.ubuntu.com/10118085/ === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [00:54] that might be due to having "firewall-mode: instance" in my environments/digitalocean.jenv [01:02] no, instance is what I want [01:15] ah, looks like expose triggers a hook which is expected to implement the desired effect, and it's not implemented in trusty/wordpress === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === dcwilliams_VA is now known as whovian [02:51] bodie_: there's no net sec on digital ocean [02:51] bodie_: effectively digital ocean has no multi-tenant private networking, and manual provider (which do plugin uses) is a no-op with net sec [02:52] bodie_: there isn't a hook for exposed afaik, there was discussion of one many moons ago, but afaicr nothing extant [02:54] hazmat, I see. there's some doc on it on a site which *I think* is caching something old? https://juju-docs.readthedocs.org/en/latest/internals/expose-services.html [02:54] hazmat, but it could definitely be done on DO using iptables in the hooks, it's simply not an API level hosting option on their service. that makes sense now though. [02:54] bodie_: those docs are ancient, they applied to the python juju impl against zookeeper [02:55] and even then "These hooks will be implemented at a future time." [02:55] is in those docs [02:55] thanks for clarifying [02:56] could be a good use-case for actions :P [02:56] bodie_: i've advocated for juju to use a iptable based expose/unexpose (ie universality first).. only issue is relations don't nesc. model tcp conn. there's some work ongoing with the network model which seeks to address that. [02:57] as is expose/unexpose work against providers that implement network security.. (azure, ec2, google, openstack). [02:57] and for the others they are no-ops [02:58] bodie_: not sure how that relates to actions, but hammers and nails i guess [02:59] something like that [03:02] more like, if I need the ability to control iptables, I can add that to a charm I'm using as a stopgap === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54_ is now known as kadams54-away === kadams54-away is now known as kadams54_ === kadams54_ is now known as kadams54-away === dcwilliams_VA is now known as whovian === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [22:42] what's a good charm to copy to begin deciphering how to build a mesos-master charm ? === kadams54 is now known as kadams54-away [22:47] SimplySeth: Whats your choice in config management toolkits? [22:47] lazyPower: Charm-Helpers and Ansible [22:47] SimplySeth: charm create -t ansible [22:48] if you have charm-tools installed (apt-get install charmtools) [22:48] lazyPower: yeah I already brew installed charm-tools [22:48] lazyPower: thanks [22:48] np [22:48] there are some patterns we employed for the docker charm (hyper simple, only delivering the docker plumbing) that are written in ansible [22:48] there's also the elasticsearch charm which is seemingly more complex, and uses ansible as well [22:49] https://github.com/chuckbutler/docker-charm [22:49] here's the outline of ansible logic we used: http://chuckbutler.github.io/docker-charm/dev/ansible-patterns.html [22:51] coool [22:54] lazyPower: thanks for the help [22:54] np === kadams54-away is now known as kadams54