lxd provider in master

[Tim Penhey]

Hi all,

I noticed that the lxd provider was now in master and attempted to use
it to help debug an HA problem.

In environments.yaml file I added a very simple clause:

   lxd:
  type: lxd

But when I try to bootstrap, I get the following:

$ juju bootstrap --debug
2015-11-23 03:26:14 INFO juju.cmd supercommand.go:58 running juju
[1.26-alpha2 gc]
2015-11-23 03:26:14 DEBUG juju.environs.config config.go:1473 coercion
failed attributes: map[string]interface {}{"namespace":"tim-lxd",
"container":"lxd"}, checker:
schema.fieldMapC{fields:schema.Fields{"container":environschema.oneOfValuesChecker{vals:[]interface
{}{"lxc", "kvm"}, checker:schema.stringC{}},
"storage-port":schema.forceIntC{}, "namespace":schema.stringC{},
"root-dir":schema.stringC{}, "bootstrap-ip":schema.stringC{},
"network-bridge":schema.stringC{}},
defaults:schema.Defaults{"container":"lxc",
"bootstrap-ip":schema.omit{}, "storage-port":8040, "namespace":"",
"root-dir":"", "network-bridge":""}, strict:false}, container: expected
one of [lxc kvm], got "lxd"
2015-11-23 03:26:14 DEBUG juju.cmd.juju common.go:96 Destroying
environment info.
2015-11-23 03:26:14 INFO cmd cmd.go:129 Bootstrap failed, cleaning up
the environment.
2015-11-23 03:26:14 ERROR cmd supercommand.go:448 there was an issue
examining the environment: failed to validate unknown attrs: container:
expected one of [lxc kvm], got "lxd"

I have lxd installed (on trusty):

$ apt-cache policy lxd
lxd:
  Installed: 0.22-0ubuntu2~ubuntu14.04.1~ppa1
  Candidate: 0.22-0ubuntu2~ubuntu14.04.1~ppa1
  Version table:
 0.22-0ubuntu2~ubuntu14.04.1 0
100 http://archive.ubuntu.com/ubuntu/ trusty-backports/universe
amd64 Packages
 *** 0.22-0ubuntu2~ubuntu14.04.1~ppa1 0
500 http://ppa.launchpad.net/ubuntu-lxc/lxd-stable/ubuntu/
trusty/main amd64 Packages
100 /var/lib/dpkg/status


There appears to be no feature flag for the lxd provider, so what am I
missing?

Cheers,
Tim

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

Re: lxd provider in master

[Tim Penhey]

On 23/11/15 16:59, Andrew Wilkins wrote:
> On Mon, Nov 23, 2015 at 11:50 AM Tim Penhey  There appears to be no feature flag for the lxd provider, so what am I
> missing?
> 
> 
> Have you added yourself to the lxd group? ("newgrp lxd")

Yes, I've had lxd installed for some time.

$ groups
tim adm cdrom sudo dip plugdev lpadmin sambashare vboxusers wireshark
autopilot libvirtd lxd thumper


Tim

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

Re: [Ecosystem-engineering] The future of Charm Helpers

[Adam Israel]

I am very much in favor of this move forward. I’ve recently worked on 
converting the charm-benchmark package to charms.benchmark; I see where having 
cleaner namespaces make will make every charm author’s life easier.

That said, I know that transitioning to this new model is an epic undertaking, 
especially with the changes coming in the next LTS, i.e., no python 2 by 
default. To that end, I’d propose some kind of compatibility report be 
generated (as part of the upgraded CI, perhaps) that notifies charm authors of 
upcoming changes and how their charm fares against the new requirements. The 
last thing I want to see as a ~charmer is Xenial come to pass and having to 
engage in firefighter mode to fix incompatibilities.


Adam Israel - Software Engineer
Canonical Ltd.
http://juju.ubuntu.com/ - Automate your Cloud Infrastructure

> On Nov 22, 2015, at 2:23 PM, Marco Ceppi  wrote:
> 
> Hello everyone,
> 
> I'm rebooting this conversation because it never fully came to a resolution 
> and since this topic was discussed a lot has happened in the Charm Ecosystem. 
> I still hold firm, and a lot of charmers I've spoken with agree, that charm 
> helpers has become the opposite which it originally helped to solve - a 
> concise and tasteful way to bind Python to Juju. I've been considering ways 
> to resolve this, providing a clear way for users to author Python charms, 
> while not diminishing the large breadth of helpers and methods already 
> created.
> 
> A new approach I'd like to present is a clean break from the "charm-helpers" 
> name and a transition to a new library, `charms.helper`. This name follows 
> the same scheme that the reactive framework does, `charms.reactive` and is a 
> way we can continue the practice of producing helpers around the charm 
> ecosystem without the need of a monolithic code base.
> 
> Under this proposal, `charmhelpers.core.hookenv` would more or less become 
> `charms.helper` and items like `charmhelpers.contrib.openstack` would be 
> moved to their own upstream project and be available as `charms.openstack`. 
> They will instead depend on `charms.helper` for previous `hookenv` methods. 
> This is a cleaner namespace that still providing the discoverability (search 
> pypi index for `charms` and you'll see the ecosystem basically owns that 
> space) desired from the current source tree.
> 
> This clean break will allow us to correct a few naming mistmatches and allow 
> us to incubate a transition period where charm authors can use and try these 
> but the current charm-helpers library has charms.helper as a dependency and 
> map current `charmhelpers.core.hookenv` to the new `charms.helper`. I've 
> already started work on a strawman to demonstrate how charms.helper could 
> look and will share that later this week.
> 
> With the new charm build pattern and reactive framework this would fit in 
> nicely as we continue on a "charming 2.0" march for quick, easy, and concise 
> ways to create charms. I welcome a continued discussion on the subject with 
> the hope we can reach a consensus soon on the best way forward. One thing is 
> clear, the current way of maintaining charm-helpers is neither scalable or 
> manageable.
> 
> Thanks,
> Marco Ceppi
> -- 
> Mailing list: https://launchpad.net/~ecosystem-engineering
> Post to : ecosystem-engineer...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ecosystem-engineering
> More help   : https://help.launchpad.net/ListHelp


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

Re: lxd provider in master

[Andrew Wilkins]

On Mon, Nov 23, 2015 at 11:50 AM Tim Penhey 
wrote:

> Hi all,
>
> I noticed that the lxd provider was now in master and attempted to use
> it to help debug an HA problem.
>
> In environments.yaml file I added a very simple clause:
>
>lxd:
>   type: lxd
>
> But when I try to bootstrap, I get the following:
>
> $ juju bootstrap --debug
> 2015-11-23 03:26:14 INFO juju.cmd supercommand.go:58 running juju
> [1.26-alpha2 gc]
> 2015-11-23 03:26:14 DEBUG juju.environs.config config.go:1473 coercion
> failed attributes: map[string]interface {}{"namespace":"tim-lxd",
> "container":"lxd"}, checker:
>
> schema.fieldMapC{fields:schema.Fields{"container":environschema.oneOfValuesChecker{vals:[]interface
> {}{"lxc", "kvm"}, checker:schema.stringC{}},
> "storage-port":schema.forceIntC{}, "namespace":schema.stringC{},
> "root-dir":schema.stringC{}, "bootstrap-ip":schema.stringC{},
> "network-bridge":schema.stringC{}},
> defaults:schema.Defaults{"container":"lxc",
> "bootstrap-ip":schema.omit{}, "storage-port":8040, "namespace":"",
> "root-dir":"", "network-bridge":""}, strict:false}, container: expected
> one of [lxc kvm], got "lxd"
> 2015-11-23 03:26:14 DEBUG juju.cmd.juju common.go:96 Destroying
> environment info.
> 2015-11-23 03:26:14 INFO cmd cmd.go:129 Bootstrap failed, cleaning up
> the environment.
> 2015-11-23 03:26:14 ERROR cmd supercommand.go:448 there was an issue
> examining the environment: failed to validate unknown attrs: container:
> expected one of [lxc kvm], got "lxd"
>
> I have lxd installed (on trusty):
>
> $ apt-cache policy lxd
> lxd:
>   Installed: 0.22-0ubuntu2~ubuntu14.04.1~ppa1
>   Candidate: 0.22-0ubuntu2~ubuntu14.04.1~ppa1
>   Version table:
>  0.22-0ubuntu2~ubuntu14.04.1 0
> 100 http://archive.ubuntu.com/ubuntu/ trusty-backports/universe
> amd64 Packages
>  *** 0.22-0ubuntu2~ubuntu14.04.1~ppa1 0
> 500 http://ppa.launchpad.net/ubuntu-lxc/lxd-stable/ubuntu/
> trusty/main
>  amd64
> Packages
> 100 /var/lib/dpkg/status
>
>
> There appears to be no feature flag for the lxd provider, so what am I
> missing?
>

