How to well target units of a service and other points (production scope)

Nicolas FOATA nicolas.foata at gmail.com
Thu Jun 6 15:21:29 UTC 2013


Since the beginning of the week, I'm continuing to test juju and I come
back on the first question, on which you said :

> We already have a notion of upgrades, and associated hooks. So perhaps
> what you are looking for is the ability for an upgrade hook to put the
> unit into a pending state (so other units, and related services, would
> be able to react accordingly) during the upgrade, or just for Juju to do
> this automatically while the upgrade is being run.

It seems really interesting to put a unit into a pending state from an
upgrade hook.
But I don't know at all where I have to look for (where I can find how to
set the unit state from a charm  to pending or another state ?).

Moreover, if I launch an upgrade to a service, all the units of this
service have to react one by one and not in parallel to avoid an
unavailability of the service. Is there a clean solution to do this kind of
thing ?

At last, I saw that when you remove some units of service these ones will
be put into the machine pool, and consequently when you add a unit to this
service, it will take one randomly (?) and if i deploy a new different
service, it will use also this old units. That means that we can have old
logs or old directory of the previous service into some machines (coming
from the old service) of the new service and the other machines of the new
service newly created are cleaner (it seems dangerous for the consistency
?).

Why not a pool for each service ?

Have a good day at all juju staff,


2013/5/31 Nicolas FOATA <nicolas.foata at gmail.com>

> In my case, I do not think that benefits are so significant today.
> That's why, I wrote it in a miscellaenous part of my first e-mail and
> this is not really important if it's not possible.
>
> Moreover, this is true that we always have to make a choice between the
> benefits
> and the complexity that this generates.
> Therefore, if the application is easy to learn, use, and reliable,
> it's better for everyone (hide the complexity, show and keep only relevant
> stuff)
>
> Good practice : Keep It Simple ;-)
>
>
>
>
> 2013/5/31 Mark Shuttleworth <mark at ubuntu.com>
>
>> On 05/31/2013 02:17 PM, Nicolas FOATA wrote:
>> > At last, to answer your curiosity, I would like to tag Amazon machines
>> > on both levels.
>> > e.g:
>> >   A tag for the platform containing all the services, so maybe a
>> > better thing to have it at the environment level and avoid redundancy,
>> >   A tag for the service to know who did it, or what is its name, and
>> > then better at the service level.
>>
>> This sounds like it would be addressed in general form by having the
>> ability to add parameters that are passed to the provider (and on to the
>> substrate) at the environment and service level. Not sure if the juju
>> team will think that's tasteful, but I can see the practical benefits!
>>
>> Mark
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130606/ef48e0c7/attachment.html>


More information about the Juju mailing list