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

[Nicolas FOATA]

Thank a lot for all the responses and especially for reactivity. Waouh. ;-)

For the first question concerning the units, so I will explore deeper the
state of service units. (Good way, ;-) )

For the second one, it's with pleasure that I will follow and joined the
discussion on stacks (next version 1.10, isn't it ?).

At last, to answer your curiosity, I would like to tag Amazon machines on
both levels.
e.g:
  A tag for the platform containing all the services, so maybe a better
thing to have it at the environment level and avoid redundancy,
  A tag for the service to know who did it, or what is its name, and then
better at the service level.

Have a good day or night ( I don't know what time is it where you are ? ) ,

Best regards,

Nicolas Foata


2013/5/31 Mark Shuttleworth <mark at ubuntu.com>

>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130531/5fc10bde/attachment.html>