I think it's fine for units to self-organise into specific functions.

We'll add a means for these functions to be described to the user, later.

The only rule is that the config and resources presented to units are
consistent, or trend to consistency. In other words, when I set config
or modify a resource, I am doing that for ALL units. While the units
will individually make the transition, they will ultimately ALL make the
transition. So at some level Juju knows that units are briefly
different, depending on which ones have processed the messages
associated with the new config or new resource, but it thinks of the
entire group of units as having the same target config / resources.

If a unit asks for a resource, it should get the same answer that any
other unit asking for that resource would get at that same moment.

Mark

On 17/02/16 12:03, Rick Harding wrote:
> I wanted to add that the reason we're curious about this is because we're
> working on how Juju can help provide insights into things that could be
> off/wrong between units. If we expect the units to be the same, then things
> like warning users that a unit hasn't yet gotten a resource that the others
> have seems like a good idea. However, if you're expecting different units
> to appear differently, then it's like having an error dialog always be
> there that you end up ignoring because that's the way it's meant to be.
>
> It influences the design of how Juju thinks about the resources across the
> units if we're expecting them to look the same or not. There have been
> discussions of how unit entropy is something to try to work on cutting out
> of the system. If I add-unit, it should be the same code at the same
> revision as the one I started previously, even if it's been months since I
> deployed that unit.
>
> The landscape example is interesting, but I can't help but feel like that
> it's abusing the system a bit. The end user doesn't really know what's
> running where if it's a self-adapting system based on the number of units.
> It's really interesting because I guess the end user just wants to know
> they've got landscape running and working properly, but the tech person in
> me is a bit scared that it's not clear what services I'm running where
> setup and exposed in what ways.
>
> On Tue, Feb 16, 2016 at 1:20 PM Katherine Cox-Buday <
> katherine.cox-bu...@canonical.com> wrote:
>
>> Hey All,
>>
>> The team is looking closely at some of our CLI surrounding resources, and
>> an interesting question came up: should units be considered homogeneous?
>>
>> My understanding is that it's a goal to make the management of units more
>> consistent, and making the units more homogeneous would support this, but
>> I'm wondering from a workload perspective if this is also true? One example
>> I could think of to support the discussion is a unit being elected leader
>> and thus taking a different path through it's workflow than the other
>> units. When it comes to resources, maybe this means it pulls a different
>> sub-set of the declared resources, or maybe doesn't pull resources at all
>> (e.g. it's coordinating the rest of the units or something).
>>
>> I'm curious what people are seeing out in the field, and hearing opinions
>> too.
>>
>> Thanks :)
>>
>>
>> -
>> Katherine
>>
>>
>
>

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Reply via email to