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

[Marius Kotsbak]

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: https://a.server.com
     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