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

Reply via email to