environment identifiers

[Gustavo Niemeyer]

On Tue, Jan 15, 2013 at 1:52 PM, Kapil Thangavelu
<kapil.thangavelu at canonical.com> wrote:
>
>
> On Tue, Jan 15, 2013 at 9:34 AM, Gustavo Niemeyer
> <gustavo.niemeyer at canonical.com> wrote:
>>
>> The environment identifier we've been using so far to disambiguate is
>> a name, which even though prone to duplication, is also encouraged to
>> be unique within a user's context (note you've added JUJU_ENV last year
>> with it in several places).
>
> Unfortunately that's not unique from a service provider perspective or
> really any non-user centric perspective. The JUJU_ENV usage from last year
> is for juju cli usage and thus defer's to the uniqueness of name within the
> user's environments.yaml.

I think that's what I said above.

>> If we introduce a different form of identification for environments, that
>> will span consequences throughout the system: How do you see it? How
>> do you export it? How do you set it? How do you correlate it to the
>> actual environment? And so on. So, I'd rather avoid that for the moment
>> if possible.
>>
>
> Its an environment instance property, it wouldn't be exported as that
> captures definition. The in review branch currently sets the environment id
> as part of state server initialization. As an environment instance identity
> property it can only be set once. Wrt to correlation the goal is that its
> also available from the websocket endpoint used that's configured with the
> service provider.
>
> While i respect the desire to defer, its currently needed for some in
> progress integration work this cycle.

What's the use case?


gustavo @ http://niemeyer.net