<div dir="ltr">Thank a lot for all the responses and especially for reactivity. Waouh. ;-)<br><div class="gmail_quote"><div dir="ltr"><br>For the first question concerning the units, so I will explore deeper the state of service units. (Good way, ;-) )<br>
<br>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 ?).<br>
<br>At last, to answer your curiosity, I would like to tag Amazon machines on both levels.<br>e.g: <br>  A tag for the platform containing all the services, so maybe a better thing to have it at the environment level and avoid redundancy,<br>

  A tag for the service to know who did it, or what is its name, and then better at the service level. <div><br></div><div>Have a good day or night ( I don't know what time is it where you are ? ) ,</div><div><br></div>

<div>Best regards,<br><div><br>Nicolas Foata</div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/31 Mark Shuttleworth <span dir="ltr"><<a href="mailto:mark@ubuntu.com" target="_blank">mark@ubuntu.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Great questions Nicholas.<br>
<div><br>
On 05/31/2013 12:21 PM, Nicolas FOATA wrote:<br>
> 1) Units inside a service<br>
><br>
> By example, when there is a big infrastruture of several webservers,<br>
> we often unexpose one by one the webservers, do the upgrade of teh<br>
> unit, test if<br>
> and put it back (expose it again).<br>
> But for doing this kind of thing here, this is not possible because if<br>
> we do an unexpose<br>
> the service is unexpose in its entirety.<br>
><br>
> Unless it is possible with juju to add some arguments to the command line,<br>
>  and so the unexpose hook knows that it has to unexpose only one part<br>
> of the VMs.<br>
><br>
> In another hand, we can solve this problems by creating severail<br>
> webservers with differents names<br>
> e.g : juju deploy webserver ws1<br>
>       juju deploy webserver ws2<br>
>       juju expose ws1<br>
>       juju expose ws2<br>
>       juju unexpose ws1<br>
>       # Do some stuff (upgrade, tests, etc.)<br>
>       juju expose ws1<br>
><br>
> But in that case, the webservers are seen as separate services and not<br>
> as a unique service.<br>
<br>
</div>That seems like a reasonably generic problem worth thinking about in the<br>
tool.<br>
<br>
Units already have SOME state differences - they can be pending or<br>
started, for example. I wonder whether what you want is some ability to<br>
flag that an upgrade is in progress with a transition in that state.<br>
Simplistically, a unit might revert to pending while it upgrades. That<br>
would avoid having a new state ("upgrading") that everything else needs<br>
to think about.<br>
<br>
We already have a notion of upgrades, and associated hooks. So perhaps<br>
what you are looking for is the ability for an upgrade hook to put the<br>
unit into a pending state (so other units, and related services, would<br>
be able to react accordingly) during the upgrade, or just for Juju to do<br>
this automatically while the upgrade is being run.<br>
<div><br>
> At last,  I think, this is the same problem, if I want to activate<br>
> more information or more log<br>
> on a single unit and not the units containing into the service for<br>
> debugging, it doesn't seem to be possible.<br>
> Indeed, if I set a config parameter it is for all the units of the<br>
> service and not only the target unit.<br>
<br>
</div>When we started with juju we were motivated by the potential of very<br>
'flat' environments, where you can get lots more machines easily, just<br>
by asking for them. So I think our taste was skewed towards 'all units<br>
are the same', cloudy environments. But I think it's worth at least<br>
debating and considering per-unit config of one form or another.<br>
<div><br>
> 2) Global parameters<br>
><br>
> Moreover, if I want to pass a global parameters to all the services or<br>
> for a subset of services,<br>
> it means that I have to put it into all the config.yaml file of Charm.<br>
> Consequently, if I have many variables, it will pollute my config<br>
> parameters and hide relevant ones.<br>
> But maybe, I missed something or it's not a good solution that I said<br>
> and it exists other ways to do it.<br>
><br>
> e.g: debug level on<br>
>        urls of repositories<br>
<br>
</div>Join the discussion on Stacks. A stack is like a group of charms that<br>
can share config. Seems like that would be a concrete step in the<br>
direction you are looking for.<br>
<div><br>
> 3) Miscellaneous : Amazon EC2 tags and completion<br>
><br>
> At last, this is not really important, but I want to notify it.<br>
><br>
> When we create VMs on Amazon EC2 via the Amazon interface, it is<br>
> possible to add somme key=value data<br>
> such as name=nfoata-webserver and thus it's possible to retrieve<br>
> easily them (with Amazon GUI)<br>
> or for other stuff.<br>
> But, in the environement.yaml, there is no available parameters for<br>
> these key value attributes.<br>
<br>
</div>Out of curiosity, do you want to tag Amazon machines at the environment<br>
level or at the service level? Or both?<br>
<div><br>
> At last, a simple remark of lazy IT engineer, when we do juju deploy<br>
> <servicename> or juju status <servicename>,<br>
> it will be interesting to have some completion (for decreasing the<br>
> muscular effort made by the fingers)<br>
> for the juju keywords (deploy, remove-service, etc.) and charms or<br>
> services or units already known.<br>
> But in all cases, this lazy engineer (me) really like juju and its<br>
> concepts.<br>
><br>
<br>
</div>Me too :)<br>
<span><font color="#888888"><br>
Mark<br>
</font></span></blockquote></div><br></div>
</div></div></div><br></div>