Juju architecture questions

Gustavo Niemeyer gustavo at niemeyer.net
Tue Sep 18 11:07:30 UTC 2012


On Mon, Sep 17, 2012 at 6:06 AM, Thomas Leonard
<tal at it-innovation.soton.ac.uk> wrote:
(...)
> If the private key is shared by all units (as currently), how do we ensure
> that only one key is generated if multiple units are deployed?

The points are highly depend on the service being managed. One option
would be to store the key inside the database itself atomically with
the first unit that joins the relation, for example. Another choice is
using a peer relation and negotiating the key with the other units.

It's not a hard problem, but even then we'll certainly be simplifying
these workflows over time.

(...)
>> Explicitly defining endpoints as you suggest adds yet another piece
>> onto the mental model that has to be held for comprehending the
>> system.
>
> I'd disagree with that. For me, the most difficult part of understanding
> Juju has been figuring out what it's doing behind the "magic". I know that a
(...)
> - db-endpoint-added: runs exactly once, and always creates the database
>
> - db-relation-joined: not needed?

I understand you'd like different building blocks that would map
exactly to the problem you have at hand, rather than having to add
logic in your own scripts to do what you want, but that's a rabbit
hole. If we attempted to support all possible use cases by introducing
custom internal semantics, we'd end up with a lot more "magic" for
people to understand and use. Instead, there are fewer hooks, and
fewer commands to run, with well defined semantics.

That said, we'll certainly be improving the semantics, and enriching
the model as we go, by digging through the real issues people find in
that model and observing use cases that are not as comfortable as they
should be. I'm taking note of your considerations, and we'll keep them
in mind for the improvements we're envisioning for relation-bound
settings.

>> It's easier today:
>>
>>      juju add-relation client rabbit:ssl
>
> Note: today it's actually:

I meant that this is how you can do, rather than what is in place
today. I'm not the author of that charm.

> Of course, if you write the charm to make SSL available by default then it
> doesn't make any difference.

Exactly. As a principle, charms should behave well and be functional
by default, rather than requiring people to jump through hops to get
things running.

> I'm not sure this is true. We want to embed the nagios monitoring page in an
(...)
> sensible. In general, having to change the charms depending on whether the
> client is or isn't managed by Juju is harder for us.

This is a different point. As I mentioned in the previous message, we'll have
something more polished for that in the future, but you can trivially
handle that
case today by creating a proxy charm to represent the external service.

> Thanks. We make a lot of prototype systems. Typically they are made up of
> prototype or production services developed by several different
> organisations, which then have to be integrated. Using Juju has the
> potential to simply this, since everyone can make their service available as
> a Juju charm and we get a standard method for handling configuration,
> deployment, testing, etc.
(...)

This all sounds quite exciting, and matches very well with where we're
headed towards. Thanks for the details.

(...)
> Our main concerns at this point are:
>
> - security (despite being prototypes, we still need to handle "personal"
> data in many cases),

This is high on our list, and we'll solve it in the near term. We're
hard at work right now porting the whole system to Go, and some issues
will already be addressed once we release it. Shortly afterwards, we
have several improvements in the pipeline as well.

> - connecting to external (non-Juju) services (as explained above).

Sounds good, as explained.


gustavo @ http://niemeyer.net



More information about the Juju mailing list