Re: Units & resources: are units homogeneous?

[Mark Shuttleworth]

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

Re: Units & resources: are units homogeneous?

[Rick Harding]

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-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Units & resources: are units homogeneous?

[John Meinel]

...

>
> And now I think of it, can I stream resources? I don't want to
> provision a machine with 8TB of storage just so I can restore a 4TB
> dump. Maybe this is just a terrible example, since I probably couldn't
> be bothered uploading the 4TB dump in the first place, and would
> instead setup tunnels and pipes to stream it into a 'juju run'
> command. An abuse of Juju resources better suited to Juju blob
> storage?
>
>
We've talked about streaming resources, but decided to omit it for version
1.

   1. Resources are cached in the server anyway, so a 4TB resources isn't a
   great fit there. We want to be caching it both for efficiency (5 units
   consuming 100MB resource only needs to be copied to the cloud one time),
   and for repeatability (adding another unit can be sure to get the same
   content of the resource even if the charm store, etc has been upgraded.)
   2. Resources *are* loaded only on demand. So until the charm does
   "resource-get", we don't copy the data from the API server to the unit.
   3. I believe we left it implementation defined if we load resources from
   the charm store opportunistically, but I think because of (1) we probably
   will.
   4. We can certainly add a new hook tool that would stream the content
   from the API server (eg resource-stream). However, 1&2 mean it didn't seem
   super useful vs added complexity and more time to implement.

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

Re: Units & resources: are units homogeneous?

[John Meinel]

...

>
> And now I think of it, can I stream resources? I don't want to
> provision a machine with 8TB of storage just so I can restore a 4TB
> dump. Maybe this is just a terrible example, since I probably couldn't
> be bothered uploading the 4TB dump in the first place, and would
> instead setup tunnels and pipes to stream it into a 'juju run'
> command. An abuse of Juju resources better suited to Juju blob
> storage?
>
>
We've talked about streaming resources, but decided to omit it for version
1.

   1. Resources are cached in the server anyway, so a 4TB resources isn't a
   great fit there. We want to be caching it both for efficiency (5 units
   consuming 100MB resource only needs to be copied to the cloud one time),
   and for repeatability (adding another unit can be sure to get the same
   content of the resource even if the charm store, etc has been upgraded.)
   2. Resources *are* loaded only on demand. So until the charm does
   "resource-get", we don't copy the data from the API server to the unit.
   3. I believe we left it implementation defined if we load resources from
   the charm store opportunistically, but I think because of (1) we probably
   will.
   4. We can certainly add a new hook tool that would stream the content
   from the API server (eg resource-stream). However, 1&2 mean it didn't seem
   super useful vs added complexity and more time to implement.

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

Re: Units & resources: are units homogeneous?

[Stuart Bishop]

On 17 February 2016 at 01:20, Katherine Cox-Buday
 wrote:

> 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).

While I have charms where units have distinct roles (one master,
multiple standbys, and the juju leader making decisions), they can be
treated as homogeneous since they need to be able to fail over from
one role to another. The only use case I can think of where different
resources might be pulled down on different units is deploying a new
service with data restored from a backup. The master would be the only
unit to pull down this resource (the backup) on deployment, and the
standbys would replicate it from the master.

And now I think of it, can I stream resources? I don't want to
provision a machine with 8TB of storage just so I can restore a 4TB
dump. Maybe this is just a terrible example, since I probably couldn't
be bothered uploading the 4TB dump in the first place, and would
instead setup tunnels and pipes to stream it into a 'juju run'
command. An abuse of Juju resources better suited to Juju blob
storage?

-- 
Stuart Bishop 

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

Re: Units & resources: are units homogeneous?

[Stuart Bishop]

On 17 February 2016 at 01:20, Katherine Cox-Buday
 wrote:

> 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).

While I have charms where units have distinct roles (one master,
multiple standbys, and the juju leader making decisions), they can be
treated as homogeneous since they need to be able to fail over from
one role to another. The only use case I can think of where different
resources might be pulled down on different units is deploying a new
service with data restored from a backup. The master would be the only
unit to pull down this resource (the backup) on deployment, and the
standbys would replicate it from the master.

And now I think of it, can I stream resources? I don't want to
provision a machine with 8TB of storage just so I can restore a 4TB
dump. Maybe this is just a terrible example, since I probably couldn't
be bothered uploading the 4TB dump in the first place, and would
instead setup tunnels and pipes to stream it into a 'juju run'
command. An abuse of Juju resources better suited to Juju blob
storage?

-- 
Stuart Bishop 

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

Re: Units & resources: are units homogeneous?

[Adam Collard]

On Tue, 16 Feb 2016 at 18:40 Katherine Cox-Buday <
katherine.cox-bu...@canonical.com> wrote:

> Thanks, Adam.
>
> Playing devil's advocate to my own question here: why isn't this 1 charm
> broken up into separate charms that handle the different bits of the
> workflow? It sounds like you'd want to break this up into different charms
> along lines of modeled responsibility and then deploy using bundles?
>

