Re: Renaming of environments

[John Meinel]

We can put the environment name in a field that is visible, but isn't
canonical. It depends on the specific use case, but if we can use tags, we
can use "juju-environment-uuid" or some tag like that as the official "what
environment is this in", and then "name" is just a local value, which can
be changed as it isn't a critical piece.

John
=:->


On Fri, Oct 23, 2015 at 9:19 AM, Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:

> On Fri, Oct 23, 2015 at 1:00 PM Menno Smits 
> wrote:
>
>> While working on the environment migrations spec I noticed that it is
>> currently not possible to change the name of a Juju environment once it has
>> been created. This creates an unfortunate corner case in the context of
>> environment migrations, where you might have an environment that can't be
>> migrated to another controller because you've already created another
>> (unrelated) environment with the same name on the target controller.
>>
>> Rick pointed out that it would also be nice to be able to rename an
>> environment when its purpose has changed. For example, you might have
>> created an environment called "test" which you build up and end up using
>> for production purposes. At that point the environment name doesn't make
>> much sense.
>>
>> We will fix this. The rename itself is fairly easy to implement but
>> environment names have also been used as part of things such as EC2 and
>> Openstack security group names so this will need to change too. It would be
>> better if the names of external environment-related resources used the
>> environment UUID instead. There is a card for this work in Onyx's backlog.
>>
>
> It was specifically requested that we include the environment name in
> resource names for debugging purposes (e.g. I'm looking at the AWS console
> and want to know which Juju machine this instance corresponds to). Some of
> this was done in 1.25, some was pre-existing.
>
> These requirements are at odds with each other. Just wondering if this has
> been considered.
>
> Cheers,
> Andrew
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

[Dimiter Naydenov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Awesome!! \o/

As a big fan of aliases (bash, git, etc.) I'd start using this right
away with juju now! :)

Thanks Tim!

Dimiter

On 23.10.2015 07:12, Tim Penhey wrote:
> Hi folks,
> 
> I scratched a personal itch yesterday and added the ability for
> users to specify their own aliases for juju commands.
> 
> There are two primary use cases that I was trying to address.
> 
> Firstly, the ability to specify default flags for commands: status
> = status --format=tabular
> 
> I could never remember the right environment variable to set to
> get tabular by default.
> 
> The second was to allow quicker iteration around playing with new
> CLI structure.  As most people are aware, the 2.0 CLI is going to
> be somewhat different to the current one, and I thought it would be
> good to provide a way in which we could "test drive" the new CLI
> with the existing codebase without having to actually code
> anything.
> 
> The aliases files lives in JUJU_HOME, and is a simple text file.
> Each non blank line that doesn't start with a '#' is considered to
> be an alias. The format is expected to be:
> 
>  =  [...]
> 
> So we can do things like:
> 
> # stat is like two whole letters shorter... stat = status
> --format=tabular
> 
> # list tests list-environments = system environments list-users =
> user list
> 
> and so on.
> 
> Tim
> 


- -- 
Dimiter Naydenov 
Juju Core Sapphire team 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWKeZDAAoJENzxV2TbLzHwOuMH/Rt5OqT29cGheVBNGraC0guR
qYSyS8nqsSKb7gizmu9HrbJeQjpQfv+Dskc97yOXlxsQbhfBrFGHkkHl15jsKHBh
XCx531/olNhs8Y9uqfI31SjMqRW4U0wylF4sVfMOpIsrTlJcuU7EQ8meYj0ObR7T
RWv9Rg6pg6b6fQ5tylVV+8LjE6YyRUr+V+8rQp/PLwVrACJQqVyi+tL5UQKd53vj
pgCqEbRJ/wN8fcQP7Pf6jh+FC84xecwmAd9Zc/toHXHh0ZYSKl022h0pPff/1XoB
JQqGyH4SS7XAR3T6jiy6ub7wYCe0LgkPtl13nbcrWR1YYZK1pJxtH+kdkwfYaXk=
=UrrP
-END PGP SIGNATURE-

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

[roger peppe]

On 23 October 2015 at 05:12, Tim Penhey  wrote:
> Hi folks,
>
> I scratched a personal itch yesterday and added the ability for users to
> specify their own aliases for juju commands.
>
> There are two primary use cases that I was trying to address.
>
> Firstly, the ability to specify default flags for commands:
>   status = status --format=tabular

