Re: Juju devel 1.26-alpha2 is available for testing

[Marco Ceppi]

Okay, but I've added the LXD daily/stable PPA which installed `go version
go1.5.1 linux/amd64`. My question is, are the LXD features locked to an
Ubuntu release or is it dependent on checking platform ability at run time?
My point being, I have a trusty machine which has a more recent version of
golang and the latest stable LXD software installed. If Juju won't work
simply because it's trusty then I need to file a bug before 1.26.0 lands.

Marco

On Fri, Nov 27, 2015 at 11:04 AM Aaron Bentley 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 2015-11-27 11:00 AM, Marco Ceppi wrote:
> > - Running Wily (LXD is installed by default)
> >
> >
> > For the LXD provider, I have the latest LXD installed on trusty,
> > will that work or is it hard-coded to wily+ ?
>
> It will not work.  Only platforms with Go 1.3 will work, because the
> LXD provider only builds with Go 1.3+.  See "Upgrading minimum Go
> version" in juju-dev for more discussion.
>
> Aaron
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJWWH75AAoJEK84cMOcf+9hWDwH/iuVczXD8UpRv1KZeXLK7AQC
> vaNY5jaUSwS3+lKGGimEdHHNwrMjH5FxEnMGqvQctRNbIgudCorL7nxEhM1J++3U
> vTus0MAe/le82t5PIos/wKHl4mNhVpxHA1x/mKmSW4CIiiA7us1v8ZOCxg/DKQen
> a+r6+/F8sne/2Q92dyIj02Vy/RN0HTKBz/3Royu0HZgdRbsJVpHaNObglvAbCbdc
> gErAMNPkzChiVceYAciqHUrmDA6FzeOB6Ep7J0kboIxJLiFf0oed0+z0Nt9qeMBE
> a+dJx+767D2B8iavpqr9thnIeoSqvH57Qzbaxev6sxnW2cQCHTN5PEY9hkODFy0=
> =dYa5
> -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: Juju devel 1.26-alpha2 is available for testing

[Marco Ceppi]

Okay, but I've added the LXD daily/stable PPA which installed `go version
go1.5.1 linux/amd64`. My question is, are the LXD features locked to an
Ubuntu release or is it dependent on checking platform ability at run time?
My point being, I have a trusty machine which has a more recent version of
golang and the latest stable LXD software installed. If Juju won't work
simply because it's trusty then I need to file a bug before 1.26.0 lands.

Marco

On Fri, Nov 27, 2015 at 11:04 AM Aaron Bentley 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 2015-11-27 11:00 AM, Marco Ceppi wrote:
> > - Running Wily (LXD is installed by default)
> >
> >
> > For the LXD provider, I have the latest LXD installed on trusty,
> > will that work or is it hard-coded to wily+ ?
>
> It will not work.  Only platforms with Go 1.3 will work, because the
> LXD provider only builds with Go 1.3+.  See "Upgrading minimum Go
> version" in juju-dev for more discussion.
>
> Aaron
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJWWH75AAoJEK84cMOcf+9hWDwH/iuVczXD8UpRv1KZeXLK7AQC
> vaNY5jaUSwS3+lKGGimEdHHNwrMjH5FxEnMGqvQctRNbIgudCorL7nxEhM1J++3U
> vTus0MAe/le82t5PIos/wKHl4mNhVpxHA1x/mKmSW4CIiiA7us1v8ZOCxg/DKQen
> a+r6+/F8sne/2Q92dyIj02Vy/RN0HTKBz/3Royu0HZgdRbsJVpHaNObglvAbCbdc
> gErAMNPkzChiVceYAciqHUrmDA6FzeOB6Ep7J0kboIxJLiFf0oed0+z0Nt9qeMBE
> a+dJx+767D2B8iavpqr9thnIeoSqvH57Qzbaxev6sxnW2cQCHTN5PEY9hkODFy0=
> =dYa5
> -END PGP SIGNATURE-
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju devel 1.26-alpha2 is available for testing

[Mark Shuttleworth]

On 27/11/15 16:21, Aaron Bentley wrote:
> It's dependent on what compiler was used to create the jujud binary.
> AIUI, the Ubuntu policy is that nothing goes into a distroseries which
> cannot be compiled with the tools in that distroseries.  Thus the
> jujud for Trusty is compiled with the version of Go provided by that
> platform.

My understanding is that a Go 1.5 backport to Trusty is part of the
current cycle planned work.

Mark


signature.asc
Description: OpenPGP digital signature
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju devel 1.26-alpha2 is available for testing

[Eric Snow]

On Fri, Nov 27, 2015 at 9:00 AM, Marco Ceppi  wrote:
> On Fri, Nov 27, 2015 at 9:37 AM Aaron Bentley 
> wrote:
>>  Requirements
>>
>> - Running Wily (LXD is installed by default)
>>
>
> For the LXD provider, I have the latest LXD installed on trusty, will that
> work or is it hard-coded to wily+ ?

It will work fine if using a juju built with Go 1.3+ (e.g. the juju
package on wily or building locally and using --upload-tools).  The
provider uses the LXD Go bindings which require Go 1.3+.  It is a
compile-time issue rather than a run-time check.

Until trusty ships with Go 1.3+ we cannot ship a Juju that depends on
the LXD Go bindings, thus the LXD provider is disabled if Juju is
compiled with anything older than Go 1.3.  As Aaron said, there's a
separate thread discussing how to solve the problem of getting the
latest full-featured Juju on trusty.

-eric

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

Re: Juju devel 1.26-alpha2 is available for testing

[Eric Snow]

On Fri, Nov 27, 2015 at 9:00 AM, Marco Ceppi  wrote:
> On Fri, Nov 27, 2015 at 9:37 AM Aaron Bentley 
> wrote:
>>  Requirements
>>
>> - Running Wily (LXD is installed by default)
>>
>
> For the LXD provider, I have the latest LXD installed on trusty, will that
> work or is it hard-coded to wily+ ?

It will work fine if using a juju built with Go 1.3+ (e.g. the juju
package on wily or building locally and using --upload-tools).  The
provider uses the LXD Go bindings which require Go 1.3+.  It is a
compile-time issue rather than a run-time check.

Until trusty ships with Go 1.3+ we cannot ship a Juju that depends on
the LXD Go bindings, thus the LXD provider is disabled if Juju is
compiled with anything older than Go 1.3.  As Aaron said, there's a
separate thread discussing how to solve the problem of getting the
latest full-featured Juju on trusty.

-eric

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

Re: Juju devel 1.26-alpha2 is available for testing

[Pshem Kowalczyk]

Hi,

Does this version support MAAS fabrics/subnets ?

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

Re: Juju devel 1.26-alpha2 is available for testing

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2015-11-27 11:10 AM, Marco Ceppi wrote:
> Okay, but I've added the LXD daily/stable PPA which installed `go 
> version go1.5.1 linux/amd64`. My question is, are the LXD features 
> locked to an Ubuntu release or is it dependent on checking
> platform ability at run time?

It's dependent on what compiler was used to create the jujud binary.
AIUI, the Ubuntu policy is that nothing goes into a distroseries which
cannot be compiled with the tools in that distroseries.  Thus the
jujud for Trusty is compiled with the version of Go provided by that
platform.

> My point being, I have a trusty machine which has a more recent
> version of golang and the latest stable LXD software installed. If
> Juju won't work simply because it's trusty then I need to file a
> bug before 1.26.0 lands.

I recommend contributing to the "Upgrading minimum Go version" thread.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWWIMlAAoJEK84cMOcf+9h/GEH/0ftpREnqycLI0MM2bw7VjmM
LZw2dNfiyhnKQNYWlupjMOEYDJoTRwVrvI7fd0mpMTbM83060Jk66caMMsUF64Da
9pMBU9B5G8jIcrHc4JApSStfJOcHPX7rtnYcuCVET0XOEXSimLdpg+06jzU+3zYB
ByM5mCjWNGX33RUzbI96mJypyLy1nqPuJS0d7MXFSGu1U3LTniiCBZIlRJtXtnNt
9QRf86J7ERLLoH2fbL2DBPk5yN9s5X44/izDySBsxDYzzhqNpg6QPReQthRU1Ovh
QyJSFx4lVlaQMhGgrOEz4X+3LzU6A0MFIybivZ60LDWnJ1wvOKrKBC12lxjzIsg=
=xMRG
-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: Juju devel 1.26-alpha2 is available for testing

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2015-11-27 11:00 AM, Marco Ceppi wrote:
> - Running Wily (LXD is installed by default)
> 
> 
> For the LXD provider, I have the latest LXD installed on trusty,
> will that work or is it hard-coded to wily+ ?

It will not work.  Only platforms with Go 1.3 will work, because the
LXD provider only builds with Go 1.3+.  See "Upgrading minimum Go
version" in juju-dev for more discussion.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWWH75AAoJEK84cMOcf+9hWDwH/iuVczXD8UpRv1KZeXLK7AQC
vaNY5jaUSwS3+lKGGimEdHHNwrMjH5FxEnMGqvQctRNbIgudCorL7nxEhM1J++3U
vTus0MAe/le82t5PIos/wKHl4mNhVpxHA1x/mKmSW4CIiiA7us1v8ZOCxg/DKQen
a+r6+/F8sne/2Q92dyIj02Vy/RN0HTKBz/3Royu0HZgdRbsJVpHaNObglvAbCbdc
gErAMNPkzChiVceYAciqHUrmDA6FzeOB6Ep7J0kboIxJLiFf0oed0+z0Nt9qeMBE
a+dJx+767D2B8iavpqr9thnIeoSqvH57Qzbaxev6sxnW2cQCHTN5PEY9hkODFy0=
=dYa5
-END PGP SIGNATURE-

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

Re: Juju devel 1.26-alpha2 is available for testing

[Rick Harding]

On Fri, Nov 27, 2015 at 11:35 AM Mark Shuttleworth  wrote:

> On 27/11/15 16:21, Aaron Bentley wrote:
>
> It's dependent on what compiler was used to create the jujud binary.
> AIUI, the Ubuntu policy is that nothing goes into a distroseries which
> cannot be compiled with the tools in that distroseries.  Thus the
> jujud for Trusty is compiled with the version of Go provided by that
> platform.
>
>
> My understanding is that a Go 1.5 backport to Trusty is part of the
> current cycle planned work.
>

Yes, the work for Go 1.5 into Trusty moves forward. For this alpha it's not
yet ready to provide the build so my understanding is that the alpha build
for Trusty is done with the current outdated tool chain. Once the Go
toolchain is updated for Trusty the builds released will be in order.

Aaron, please correct me if I'm mistaken there.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju devel 1.26-alpha2 is available for testing

[Marco Ceppi]

On Fri, Nov 27, 2015 at 9:37 AM Aaron Bentley 
wrote:

> # juju-core 1.26-alpha2
>

This is probably the most anticipated release of the year. Looking forward
to trying out all the new features!


> ### LXD Provider
>
> The new LXD provider is the best way to use Juju locally.
>
> The state-server is no longer your host machine; it is now a LXC
> container. This keeps your host machine clean and allows you to utilize
> your local environment more like a traditional Juju environment. Because
> of this, you can test things like Juju high-availability without needing
> to utilize a cloud provider.
>
> The previous local provider remains functional for backwards
> compatibility.
>
>  Requirements
>
> - Running Wily (LXD is installed by default)
>
>
For the LXD provider, I have the latest LXD installed on trusty, will that
work or is it hard-coded to wily+ ?


> - Import the LXD cloud-images that you intend to deploy and register
>   an alias:
>
>   lxd-images import ubuntu trusty --alias ubuntu-trusty
>   lxd-images import ubuntu wily --alias ubuntu-wily
>
>   or register an alias for your existing cloud-images
>
>   lxc image alias create ubuntu-trusty 
>   lxc image alias create ubuntu-wily 
>
> - For alpha2, you must specify the "--upload-tools" flag when
>   bootstrapping the environment that will use trusty cloud-images.
>   This is because most of Juju's charms are for Trusty, and the
>   agent-tools for Trusty don't yet have LXD support compiled in.
>
> juju bootstrap --upload-tools
>
> "--upload-tools" is not required for deploying a wily state-server and
> wily services.
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju devel 1.26-alpha2 is available for testing

[Marco Ceppi]

On Fri, Nov 27, 2015 at 9:37 AM Aaron Bentley 
wrote:

> # juju-core 1.26-alpha2
>

This is probably the most anticipated release of the year. Looking forward
to trying out all the new features!


> ### LXD Provider
>
> The new LXD provider is the best way to use Juju locally.
>
> The state-server is no longer your host machine; it is now a LXC
> container. This keeps your host machine clean and allows you to utilize
> your local environment more like a traditional Juju environment. Because
> of this, you can test things like Juju high-availability without needing
> to utilize a cloud provider.
>
> The previous local provider remains functional for backwards
> compatibility.
>
>  Requirements
>
> - Running Wily (LXD is installed by default)
>
>
For the LXD provider, I have the latest LXD installed on trusty, will that
work or is it hard-coded to wily+ ?


> - Import the LXD cloud-images that you intend to deploy and register
>   an alias:
>
>   lxd-images import ubuntu trusty --alias ubuntu-trusty
>   lxd-images import ubuntu wily --alias ubuntu-wily
>
>   or register an alias for your existing cloud-images
>
>   lxc image alias create ubuntu-trusty 
>   lxc image alias create ubuntu-wily 
>
> - For alpha2, you must specify the "--upload-tools" flag when
>   bootstrapping the environment that will use trusty cloud-images.
>   This is because most of Juju's charms are for Trusty, and the
>   agent-tools for Trusty don't yet have LXD support compiled in.
>
> juju bootstrap --upload-tools
>
> "--upload-tools" is not required for deploying a wily state-server and
> wily services.
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: [ANN] charm-tools 1.9.3

[Marco Ceppi]

On Thu, Nov 26, 2015 at 3:05 AM Simon Davy  wrote:

> On Thursday, 26 November 2015, Marco Ceppi 
> wrote:
> > On Wed, Nov 25, 2015 at 4:08 PM Simon Davy 
> wrote:
> >>
> >> On 25 November 2015 at 16:02, Marco Ceppi 
> wrote:
> >> > ## Wheel House for layer dependencies
> >> >
> >> > Going forward we recommend all dependencies for layers and charms be
> >> > packaged in a wheelhouse.txt file. This perform the installation of
> pypi
> >> > packages on the unit instead of first on the local machine meaning
> Python
> >> > libraries that require architecture specific builds will do it on the
> units
> >> > architecture.
> >>
> >> If I'm understanding the above correctly, this approach is a blocker
> for us.
> >>
> >> We would not want to install direct from pypi on a production service
> >>
> >>  1) pypi packages are not signed (or when they are, pip doesn't verify
> >> the signature)
> >>  2) pypi is an external dependency and thus unreliable (although not
> >> as bad these days)
> >>  3) old versions can disappear from pypi at an authors whim.
> >>  4) installing c packages involves installing a c toolchain on your
> prod machine
> >>
> >> Additionally, our policy (Canonical's, that is), does not allow access
> >> to the internet on production machines, for very good reasons. This is
> >> the default policy in many (probably most) production environments.
> >>
> >> Any layer or charm that consumes a layer that uses this new approach
> >> for dependencies would thus be unusable to us :(
> >>
> >> It also harms repeatability, and I would not want to use it even if
> >> our access policy allowed access to pypi.
> >>
> >> For python charm dependencies, we use system python packages as much
> >> as possible, or if we need any wheels, we ship that wheel in the
> >> charm, and pip install it directly from the there. No external
> >> network, completely repeatable.
> >
> > So, allow me to clarify. If you review the pastebin outputs from the
> original announcement email, what this shift does is previously `charm
> build` would create and embed installed dependencies into the charm under
> lib/ much like charm-helper-sync did for instead for any arbitrary Pypi
> dependency. Issues there are for PyYAML it will build a yaml.so file which
> would be built based on the architecture of your machine and not the cloud.
>
> Right. This was the bit which confused me, I think.
>
> Can we not just use python-yaml, as its installed by default on cloud
> images anyway?
>
> We use virtualenv with --system-site-packages, and use system packages for
> python libs with c packages where possible, leaving wheels for things which
> aren't packaged or we want newer versions of.
>
>
Again, this is for hook dependencies, not exactly for dependencies of the
workload. The charm could apt intall python-yaml, but using
--system-site-packages when building is something I'd discourage since not
everyone has the same apt pacakges installed. Unless that user is building
on a fresh cloud-image there's a chance they won't catch some packages that
don't get declared.

We'd be interested in making this a better story. The wheelhousing for
dependencies not yet available in the archive instead of embedding them in
the charm was a first step but certainly not the last. I'm not sure how
this would work when we generate a wheelhouse since the wheelhouse
generation grabs dependencies of the install. That's why PyYAML is showing
up in the generated charm artifact. We're not explicitly saying "included
PyYAML" we're simply saying we need charmhelpers and charms.reactive from
PyPI as a minimum dependency for all charm hooks built with charm build to
work. Suggestions around this are welcome.

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

Re: Juju devel 1.26-alpha2 is available for testing

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2015-11-27 11:00 AM, Marco Ceppi wrote:
> - Running Wily (LXD is installed by default)
> 
> 
> For the LXD provider, I have the latest LXD installed on trusty,
> will that work or is it hard-coded to wily+ ?

It will not work.  Only platforms with Go 1.3 will work, because the
LXD provider only builds with Go 1.3+.  See "Upgrading minimum Go
version" in juju-dev for more discussion.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWWH75AAoJEK84cMOcf+9hWDwH/iuVczXD8UpRv1KZeXLK7AQC
vaNY5jaUSwS3+lKGGimEdHHNwrMjH5FxEnMGqvQctRNbIgudCorL7nxEhM1J++3U
vTus0MAe/le82t5PIos/wKHl4mNhVpxHA1x/mKmSW4CIiiA7us1v8ZOCxg/DKQen
a+r6+/F8sne/2Q92dyIj02Vy/RN0HTKBz/3Royu0HZgdRbsJVpHaNObglvAbCbdc
gErAMNPkzChiVceYAciqHUrmDA6FzeOB6Ep7J0kboIxJLiFf0oed0+z0Nt9qeMBE
a+dJx+767D2B8iavpqr9thnIeoSqvH57Qzbaxev6sxnW2cQCHTN5PEY9hkODFy0=
=dYa5
-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

Juju devel 1.26-alpha2 is available for testing

[Aaron Bentley]

# juju-core 1.26-alpha2

A new development release of Juju, juju-core 1.26-alpha2, is now
available.
This release replaces version 1.26-alpha1.


## Getting Juju

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

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

Windows and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.26-alpha2

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

Upgrading from stable releases to development releases is not
supported. You can upgrade test environments to development releases
to test new features and fixes, but it is not advised to upgrade
production environments to 1.26-alpha2.


## Notable Changes

* Native support for charm bundles
* Unit agent improvements
* API login with macaroons
* LXD Provider
* Microsoft Azure Resource Manager provider

### Native support for charm bundles

The Juju 'deploy' command can now deploy a bundle. The Juju Quickstart
or Deployer plugins are not needed to deploy a bundle of charms. You can
deploy the mediawiki-single bundle like so:

juju deploy cs:bundle/mediawiki-single

Local bundles can be deployed by passing the path to the bundle. For
example:

juju deploy ./openstack/bundle.yaml

Local bundles can also be deployed from a local repository. Bundles
reside in the "bundle" subdirectory. For example, your local juju
repository might look like this:

juju-repo/
 |
 - trusty/
 - bundle/
   |
   - openstack/
 |
 - bundle.yaml

and you can deploy the bundle like so:

export JUJU_REPOSITORY="$HOME/juju-repo"
juju deploy local:bundle/openstack

Bundles, when deployed from the command line like this, now support
storage constraints. To specify how to allocate storage for a service, you
can add a "storage" key underneath a service, and under "storage" add a
key for each store you want to allocate, along with the constraints. e.g.
say you're deploying ceph-osd, and you want each unit to have a 50GiB
disk:

ceph-osd:
...
storage:
osd-devices: 50G

Because a bundle should work across cloud providers, the constraints in
the bundle should not specify a pool/storage provider, and just use the
default for the cloud. To customize how storage is allocated, you can use
the "--storage" flag with a new bundle-specific format: --storage
service:store=constraints. e.g. say you you're deploying OpenStack, and
you want each unit of ceph-osd to have 3x50GiB disks:

juju deploy ./openstack/bundle.yaml --storage
ceph-osd:osd-devices=3,50G


### Unit agent improvements

We've made improvements to worker lifecycle management in the unit agent
in this release. The resource dependencies (API connections, locks,
etc.) shared among concurrent workers that comprise the agent are now
well-defined, modeled and coordinated by an engine, in a design inspired
by Erlang supervisor trees.

This improves the long-term testability of the unit agent, and should
improve the agent's resilience to failure. This work also allows hook
contexts to execute concurrently, which supports features in development
targeting 2.0.


### API login with macaroons

Added an alternative API login method based on macaroons in support of a
new charm publishing workflow targeting 16.04.


### LXD Provider

The new LXD provider is the best way to use Juju locally.

The state-server is no longer your host machine; it is now a LXC
container. This keeps your host machine clean and allows you to utilize
your local environment more like a traditional Juju environment. Because
of this, you can test things like Juju high-availability without needing
to utilize a cloud provider.

The previous local provider remains functional for backwards
compatibility.

 Requirements

- Running Wily (LXD is installed by default)

- Import the LXD cloud-images that you intend to deploy and register
  an alias:

  lxd-images import ubuntu trusty --alias ubuntu-trusty
  lxd-images import ubuntu wily --alias ubuntu-wily

  or register an alias for your existing cloud-images

  lxc image alias create ubuntu-trusty 
  lxc image alias create ubuntu-wily 

- For alpha2, you must specify the "--upload-tools" flag when
  bootstrapping the environment that will use trusty cloud-images.
  This is because most of Juju's charms are for Trusty, and the
  agent-tools for Trusty don't yet have LXD support compiled in.

juju bootstrap --upload-tools

"--upload-tools" is not required for deploying a wily state-server and
wily services.


 Specifying a LXD Environment

In you environments.yaml, you'll now find a block for LXD providers:

lxd:
type: lxd
# namespace identifies the namespace to associate with containers
# created by the provider.  It is prepended to the container names.
# By default the environment's name 

Re: Unit name issue with SFTP command.

[Cory Johns]

You can get the full unit name with:

unit_name = d.sentry['ibm-db2'][0].info['unit_name']
d.action_do(unit_name, ...)

We should perhaps consider moving action_do to the UnitSentry so that it
could instead be called as:

   d.sentry['ibm-db2'][0].action_do(...)

On Fri, Nov 27, 2015 at 1:38 AM, Sunitha Radharapu 
wrote:

> HI,
>
> We have action_do function to download the packages from the repository in
> our amulet test as follows.
> * uuid = d.action_do('ibm-db2/0', 'download', {"username":
> config.get('ibm-repo').get('sftp_user_name'), "password":
> config.get('ibm-repo').get('sftp_password'), "packagename":
> config.get('ibm-repo').get('package_name'), "host":
> config.get('ibm-repo').get('sftp_host')})*
>
> With newer version of juju we cannot give the unit name like ibm-db2/0 as
> the unit names keeps increasing sequentially with multiple deployment.
> We tried to get the unit name as follows and passed it to action_do
> function, but it threw error.
>
> *db2_unit1 = d.sentry['ibm-db2'][0]*
> * uuid = d.action_do(db2_unit1, 'download', {"username":
> config.get('ibm-repo').get('sftp_user_name'), "password":
> config.get('ibm-repo').get('sftp_password'), "packagename":
> config.get('ibm-repo').get('package_name'), "host":
> config.get('ibm-repo').get('sftp_host')})*
>
>
>
> The error we got is :
>
>
> *==*
> *ERROR: setUpClass (__main__.BundleTest)*
> *--*
> *Traceback (most recent call last):*
> * File "tests/10-bundles-test.py", line 47, in setUpClass*
> * uuid = d.action_do(db2_unit1, 'download', {"username":
> config.get('ibm-repo').get('sftp_user_name'), "password":
> config.get('ibm-repo').get('sftp_password'), "packagename":
> config.get('ibm-repo').get('package_name'), "host":
> config.get('ibm-repo').get('sftp_host')})*
> * File "/usr/lib/python2.7/dist-packages/amulet/deployer.py", line 372, in
> action_do*
> * if '/' not in unit:*
> *TypeError: argument of type 'UnitSentry' is not iterable*
>
>
>
> The action_do function in the above in .py file is defined as follows:
>
> def action_do(self, unit, action, action_args={}):
> """
> :param unit: Unit to run action on.
> :param action: Action to run.
> :param action_args: Action parameters.
>
> Runs specified action on specified unit and returns the uuid to fetch
> results by.
>
> """
> if '/' not in unit:
> raise ValueError('%s is not a unit' % unit)
> cmd = ['action', 'do', unit, action, '--format', 'json']
> for key, value in action_args.items():
> cmd += ["%s=%s" % (str(key), str(value))]
> result = juju(cmd)
> action_result = json.loads(result)
> results_id = action_result["Action queued with id"]
> return results_id
>
>
> From this we understand that "/" is required in the unitname for action to
> work .
>
> How do we resolve this issue in latest version of Juju. Is it a limitation
> in the newer version for using action commands inside amulet test ?
>
>
> Thanks,
> Sunitha.
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [ANN] charm-tools 1.9.3

[Simon Davy]

On Friday, 27 November 2015, Marco Ceppi  wrote:
> On Thu, Nov 26, 2015 at 3:05 AM Simon Davy  wrote:
>>
>> On Thursday, 26 November 2015, Marco Ceppi 
wrote:
>> > On Wed, Nov 25, 2015 at 4:08 PM Simon Davy 
wrote:
>> >>
>> >> On 25 November 2015 at 16:02, Marco Ceppi 
wrote:
>> >> > ## Wheel House for layer dependencies
>> >> >
>> >> > Going forward we recommend all dependencies for layers and charms be
>> >> > packaged in a wheelhouse.txt file. This perform the installation of
pypi
>> >> > packages on the unit instead of first on the local machine meaning
Python
>> >> > libraries that require architecture specific builds will do it on
the units
>> >> > architecture.
>> >>
>> >> If I'm understanding the above correctly, this approach is a blocker
for us.
>> >>
>> >> We would not want to install direct from pypi on a production service
>> >>
>> >>  1) pypi packages are not signed (or when they are, pip doesn't verify
>> >> the signature)
>> >>  2) pypi is an external dependency and thus unreliable (although not
>> >> as bad these days)
>> >>  3) old versions can disappear from pypi at an authors whim.
>> >>  4) installing c packages involves installing a c toolchain on your
prod machine
>> >>
>> >> Additionally, our policy (Canonical's, that is), does not allow access
>> >> to the internet on production machines, for very good reasons. This is
>> >> the default policy in many (probably most) production environments.
>> >>
>> >> Any layer or charm that consumes a layer that uses this new approach
>> >> for dependencies would thus be unusable to us :(
>> >>
>> >> It also harms repeatability, and I would not want to use it even if
>> >> our access policy allowed access to pypi.
>> >>
>> >> For python charm dependencies, we use system python packages as much
>> >> as possible, or if we need any wheels, we ship that wheel in the
>> >> charm, and pip install it directly from the there. No external
>> >> network, completely repeatable.
>> >
>> > So, allow me to clarify. If you review the pastebin outputs from the
original announcement email, what this shift does is previously `charm
build` would create and embed installed dependencies into the charm under
lib/ much like charm-helper-sync did for instead for any arbitrary Pypi
dependency. Issues there are for PyYAML it will build a yaml.so file which
would be built based on the architecture of your machine and not the cloud.
>>
>> Right. This was the bit which confused me, I think.
>>
>> Can we not just use python-yaml, as its installed by default on cloud
images anyway?
>>
>> We use virtualenv with --system-site-packages, and use system packages
for python libs with c packages where possible, leaving wheels for things
which aren't packaged or we want newer versions of.
>>
>
> Again, this is for hook dependencies, not exactly for dependencies of the
workload.

Right. I understand that :)

I detailed how we solve this for our python app payloads as a possible
solution for how to solve it for python charm deps also, but of course
those deps would be completely separate things, not even installed in the
same virtualenv.


> The charm could apt intall python-yaml, but using --system-site-packages
when building is something I'd discourage since not everyone has the same
apt pacakges installed.

Except that they do specifically have python-yaml installed, I believe. Its
installed by default in Ubuntu cloud images, due to cloud-init I think.

But yes, other system python packages could be exposed. I wish once again
there was a way to include specific list of system packages in a virtualenv
rather than all them.

And it should be easy enough to add a way to declare which system packages
are required by a layer?

>Unless that user is building on a fresh cloud-image there's a chance they
won't catch some packages that don't get declared.
> We'd be interested in making this a better story. The wheelhousing for
dependencies not yet available in the archive instead of embedding them in
the charm was a first step but certainly not the last. I'm not sure how
this would work when we generate a wheelhouse since the wheelhouse
generation grabs dependencies of the install. That's why PyYAML is showing
up in the generated charm artifact. We're not explicitly saying "included
PyYAML" we're simply saying we need charmhelpers and charms.reactive from
PyPI as a minimum dependency for all charm hooks built with charm build to
work. Suggestions around this are welcome.

Right, the wheelhouse seems a good approach for that. I'm just wondering if
we can do a specific solution for python-yaml that avoids the binary wheel
(which AIUI is brittle even on same arch, due to glibc/cc verions)

I would be surprised if there were many charm python deeps that had c
extensions ?

Also, iirc there is a pure python yaml lib? Given speed is not an issue
here (as the yaml is