Given a bit of thought the reasons that I proposed the sub command remove-from rather than just remove are both obscure enough that I should have explained them, and wrong enough that I should not have proposed that syntax.
I was thinking that remove always requires a machine ID, and that add did not which made them asymmetric enough to justify a different spelling, but a bit of further thinking leads me to think that this is already the case with add-unit and remove-unit, and therefore consistency is better than a new spelling. On Fri, Nov 8, 2013 at 5:15 PM, Andrew Wilkins <andrew.wilk...@canonical.com > wrote: > 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
