On Wed, Sep 3, 2014 at 11:37 PM, Andrew Wilkins <andrew.wilk...@canonical.com> wrote: > On Thu, Sep 4, 2014 at 3:46 AM, Eric Snow <eric.s...@canonical.com> wrote: >> Here's a write-up on my experience writing a charm for the first time. > > Thanks for writing this up.
Blame Nate! He had the sense to ask me to do it. :) >> * there is no unexpose command > > ??? > > andrew@blank:~$ juju help unexpose > usage: juju unexpose [options] <service> > purpose: unexpose a service > > options: > -e, --environment (= "") > juju environment to operate in > andrew@blank:~$ > Wow. I could swear I did not see it when I tried, yet I see it there too. I'm glad because if there hadn't been one it would have made me question my understanding of what expose does. >> [1] I haven't had a chance to look at haproxy, but I'd expect that >> interface to be dependent on services that support multiple units. > > What are you after, if not something which load balances across multiple > units? If that's what haproxy does (where the units have no knowledge of each other) then it's the right tool for the job. I'm already planning on using a reverse-proxy for SSL and quickly switching to a fail-over instance, but I'm guessing that won't change (at least for the SSL needs). For redundancy I'm also planning on setting up replication on the postgresql charm, which I'm guessing would have to happen independently of haproxy. However, that will be easy (the charm already supports it). -eric -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev