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

Nicolas FOATA nicolas.foata at
Fri May 31 13:35:47 UTC 2013

Thanks ! With your remark for overriding config.yaml, it helps me on some
and opens new ways for sharing values which I hadn't noticed.

However this action, only happens when you deploy a service, doesn't it ?

I will think about it and coming back quickly when my ideas will be more
orderly and accurate,
and after improving my knowledge about stacks too.

As I have just say, to Mark waouh for your reactivity.

2013/5/31 Marius Kotsbak <marius at>

> Den 31. mai 2013 13:21, skrev Nicolas FOATA:
>  Hi juju community,
>> First of all, thanks for juju, I am playing with it (0.7 python version)
>> on an Amazon EC2 environment since nearly one week
>> and it's really interesting and easy to build a complete
>> and a complex platform (databases, front-ends, proxy servers, juju-gui,
>> ...).
>> Nevertheless, I have some questions and some points
>> on which ones I would like some additionnal information if possible.
>> Indeed, I was faced with some problems.
>> 1) Units inside a service
>> By example, when there is a big infrastruture of several webservers,
>> we often unexpose one by one the webservers, do the upgrade of teh unit,
>> test if
>> and put it back (expose it again).
>> But for doing this kind of thing here, this is not possible because if
>> we do an unexpose
>> the service is unexpose in its entirety.
>> Unless it is possible with juju to add some arguments to the command line,
>>   and so the unexpose hook knows that it has to unexpose only one part
>> of the VMs.
>> In another hand, we can solve this problems by creating severail
>> webservers with differents names
>> e.g : juju deploy webserver ws1
>>        juju deploy webserver ws2
>>        juju expose ws1
>>        juju expose ws2
>>        juju unexpose ws1
>>        # Do some stuff (upgrade, tests, etc.)
>>        juju expose ws1
>> But in that case, the webservers are seen as separate services and not
>> as a unique service.
>> At last,  I think, this is the same problem, if I want to activate more
>> information or more log
>> on a single unit and not the units containing into the service for
>> debugging, it doesn't seem to be possible.
>> Indeed, if I set a config parameter it is for all the units of the
>> service and not only the target unit.
>> 2) Global parameters
>> Moreover, if I want to pass a global parameters to all the services or
>> for a subset of services,
>> it means that I have to put it into all the config.yaml file of Charm.
>> Consequently, if I have many variables, it will pollute my config
>> parameters and hide relevant ones.
>> But maybe, I missed something or it's not a good solution that I said
>> and it exists other ways to do it.
> In config.yaml you can use references with overrides to avoid duplication:
> something-dev: &something-dev-ref
>     app_branch: master
>     app_name: one_app
>     app_url:
>     app_user: ubuntu
>     app_node_env: development
>     install_root: /opt
> and then:
> something-staging:
>     <<: *something-dev-ref
>     app_branch: staging
>     app_node_env: staging
> Wouldn't that solve some of the above mentioned problems?
> --
> Marius
> --
> Juju mailing list
> Juju at
> Modify settings or unsubscribe at:**
> mailman/listinfo/juju <>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Juju mailing list