I've just realised that all the traffic for this thread was actually in juju-dev, so I'll revert to there. Another cross post then, my apologies.
On 7 November 2013 09:21, roger peppe <roger.pe...@canonical.com> wrote: > 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