Well we do have a few bundles too, but these are different services inside
the one charm.

There are several advantages to using this approach
1) we can fail over services without user intervention
2) when the architecture of services inside Landscape changes, there is no
user intervention required (i.e. one upgrade-charm hook to write, config
files take over from there).
3) we encapsulate the details of Landscape inside the charm, maintained by
us and don't expose implementation details to Juju users
4) when the user "juju add-unit"s (or remove-unit's) we can scale the
services that we know should be scaled, maintaining affinity and
anti-affinity rules that are properties of the software we maintain.
5) avoid some complex interdependencies when relation-changed hooks fire

... I could probably come up with some more, but that should be enough for
you to chew over :)


> Sorry if I'm over-simplifying.
>

Nah it's fine :)
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Units & resources: are units homogeneous?

[Adam Collard]

On Tue, 16 Feb 2016 at 18:40 Katherine Cox-Buday <
katherine.cox-bu...@canonical.com> wrote:

> Thanks, Adam.
>
> Playing devil's advocate to my own question here: why isn't this 1 charm
> broken up into separate charms that handle the different bits of the
> workflow? It sounds like you'd want to break this up into different charms
> along lines of modeled responsibility and then deploy using bundles?
>

Well we do have a few bundles too, but these are different services inside
the one charm.

There are several advantages to using this approach
1) we can fail over services without user intervention
2) when the architecture of services inside Landscape changes, there is no
user intervention required (i.e. one upgrade-charm hook to write, config
files take over from there).
3) we encapsulate the details of Landscape inside the charm, maintained by
us and don't expose implementation details to Juju users
4) when the user "juju add-unit"s (or remove-unit's) we can scale the
services that we know should be scaled, maintaining affinity and
anti-affinity rules that are properties of the software we maintain.
5) avoid some complex interdependencies when relation-changed hooks fire

... I could probably come up with some more, but that should be enough for
you to chew over :)


> Sorry if I'm over-simplifying.
>

Nah it's fine :)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Units & resources: are units homogeneous?

[Katherine Cox-Buday]

Thanks, Adam.

Playing devil's advocate to my own question here: why isn't this 1 charm 
broken up into separate charms that handle the different bits of the 
workflow? It sounds like you'd want to break this up into different 
charms along lines of modeled responsibility and then deploy using bundles?


Sorry if I'm over-simplifying.

-
Katherine

On 02/16/2016 12:35 PM, Adam Collard wrote:

Hi Katherine,


On Tue, 16 Feb 2016 at 18:20 Katherine Cox-Buday 
> wrote:


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).


Yes, as a concrete example the Landscape charm[0], does just that and 
runs different Landscape services on different units, using the leader 
to decide what goes where. The units are heterogeneous and under the 
control of the charm.


Cheers,

Adam
[0] https://jujucharms.com/landscape-server/trusty/


--
-
Katherine

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

Re: Units & resources: are units homogeneous?

[Katherine Cox-Buday]

Thanks, Adam.

Playing devil's advocate to my own question here: why isn't this 1 charm 
broken up into separate charms that handle the different bits of the 
workflow? It sounds like you'd want to break this up into different 
charms along lines of modeled responsibility and then deploy using bundles?


Sorry if I'm over-simplifying.

-
Katherine

On 02/16/2016 12:35 PM, Adam Collard wrote:

Hi Katherine,


On Tue, 16 Feb 2016 at 18:20 Katherine Cox-Buday 
> wrote:


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).


Yes, as a concrete example the Landscape charm[0], does just that and 
runs different Landscape services on different units, using the leader 
to decide what goes where. The units are heterogeneous and under the 
control of the charm.


Cheers,

Adam
[0] https://jujucharms.com/landscape-server/trusty/


--
-
Katherine

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

Re: Units & resources: are units homogeneous?

[Adam Collard]

Hi Katherine,


On Tue, 16 Feb 2016 at 18:20 Katherine Cox-Buday <
katherine.cox-bu...@canonical.com> wrote:

> 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).
>

Yes, as a concrete example the Landscape charm[0], does just that and runs
different Landscape services on different units, using the leader to decide
what goes where. The units are heterogeneous and under the control of the
charm.

Cheers,

Adam

[0] https://jujucharms.com/landscape-server/trusty/
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Units & resources: are units homogeneous?

[Adam Collard]

Hi Katherine,


On Tue, 16 Feb 2016 at 18:20 Katherine Cox-Buday <
katherine.cox-bu...@canonical.com> wrote:

> 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).
>

Yes, as a concrete example the Landscape charm[0], does just that and runs
different Landscape services on different units, using the leader to decide
what goes where. The units are heterogeneous and under the control of the
charm.

Cheers,

Adam

[0] https://jujucharms.com/landscape-server/trusty/
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Units & resources: are units homogeneous?

[Katherine Cox-Buday]

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