This sounds useful, thanks. Presumably additional arguments are
just tacked onto the end?

> I could never remember the right environment variable to set to get
> tabular by default.
>
> The second was to allow quicker iteration around playing with new CLI
> structure.  As most people are aware, the 2.0 CLI is going to be
> somewhat different to the current one, and I thought it would be good to
> provide a way in which we could "test drive" the new CLI with the
> existing codebase without having to actually code anything.

Unless the new CLI is non-hierarchical I'm thinking that may
not work unless you can specify multi-level aliases;
For example:

model destroy = environment destroy

which might be a little harder.

While I'm on the subject of hierarchical CLIs, I often have difficulty
remembering where a given command is buried. "juju commands | grep"
was often a decent solution but doesn't work when the command
I'm looking for is buried two levels deep. Any chance of something like
"juju commands --all" to show all commands, even those two or more
levels down?

  cheers,
rog.

>
> The aliases files lives in JUJU_HOME, and is a simple text file. Each
> non blank line that doesn't start with a '#' is considered to be an
> alias. The format is expected to be:
>
>  =  [...]
>
> So we can do things like:
>
> # stat is like two whole letters shorter...
> stat = status --format=tabular
>
> # list tests
> list-environments = system environments
> list-users = user list
>
> and so on.
>
> Tim
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/juju-dev

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Renaming of environments

[Andrew Wilkins]

On Fri, Oct 23, 2015 at 3:32 PM John Meinel  wrote:

> We can put the environment name in a field that is visible, but isn't
> canonical. It depends on the specific use case, but if we can use tags, we
> can use "juju-environment-uuid" or some tag like that as the official "what
> environment is this in", and then "name" is just a local value, which can
> be changed as it isn't a critical piece.
>

It won't be quite as clear, but I suppose it's a fair price to pay. It
would be good if we updated tags for things that change, like this.

I'm doing the new Azure provider now, I've updated it so resource names do
not include the environment name.

Cheers,
Andrew


> John
> =:->
>
>
> On Fri, Oct 23, 2015 at 9:19 AM, Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> On Fri, Oct 23, 2015 at 1:00 PM Menno Smits 
>> wrote:
>>
>>> While working on the environment migrations spec I noticed that it is
>>> currently not possible to change the name of a Juju environment once it has
>>> been created. This creates an unfortunate corner case in the context of
>>> environment migrations, where you might have an environment that can't be
>>> migrated to another controller because you've already created another
>>> (unrelated) environment with the same name on the target controller.
>>>
>>> Rick pointed out that it would also be nice to be able to rename an
>>> environment when its purpose has changed. For example, you might have
>>> created an environment called "test" which you build up and end up using
>>> for production purposes. At that point the environment name doesn't make
>>> much sense.
>>>
>>> We will fix this. The rename itself is fairly easy to implement but
>>> environment names have also been used as part of things such as EC2 and
>>> Openstack security group names so this will need to change too. It would be
>>> better if the names of external environment-related resources used the
>>> environment UUID instead. There is a card for this work in Onyx's backlog.
>>>
>>
>> It was specifically requested that we include the environment name in
>> resource names for debugging purposes (e.g. I'm looking at the AWS console
>> and want to know which Juju machine this instance corresponds to). Some of
>> this was done in 1.25, some was pre-existing.
>>
>> These requirements are at odds with each other. Just wondering if this
>> has been considered.
>>
>> Cheers,
>> Andrew
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Renaming of environments

[Rick Harding]

That's interesting Andrew and not something considered in the conversations
around this so far. With the new Azure provider and resource groups is the
name of that group mutable? For Azure at least the resource groupings
should help with the tags/identification though it does complicate things
for the other providers. Are the tags typically not able to be updated?
Maybe we can provide some help to the user to map uuid to the names with
something like a juju show environment $uuid? and get name and some other
info back?



On Fri, Oct 23, 2015 at 6:33 AM Andrew Wilkins 
wrote:

