On 6 November 2013 20:07, Kapil Thangavelu
<kapil.thangav...@canonical.com> wrote:
> instead of adding more complexity and concepts, it would be ideal if we
> could reuse the primitives we already have. ie juju environments have three
> user exposed services, that users can add-unit / remove-unit etc. they have
> a juju prefix and therefore are omitted by default from status listing.
> That's a much simpler story to document. how do i scale my state server..
> juju add-unit juju-db... my provisioner juju add-unit juju-provisioner.
I have a lot of sympathy with this point of view. I've thought about
it quite a bit.
I see two possibilities for implementing it:
1) Keep something like the existing architecture, where machine agents can
take on managerial roles, but provide a veneer over the top which
specially interprets service operations on the juju built-in services
and translates them into operations on machine jobs.
2) Actually implement the various juju services as proper services.
The difficulty I have with 1) is that there's a significant mismatch between
the user's view of things and what's going on underneath.
For instance, with a built-in service, can I:
- add a subordinate service to it?
- see the relevant log file in the usual place for a unit?
- see its charm metadata?
- join to its juju-info relation?
If it's a single service, how can its units span different series?
(presumably it has got a charm URL, which includes the series)
I fear that if we try this approach, the cracks show through
and the result is a system that's hard to understand because
too many things are not what they appear.
And that's not even going into the plethora of special
casing that this approach would require throughout the code.
2) is more attractive, as it's actually doing what's written on the
label. But this has its own problems.
- it's a highly significant architectural change.
- juju managerial services are tightly tied into the operation
of juju itself (not surprisingly). There are many chicken and egg
problems here - we would be trying to use the system to support itself,
and that could easily lead to deadlock as one part of the system
tries to talk to another part of the system that relies on the first.
I think it *might* be possible, but it's not gonna be easy
and I suspect nasty gotchas at the end of a long development process.
- again there are inevitably going to be many special cases
throughout the code - for instance, how does a unit
acquire the credentials it needs to talk to the API
server?
It may be that a hybrid approach is possible - for example
implementing the workers as a service and still having mongo
and the API server as machine workers. I think that's
a reasonable evolutionary step from the approach I'm proposing.
The reasoning behind my proposed approach perhaps
comes from the fact that (I'm almost ashamed to admit it)
I'm a lazy programmer. I don't like creating mountains of code
where a small amount will do almost as well.
Adding the concept of jobs on machines maps very closely
to the architecture that we have today. It is a single
extra concept for the user to understand - all the other
features (e.g. add-machine and destroy-machine) are already
exposed.
I agree that in an ideal world we would scale juju meta-services
just as we would scale normal services, but I think it's actually
reasonable to have a special case here.
Allowing the user to know that machines can take on juju managerial
roles doesn't seem to be a huge ask. And we get just as much
functionality with considerably less code, which seems like a significant
win to me in terms of ongoing maintainability and agility for the future.
cheers,
rog.
PS now not cross-posting, sorry Tim - followups to juju@lists.ubuntu.com only.
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