Have you added yourself to the lxd group? ("newgrp lxd")


> Cheers,
> 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: juju deploy failure on nova

[Billy Olsen]

Hi Cathy,

These messages are used to indicate why the service is not a fully
functional service.. As you point out, the software packages for the base
charm service has been installed at this point in time, but needs
additional relations in order to make the service a fully functioning
service. These are normally expected messages when the service has just
been deployed.

If you proceed at this point to adding the missing relations, you'll see
this message disappear from the status output.

Thanks,

Billy


On Sat, Nov 21, 2015 at 1:59 AM, wuwenbin  wrote:

> Hi Adam:
>
>  I download trusty codes and use juju to deploy openstack. While
> there are problems about nova-cloud-controller and nova-compute.
>
>  Error info is as follows. I think that installing charm is an
> independent operation because later we will add relationship between those
> charms. I have no idea what’t going on.
>
>  Looking forward for your replay.
>
>  Thanks.
>
> Best regards
>
> Cathy
>
>
>
> Error info:
>
> nova-cloud-controller:
>
> charm: local:trusty/nova-cloud-controller-501
>
> exposed: false
>
> service-status:
>
>   current: blocked
>
>   message: 'Missing relations: messaging, image, compute, identity,
> database'
>
>   since: 21 Nov 2015 12:44:35+08:00
>
> relations:
>
>   cluster:
>
>   - nova-cloud-controller
>
> units:
>
>   nova-cloud-controller/0:
>
> workload-status:
>
>   current: blocked
>
>   message: 'Missing relations: messaging, image, compute,
> identity, database'
>
>   since: 21 Nov 2015 12:44:35+08:00
>
> agent-status:
>
>   current: idle
>
>   since: 21 Nov 2015 16:39:38+08:00
>
>   version: 1.25.0.1
>
> agent-state: started
>
> agent-version: 1.25.0.1
>
> machine: "5"
>
> open-ports:
>
> - /tcp
>
> - 8773/tcp
>
> - 8774/tcp
>
> - 9696/tcp
>
> public-address: 192.168.122.242
>
>   nova-compute:
>
> charm: local:trusty/nova-compute-133
>
> exposed: false
>
> service-status:
>
>   current: blocked
>
>   message: 'Missing relations: messaging, image'
>
>   since: 21 Nov 2015 16:40:46+08:00
>
> relations:
>
>   compute-peer:
>
>   - nova-compute
>
> units:
>
>   nova-compute/0:
>
> workload-status:
>
>   current: blocked
>
>   message: 'Missing relations: messaging, image'
>
>   since: 21 Nov 2015 16:40:46+08:00
>
> agent-status:
>
>   current: idle
>
>   since: 21 Nov 2015 16:40:48+08:00
>
>   version: 1.25.0.1
>
> agent-state: started
>
> agent-version: 1.25.0.1
>
> machine: "1"
>
> public-address: 192.168.122.56
>
>
>
> log info:
>
> unit-nova-compute-0[3088]: 2015-11-21 08:50:56 WARNING
> unit.nova-compute/0.juju-log server.go:268 messaging relation is missing
> and must be related for functionality.
>
> unit-nova-compute-0[3088]: 2015-11-21 08:50:56 WARNING
> unit.nova-compute/0.juju-log server.go:268 image relation is missing and
> must be related for functionality.
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>


-- 
Billy Olsen

billy.ol...@canonical.com
Software Engineer
Canonical USA
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju