On Fri, Nov 8, 2013 at 4:47 PM, Mark Canonical Ramm-Christensen < mark.ramm-christen...@canonical.com> wrote:
> 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 > Sounds good to me. Similar to how I was thinking of doing it originally, but segregating it from add-machine etc. should prevent adding cognitive overhead for users that don't care. Also, not so much leakage of internals, and no magic (a good thing!) 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 <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 apologies; my last cross-post, honest! followups to >> juju-dev@lists.ubuntu.com only. >> >> -- >> Juju-dev mailing list >> Juju-dev@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> > > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
