[00:29] <bodie_> `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] <bodie_> it changes the value of "exposed" for the service in `juju status`
[00:32] <bodie_> I have multiple services running on a single machine, but the other services are also not exposed
[00:33] <bodie_> it's trusty/wordpress
[00:33] <bodie_> open-ports shows 80/tcp
[00:34] <bodie_> juju 1.23-alpha1-utopic-amd64 cilent
[00:34] <bodie_> client*
[00:37] <bodie_> http://paste.ubuntu.com/10118085/
[00:54] <bodie_> that might be due to having "firewall-mode: instance" in my environments/digitalocean.jenv
[01:02] <bodie_> no, instance is what I want
[01:15] <bodie_> ah, looks like expose triggers a hook which is expected to implement the desired effect, and it's not implemented in trusty/wordpress
[02:51] <hazmat> bodie_: there's no net sec on digital ocean
[02:51] <hazmat> 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] <hazmat> bodie_: there isn't a hook for exposed afaik, there was discussion of one many moons ago, but afaicr nothing extant
[02:54] <bodie_> 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] <bodie_> 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] <hazmat> bodie_: those docs are ancient, they applied to the python juju impl against zookeeper
[02:55] <hazmat> and even then "These hooks will be implemented at a future time."
[02:55] <hazmat> is in those docs
[02:55] <bodie_> thanks for clarifying
[02:56] <bodie_> could be a good use-case for actions :P
[02:56] <hazmat> 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] <hazmat> as is expose/unexpose work against providers that implement network security.. (azure, ec2, google, openstack).
[02:57] <hazmat> and for the others they are no-ops
[02:58] <hazmat> bodie_: not sure how that relates to actions, but hammers and nails i guess
[02:59] <bodie_> something like that
[03:02] <bodie_> more like, if I need the ability to control iptables, I can add that to a charm I'm using as a stopgap
[22:42] <SimplySeth> what's a good charm to copy to begin deciphering how to build a mesos-master charm ?
[22:47] <lazyPower> SimplySeth: Whats your choice in config management toolkits?
[22:47] <SimplySeth> lazyPower: Charm-Helpers and Ansible
[22:47] <lazyPower> SimplySeth: charm create -t ansible
[22:48] <lazyPower> if you have charm-tools installed (apt-get install charmtools)
[22:48] <SimplySeth> lazyPower:  yeah I already brew installed charm-tools
[22:48] <SimplySeth> lazyPower: thanks
[22:48] <lazyPower> np
[22:48] <lazyPower> there are some patterns we employed for the docker charm (hyper simple, only delivering the docker plumbing) that are written in ansible
[22:48] <lazyPower> there's also the elasticsearch charm which is seemingly more complex, and uses ansible as well
[22:49] <lazyPower> https://github.com/chuckbutler/docker-charm
[22:49] <lazyPower> here's the outline of ansible logic we used: http://chuckbutler.github.io/docker-charm/dev/ansible-patterns.html
[22:51] <SimplySeth> coool
[22:54] <SimplySeth> lazyPower: thanks for the help
[22:54] <lazyPower> np