I have a few high level thoughts on all of this, but the key thing I want to say is that we need to get a meeting setup next week for the solution to get hammered out.
First, conceptually, I don't believe the user model needs to match the implementation model. That way lies madness -- users care about the things they care about and should not have to understand how the system works to get something basic done. See: http://www.amazon.com/The-Inmates-Are-Running-Asylum/dp/0672326140 for reasons why I call this madness. For that reason I think the path of adding a --jobs flag to add-machine is not a move forward. It is exposing implementation detail to users and forcing them into a more complex conceptual model. Second, we don't have to boil the ocean all at once. An "ensure-ha" command that sets up additional server nodes is better than what we have now -- nothing. Nate is right, the box need not be black, we could have an juju ha-status command that just shows the state of HA. This is fundamentally different than changing the behavior and meaning of add-machines to know about juju jobs and agents and forcing folks to think about that. Third, we I think it is possible to chart a course from ensure-ha as a shortcut (implemented first) to the type of syntax and feature set that Kapil is talking about. And let's not kid ourselves, there are a bunch of new features in that proposal: * Namespaces for services * support for subordinates to state services * logging changes * lifecycle events on juju "jobs" * special casing the removal of services that would kill the environment * special casing the stats to know about HA and warn for even state server nodes I think we will be adding a new concept and some new syntax when we add HA to juju -- so the idea is just to make it easier for users to understand, and to allow a path forward to something like what Kapil suggests in the future. And I'm pretty solidly convinced that there is an incremental path forward. Fourth, the spelling "ensure-ha" is probably not a very good idea, the cracks in that system (like taking a -n flag, and dealing with failed machines) are already apparent. I think something like Nick's proposal for "add-manager" would be better. Though I don't think that's quite right either. So, I propose we add one new idea for users -- a state-server. then you'd have: juju management --info juju management --add juju management --add --to 3 juju management --remove-from I know this is not following the add-machine format, but I think it would be better to migrate that to something more like this: juju machine --add --Mark Ramm On Thu, Nov 7, 2013 at 8:16 PM, roger peppe <[email protected]>wrote: > On 6 November 2013 20:07, Kapil Thangavelu > <[email protected]> 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 apologies; my last cross-post, honest! followups to > [email protected] only. > > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
