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

[Nicolas FOATA]

Thanks ! With your remark for overriding config.yaml, it helps me on some
stuff
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-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 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...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130531/bf64efb1/attachment-0001.html>