-e should remember the environment in that session

[Jorge Castro]

I like that I can "juju bootstrap -e my-ec2-environment"

But then I need to add a "-e my-ec2-environment" from then on when I am deploying and adding stuff. That's alot of typing! How about like how VCS systems do it:

$ juju bootstrap -e my-ec2-environment
Environment now set as my-ec2-environment
type: ec2

(then do stuff, no need to be explicit with the -e, then when I want to use my local stuff:)

$ juju switch-environment my-local-thing
Environment now set as my-local-thing
type: local

Then do stuff, I can then switch to any of my environments by demand, and then we just have convenience commands for it like:

juju list-environments - shows every one I've configured
juju environment - shows me which environment I am currently in.

[Mark Mims (mark-mims)]

I do run multiple envs at the same time though... sometimes even on purpose!

- ec2 (one email account) to run byobu-classroom
- ec2 (another email account) to run a demo stack
- local (because I was developing something locally when I had to do the impromptu demo above)

I could totally run them in separate screen shells though.

[Juan L. Negron (negronjl)]

I like this so +1 from me.

I'm not 100% sure of how this should be implemented but, I agree with the
sentiment of being able to operate on diff. environments while at the same
time not having to explicitly name them on every command.

Thanks,

Juan

On Fri, Nov 25, 2011 at 11:00 AM, Jorge O. Castro <email address hidden> wrote:

> Public bug reported:
>
> I like that I can "juju bootstrap -e my-ec2-environment"
>
> But then I need to add a "-e my-ec2-environment" from then on when I am
> deploying and adding stuff. That's alot of typing! How about like how
> VCS systems do it:
>
> $ juju bootstrap -e my-ec2-environment
> Environment now set as my-ec2-environment
> type: ec2
>
> (then do stuff, no need to be explicit with the -e, then when I want to
> use my local stuff:)
>
> $ juju switch-environment my-local-thing
> Environment now set as my-local-thing
> type: local
>
> Then do stuff, I can then switch to any of my environments by demand,
> and then we just have convenience commands for it like:
>
> juju list-environments - shows every one I've configured
> juju environment - shows me which environment I am currently in.
>
> ** Affects: juju
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to juju.
> https://bugs.launchpad.net/bugs/896378
>
> Title:
> -e should remember the environment in that session
>
> Status in juju:
> New
>
> Bug description:
> I like that I can "juju bootstrap -e my-ec2-environment"
>
> But then I need to add a "-e my-ec2-environment" from then on when I
> am deploying and adding stuff. That's alot of typing! How about like
> how VCS systems do it:
>
> $ juju bootstrap -e my-ec2-environment
> Environment now set as my-ec2-environment
> type: ec2
>
> (then do stuff, no need to be explicit with the -e, then when I want
> to use my local stuff:)
>
> $ juju switch-environment my-local-thing
> Environment now set as my-local-thing
> type: local
>
> Then do stuff, I can then switch to any of my environments by demand,
> and then we just have convenience commands for it like:
>
> juju list-environments - shows every one I've configured
> juju environment - shows me which environment I am currently in.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/896378/+subscriptions
>
>

[Kapil Thangavelu (hazmat)]

effectively this sounds like management of the environments.yaml default key.

[Clint Byrum (clint-fewbar)]

I think for the main use case, this feature request might be better:

https://bugs.launchpad.net/juju/+bug/823352

So you'd do

juju shell -e foo
juju:foo>

I don't think it makes much sense to have "sessions" in a magical way as we'll see people with prod/test/dev in their environments.yaml and we don't want them accidentally plonking on prod without a prompt that shows them what they're about to do.

IMO, this bug should be marked as a duplicate of bug #823352

[Jamu Kakar (jkakar)]

You might want to take a look at virtualenvwrapper, which provides a
similar UI overtop of virtualenv. It does nice things like detecting
when you're in the wrong environment and you try to do something, for
example. It could be a good starting point to see how such a thing
could work.

[Kapil Thangavelu (hazmat)]

Excerpts from Clint Byrum's message of Fri Nov 25 21:44:25 UTC 2011:
> I think for the main use case, this feature request might be better:
>
> https://bugs.launchpad.net/juju/+bug/823352
>
> So you'd do
>
> juju shell -e foo
> juju:foo>
>
> I don't think it makes much sense to have "sessions" in a magical way as
> we'll see people with prod/test/dev in their environments.yaml and we
> don't want them accidentally plonking on prod without a prompt that
> shows them what they're about to do.
>

good point, agreed. The shell impl will need to wait till we go after a REST
interface, doing shell consoles in twisted is more complicated than its worth,
imo.

[Mark Mims (mark-mims)]

How about the juju cli using environments found in the following order:
- specified on the cli w/ the -e option
- specified in an environment variable (like JUJU_ENV)
- the default specified in .juju/environments.yaml

This should take care of the case you're talking about, yet still
provide the flex we need in general.

On 11/25/2011 12:00 PM, Jorge O. Castro wrote:
> Public bug reported:
>
> I like that I can "juju bootstrap -e my-ec2-environment"
>
> But then I need to add a "-e my-ec2-environment" from then on when I am
> deploying and adding stuff. That's alot of typing! How about like how
> VCS systems do it:
>
> $ juju bootstrap -e my-ec2-environment
> Environment now set as my-ec2-environment
> type: ec2
>
> (then do stuff, no need to be explicit with the -e, then when I want to
> use my local stuff:)
>
> $ juju switch-environment my-local-thing
> Environment now set as my-local-thing
> type: local
>
> Then do stuff, I can then switch to any of my environments by demand,
> and then we just have convenience commands for it like:
>
> juju list-environments - shows every one I've configured
> juju environment - shows me which environment I am currently in.
>
> ** Affects: juju
> Importance: Undecided
> Status: New
>

--
Mark Mims, Ph.D.
Canonical Ltd.
<email address hidden>
[phone]

[Mark Mims (mark-mims)]

fixed in Bug #933165
lp:~hazmat/juju/env-from-env