> On Fri, Oct 23, 2015 at 3:32 PM John Meinel 
> wrote:
>
>> We can put the environment name in a field that is visible, but isn't
>> canonical. It depends on the specific use case, but if we can use tags, we
>> can use "juju-environment-uuid" or some tag like that as the official "what
>> environment is this in", and then "name" is just a local value, which can
>> be changed as it isn't a critical piece.
>>
>
> It won't be quite as clear, but I suppose it's a fair price to pay. It
> would be good if we updated tags for things that change, like this.
>
> I'm doing the new Azure provider now, I've updated it so resource names do
> not include the environment name.
>
> Cheers,
> Andrew
>
>
>> John
>> =:->
>>
>>
>> On Fri, Oct 23, 2015 at 9:19 AM, Andrew Wilkins <
>> andrew.wilk...@canonical.com> wrote:
>>
>>> On Fri, Oct 23, 2015 at 1:00 PM Menno Smits 
>>> wrote:
>>>
 While working on the environment migrations spec I noticed that it is
 currently not possible to change the name of a Juju environment once it has
 been created. This creates an unfortunate corner case in the context of
 environment migrations, where you might have an environment that can't be
 migrated to another controller because you've already created another
 (unrelated) environment with the same name on the target controller.

 Rick pointed out that it would also be nice to be able to rename an
 environment when its purpose has changed. For example, you might have
 created an environment called "test" which you build up and end up using
 for production purposes. At that point the environment name doesn't make
 much sense.

 We will fix this. The rename itself is fairly easy to implement but
 environment names have also been used as part of things such as EC2 and
 Openstack security group names so this will need to change too. It would be
 better if the names of external environment-related resources used the
 environment UUID instead. There is a card for this work in Onyx's backlog.

>>>
>>> It was specifically requested that we include the environment name in
>>> resource names for debugging purposes (e.g. I'm looking at the AWS console
>>> and want to know which Juju machine this instance corresponds to). Some of
>>> this was done in 1.25, some was pre-existing.
>>>
>>> These requirements are at odds with each other. Just wondering if this
>>> has been considered.
>>>
>>> Cheers,
>>> Andrew
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>
>>> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

[Rick Harding]

On Fri, Oct 23, 2015 at 12:12 AM Tim Penhey 
wrote:

> Hi folks,
>
> Firstly, the ability to specify default flags for commands:
>   status = status --format=tabular
>
> I could never remember the right environment variable to set to get
> tabular by default.
>
> The second was to allow quicker iteration around playing with new CLI
> structure.  As most people are aware, the 2.0 CLI is going to be
> somewhat different to the current one, and I thought it would be good to
> provide a way in which we could "test drive" the new CLI with the
> existing codebase without having to actually code anything.
>

This is very cool Tim. I would like to raise a word of caution though. When
folks get aliasing too much to work around pain points of the experience it
makes it easy to hide the pain and not raise it up and deal with it.  My
one hesitation here is that we need to make sure that these are small and
that if we find common ones that we bring them up as things that should be
fixed in the cli vs "just use the following aliases" in reply to folks
frustrations.

In particular, with the 2.0 cli experiments, it'd be helpful if there was
some method that everyone could be using a shared experience so that we
were getting real testing of a common plan for a 2.0 cli vs everyone
building their own 2.0 as they go.

Not to be negative on the cool handy feature, but something to think about
as folks go adding their aliases.

Rick
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Renaming of environments

[Andrew Wilkins]

On Fri, Oct 23, 2015 at 7:31 PM Rick Harding 
wrote:

> That's interesting Andrew and not something considered in the
> conversations around this so far. With the new Azure provider and resource
> groups is the name of that group mutable?
>

Names of resources -- including resource groups -- are immutable in Azure.

For Azure at least the resource groupings should help with the
> tags/identification though it does complicate things for the other
> providers. Are the tags typically not able to be updated?
>

Tags can be updated, we just don't have a good mechanism to do so yet. I
think we'll want to have something that periodically updates tags,
including the environment name. We do record the environment UUID as a tag
(in a few providers), so it shouldn't be too hard to do this.

Maybe we can provide some help to the user to map uuid to the names with
> something like a juju show environment $uuid? and get name and some other
> info back?
>

I think if we keep the tags up-to-date we'll be fine.

Cheers,
Andrew

