How to well target units of a service and other points (production scope)
nicolas.foata at gmail.com
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 kotsbak.com>
> 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-dev-ref
> app_branch: staging
> app_node_env: staging
> Wouldn't that solve some of the above mentioned problems?
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/**
> mailman/listinfo/juju <https://lists.ubuntu.com/mailman/listinfo/juju>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Juju