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

[Mark Shuttleworth]

Great questions Nicholas.

On 05/31/2013 12:21 PM, Nicolas FOATA wrote:
> 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.

That seems like a reasonably generic problem worth thinking about in the
tool.

Units already have SOME state differences - they can be pending or
started, for example. I wonder whether what you want is some ability to
flag that an upgrade is in progress with a transition in that state.
Simplistically, a unit might revert to pending while it upgrades. That
would avoid having a new state ("upgrading") that everything else needs
to think about.

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.

> 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.

When we started with juju we were motivated by the potential of very
'flat' environments, where you can get lots more machines easily, just
by asking for them. So I think our taste was skewed towards 'all units
are the same', cloudy environments. But I think it's worth at least
debating and considering per-unit config of one form or another.

> 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.
>
> e.g: debug level on
>        urls of repositories

Join the discussion on Stacks. A stack is like a group of charms that
can share config. Seems like that would be a concrete step in the
direction you are looking for.

> 3) Miscellaneous : Amazon EC2 tags and completion
>
> At last, this is not really important, but I want to notify it.
>
> When we create VMs on Amazon EC2 via the Amazon interface, it is
> possible to add somme key=value data
> such as name=nfoata-webserver and thus it's possible to retrieve
> easily them (with Amazon GUI) 
> or for other stuff.
> But, in the environement.yaml, there is no available parameters for
> these key value attributes.

Out of curiosity, do you want to tag Amazon machines at the environment
level or at the service level? Or both?

> At last, a simple remark of lazy IT engineer, when we do juju deploy
> <servicename> or juju status <servicename>,
> it will be interesting to have some completion (for decreasing the
> muscular effort made by the fingers) 
> for the juju keywords (deploy, remove-service, etc.) and charms or
> services or units already known.
> But in all cases, this lazy engineer (me) really like juju and its
> concepts.
>

Me too :)

Mark