On Fri, Oct 23, 2015 at 6:33 AM Andrew Wilkins 
> wrote:
>
>> On Fri, Oct 23, 2015 at 3:32 PM John Meinel 
>> wrote:
>>
>>> We can put the environment name in a field that is visible, but isn't
>>> canonical. It depends on the specific use case, but if we can use tags, we
>>> can use "juju-environment-uuid" or some tag like that as the official "what
>>> environment is this in", and then "name" is just a local value, which can
>>> be changed as it isn't a critical piece.
>>>
>>
>> It won't be quite as clear, but I suppose it's a fair price to pay. It
>> would be good if we updated tags for things that change, like this.
>>
>> I'm doing the new Azure provider now, I've updated it so resource names
>> do not include the environment name.
>>
>> Cheers,
>> Andrew
>>
>>
>>> John
>>> =:->
>>>
>>>
>>> On Fri, Oct 23, 2015 at 9:19 AM, Andrew Wilkins <
>>> andrew.wilk...@canonical.com> wrote:
>>>
 On Fri, Oct 23, 2015 at 1:00 PM Menno Smits 
 wrote:

> While working on the environment migrations spec I noticed that it is
> currently not possible to change the name of a Juju environment once it 
> has
> been created. This creates an unfortunate corner case in the context of
> environment migrations, where you might have an environment that can't be
> migrated to another controller because you've already created another
> (unrelated) environment with the same name on the target controller.
>
> Rick pointed out that it would also be nice to be able to rename an
> environment when its purpose has changed. For example, you might have
> created an environment called "test" which you build up and end up using
> for production purposes. At that point the environment name doesn't make
> much sense.
>
> We will fix this. The rename itself is fairly easy to implement but
> environment names have also been used as part of things such as EC2 and
> Openstack security group names so this will need to change too. It would 
> be
> better if the names of external environment-related resources used the
> environment UUID instead. There is a card for this work in Onyx's backlog.
>

 It was specifically requested that we include the environment name in
 resource names for debugging purposes (e.g. I'm looking at the AWS console
 and want to know which Juju machine this instance corresponds to). Some of
 this was done in 1.25, some was pre-existing.

 These requirements are at odds with each other. Just wondering if this
 has been considered.

 Cheers,
 Andrew

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev

 --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

[Aaron Bentley]

bzr has a similar feature, but the problem with such a feature is that
it can break scripts that expect the normal behaviour.  That's why bzr
provides a --no-aliases option, which all scripts calling bzr should use.

The same applies to Juju.  If "status" gets defaulted to "status
--format=tabular", most of our test scripts will break.  This isn't
likely to happen on our test machines, but could easily happen when
devs run our test scripts.

Could you please provide a similar --no-aliases option for juju, so
that we can ensure people don't break our scripts by specifying
surprising defaults?

Thanks,

Aaron

On 2015-10-23 12:12 AM, Tim Penhey wrote:
> Hi folks,
> 
> I scratched a personal itch yesterday and added the ability for
> users to specify their own aliases for juju commands.
> 
> There are two primary use cases that I was trying to address.
> 
> Firstly, the ability to specify default flags for commands: status
> = status --format=tabular
> 
> I could never remember the right environment variable to set to
> get tabular by default.
> 
> The second was to allow quicker iteration around playing with new
> CLI structure.  As most people are aware, the 2.0 CLI is going to
> be somewhat different to the current one, and I thought it would be
> good to provide a way in which we could "test drive" the new CLI
> with the existing codebase without having to actually code
> anything.
> 
> The aliases files lives in JUJU_HOME, and is a simple text file.
> Each non blank line that doesn't start with a '#' is considered to
> be an alias. The format is expected to be:
> 
>  =  [...]
> 
> So we can do things like:
> 
> # stat is like two whole letters shorter... stat = status
> --format=tabular
> 
> # list tests list-environments = system environments list-users =
> user list
> 
> and so on.
> 
> Tim
> 

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju stable 1.25.0 is proposed for release.

[Curtis Hovey-Canonical]

# juju-core 1.25.0

A new proposed stable release of Juju, juju-core 1.25.0, is now available.
This release may replace version 1.24.7 on Thursday October 29.


## Getting Juju

juju-core 1.25.0 is available for Wily and backported to earlier
series in the following PPA:

https://launchpad.net/~juju/+archive/proposed

Windows Centos, and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.25.0

Proposed releases use the "proposed" simple-streams. You must configure
the `agent-stream` option in your environments.yaml to use the matching
juju agents.


## Notable Changes
  * (Experimental) Improved networking features for AWS
* New 'spaces' and 'subnet' commands
* New 'spaces' constraints support
  * Support for "devices" on MAAS 1.8+
  * Storage support for GCE and Azure providers
  * Payload management for charmers


### (Experimental) Improved networking features for AWS

Juju has experimental support for deploying services on AWS in isolation,
taking advantage of the enhanced AWS VPC networking features. This is just a
first step towards a full-fledged networking model support in Juju.


 New 'spaces' and 'subnet' commands

Juju introduces the 'space' and 'subnet' commands to manage the networks
available to services. A Juju network space is a collection of related subnets
that have no firewalls between each other and have the same ingress and egress
policies.

You can create a new Juju space, and optionally associate existing subnets
with it by specifying their CIDRs using the 'create' subcommand. The command
looks like this:

juju space create  [  …]

The list of registered spaces can be seen using the 'list' subcommand:

juju space list [--short] [--format yaml|json] [--output ]

You can add an existing AWS subnet to a space by CIDR or AWS ID, for example:

juju subnet add | 

You can list all the subnets known by Juju and optionally filtering them by
space and/or availability zone like so:

juju subnet list [--zone ] [--space ] [  …]

For more information about these commands, type:

juju  --help


 New 'spaces' constraints support

The new 'spaces' constraint instructs Juju to deploy a service's units in
subnets of the given space.

Similar to the 'tags' constraint, the 'spaces' constraint takes a comma-
delimited list of existing Juju network spaces. Both positive (without prefix)
and negative (prefixed by "^") spaces are allowed in the list. For this alpha
release, the first positive space name is used, the rest is ignored.

You can constrain a service to a space like this:

juju deploy  [] [--constraints "spaces="]

For more information, run

juju help glossary

and

juju help constraints


 Known issues

Deploying a service to a space that has no subnets will cause the agent to
panic and is a known issue (https://launchpad.net/bugs/1499426). This issue
can be mitigated by always adding at least one subnet to the space.


### Support "devices" on MAAS 1.8+

MAAS 1.8 introduced a new feature called "devices". This allows the
association of a "device", that requires an IP address, with a parent machine
managed by MAAS. There is a view in the MAAS UI showing all devices.

With the "address-allocation" feature flag enabled, Juju will register LXC and
KVM containers as devices on MAAS 1.8+. They are visible in the MAAS UI. If
the environment is forcibly shut down, the IP addresses allocated to the
containers will be released by MAAS.

You can enable "address-allocation" is new Juju environments like so:

JUJU_DEV_FEATURE_FLAG=address-allocation juju bootstrap


### Storage support for GCE and Azure providers

Juju's storage feature can now be used with the Google Compute Engine and
Azure providers. Storage is now supported for local, AWS, Openstack, MAAS, GCE
and Azure. See https://jujucharms.com/docs/devel/storage for more information.


### Status for storage volumes

Volumes now have status associated, so provisioning progress can be observed.
List the volumes to see their status:

juju storage volume list


### Payload management for charmers

The new payload management feature allows charmers to more accurately define
large and complex deployments by registering different payloads, such as LXC,
KVM, and docker, with Juju. This lets the operator better understand the
purpose and function of these payloads on a given machine.

You define these payloads in the metadata.yaml of the charm under the
payloads section. You create a class for the payload, "monitoring" or "kvm-
guest", and assign the type.

payloads:
monitoring:
type: docker
kvm-guest:
type: kvm

From your charm hook you can manage your payload with the following
commands:

payload-register[tags]
payload-unregister   
payload-status-set

From the Juju command line you can view your payloads like this:

  juju list-payloads 

For more information run:

juju help payloads

New feature in 1.25.0: Payload Management!

[Katherine Cox-Buday]

Hey All,

Moonstone have been working hard this cycle on delivering a way to manage 
payloads from within a Juju Charm, and providing a nice way to expose 
information about the payloads through the Juju client. We got off course for a 
bit there, but with the help of Mark and some others, we're very happy to 
announce that this work has landed in v1.25.0 (now in proposed)!

Throughout work on this feature, we've worked very closely with our amazing 
Ecosystems team, and we're happy to point you all to a blog post[1] Chuck 
(lazypower) put together demonstrating a charm he's written utilizing payload 
management (as well as our awesome new reactive charming!). The payload 
management stuff starts @ 3:40 in Chuck's video[2], but it's only 6 minutes 
long, so go ahead and watch the entire thing :)

Enjoy, and let me know if you have any questions!

-
Katherine

[1] http://blog.dasroot.net/2015-charming-2-point-oh.html
[2] https://youtu.be/aRQcERLnbIQ?t=221

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev