Re: Juju 2.0~ Local LXD provider workflows are awesome!
On 04/02/16 02:23, Mark Shuttleworth wrote: > On 03/02/16 12:09, James Page wrote: >> juju create-model midonet-review >> juju switch midonet-review > > Thanks for the feedback James, it's great to see these bits coming > together so nicely :) > > Should we automatically switch to a new model when you create it? I > suspect the common case is create-model-then-work-in-it rather than > create-model-then-do-something-else. I thought we did do that by default. Tim -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Problem deploying a bundle
Hi, On Wed, 3 Feb 2016 at 22:55 James Page wrote: > Hi Pshem > > {cut} >> > > Why are they failing now? And the more important question - how do I make >> it work again? Do I have to upgrade my bundle file to use the new charms? >> > > Yes - use the new charms in the charm store with Liberty rather than > Mitaka; there was a stable charm update just prior to 16.01 to fix the > problem you are hitting (version detection of point releases for the new > semantic naming upstream in OpenStack). > > The point release for liberty where release earlier in the week, so you're > now picking up .1 versions in stead of .0 versions. > > The 16.01 charm release includes these fixes so will work OK. > > Thank you for the explanation. Is it possible to create a bundle file that doesn't have specific versions of charms (and instead pulls in the current ones)? kind regards Pshem -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju 2.0~ Local LXD provider workflows are awesome!
I think in 2.0-alpha1 it does not, but as James mentioned he's running a little closer to alpha2/alpha3 version (from master) which appears to implement this so it's just a matter of alpha software is alpha :) On Wed, Feb 3, 2016 at 9:20 AM Rick Harding wrote: > Yes it's intended to auto switch for you. If it does not we need to > correct it. > > On Wed, Feb 3, 2016, 2:49 PM James Page wrote: > >> On Wed, 3 Feb 2016 at 13:23 Mark Shuttleworth wrote: >> >>> On 03/02/16 12:09, James Page wrote: >>> > juju create-model midonet-review >>> > juju switch midonet-review >>> >>> Thanks for the feedback James, it's great to see these bits coming >>> together so nicely :) >>> >>> Should we automatically switch to a new model when you create it? I >>> suspect the common case is create-model-then-work-in-it rather than >>> create-model-then-do-something-else. >> >> >> Actually we do the auto switch already - the switch in my example is not >> required (just tested with a new model). >> -- >> 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 > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju 2.0~ Local LXD provider workflows are awesome!
Yes it's intended to auto switch for you. If it does not we need to correct it. On Wed, Feb 3, 2016, 2:49 PM James Page wrote: > On Wed, 3 Feb 2016 at 13:23 Mark Shuttleworth wrote: > >> On 03/02/16 12:09, James Page wrote: >> > juju create-model midonet-review >> > juju switch midonet-review >> >> Thanks for the feedback James, it's great to see these bits coming >> together so nicely :) >> >> Should we automatically switch to a new model when you create it? I >> suspect the common case is create-model-then-work-in-it rather than >> create-model-then-do-something-else. > > > Actually we do the auto switch already - the switch in my example is not > required (just tested with a new model). > -- > 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: Juju 2.0~ Local LXD provider workflows are awesome!
On Wed, 3 Feb 2016 at 13:23 Mark Shuttleworth wrote: > On 03/02/16 12:09, James Page wrote: > > juju create-model midonet-review > > juju switch midonet-review > > Thanks for the feedback James, it's great to see these bits coming > together so nicely :) > > Should we automatically switch to a new model when you create it? I > suspect the common case is create-model-then-work-in-it rather than > create-model-then-do-something-else. Actually we do the auto switch already - the switch in my example is not required (just tested with a new model). -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju 2.0~ Local LXD provider workflows are awesome!
Hi, Le 03/02/2016 14:23, Mark Shuttleworth a écrit : > On 03/02/16 12:09, James Page wrote: >> juju create-model midonet-review >> juju switch midonet-review > > Thanks for the feedback James, it's great to see these bits coming > together so nicely :) > > Should we automatically switch to a new model when you create it? I > suspect the common case is create-model-then-work-in-it rather than > create-model-then-do-something-else. > Don't we all love 'git checkout -b' to land into the newly created branch ??? How about juju create-model -b ;-) > Thoughts? > Mark > ...Louis -- Louis Bouchard Software engineer, Cloud & Sustaining eng. Canonical Ltd Ubuntu developer Debian Maintainer GPG : 429D 7A3B DD05 B6F8 AF63 B9C4 8B3D 867C 823E 7A61 -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju 2.0~ Local LXD provider workflows are awesome!
On Wed, Feb 3, 2016 at 1:09 PM, James Page wrote: > Hi All > > I've been using Juju 2.0 (built from source with an in-flight patch for LXD > 2.0 right now - but that should be resolved soon) with the local LXD > provider on Ubuntu Xenial development to test some work we've been doing to > get OpenStack running on-top of LXD in a single machine. > > That's now working quite well (a few rough edges), but is not the main topic > for my post. This is solid, thanks for sharing here. -Antonio > > 1) Multiple models, single controller > > Alongside LXD support, you can also create multiple models against a single > controller, so I've been creating models to deploy, test and review specific > pieces of work (reviewing the midonet charms right now for example): > > juju bootstrap > juju create-model midonet-review > juju switch midonet-review > > and then deploy away; Not having to re-bootstrap a controller > every-time I want to tear-down and redeploy, or push something new up for > test optimizes my workflow nicely. > > 2) Tweaking container profiles > > For each model, Juju creates a profile in LXD (named juju-)- and > its quite possible to make additions to that profile for your specific model > requirements - here's the one we wrote for openstack-on-lxd: > > name: juju-openstack-on-lxd > config: > boot.autostart: "true" > linux.kernel_modules: openvswitch,nbd,ip_tables,ip6_tables > security.nesting: "true" > security.privileged: "true" > devices: > eth0: > mtu: "9000" > name: eth0 > nictype: bridged > parent: lxcbr0 > type: nic > eth1: > mtu: "9000" > name: eth1 > nictype: bridged > parent: lxcbr0 > type: nic > kvm: > path: /dev/kvm > type: unix-char > root: > path: / > type: disk > tun: > path: /dev/net/tun > type: unix-char > > This adds a-lot to the default profile, but at a high level ensures that > each container gets two network interfaces with a high mtu to avoid packet > fragmentation, can access a few devices required for virt networking and > process management - and also switches the container into 'privileged' mode > that we need for Open vSwitch support in a container right now (Tycho is > working on fixing that so we can run unprivileged). Read more about LXD > profiles here: > > https://github.com/lxc/lxd/blob/master/specs/configuration.md > > Editing is super easy - 'lxc profile edit '. > > 3) Pause/Resume containers > > I've found a few bits that LXD provides outside of Juju quite useful as well > - specifically I've been away from regular power for the last few days, so > I've been using the 'pause' feature of containers to freeze containers, > stopping CPU consumption and making my battery last a alot longer without > destroying and re-deploying the environment (which would consume far more > battery anyway) - here's 'pause-juju': > > for container in `lxc list | grep RUNNING | grep juju | awk '{ print $2 > }'`; do > lxc pause $container > done > > and 'resume-juju': > > for container in `lxc list | grep FROZEN | grep juju | awk '{ print $2 > }'`; do > lxc start $container > done > > I'm doing this outside of Juju right now - but I think it would make a great > feature! > > All container processes still consume memory, but stop consuming cpu cycles > until resumed. > > Oh - and use the ZFS backend for LXD - its superfast!: > > > https://insights.ubuntu.com/2015/11/06/using-lxd-with-a-file-based-zfs-pool-on-ubuntu-wily/ > > Hope people find that all useful! > > Cheers > > James > > > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > -- Antonio Rosales Ecosystem Engineering Canonical -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju 2.0~ Local LXD provider workflows are awesome!
On Wed, Feb 3, 2016 at 1:09 PM, James Page wrote: > Hope people find that all useful! Indeed, we also have fresh documentation thanks to Peter Matulis. I've been using these all week to spin up on lxd and juju: https://jujucharms.com/docs/devel/config-LXD As always everyone please feel free to open a PR or file an issue. Also a huge +1 to the LXD/ZFS/Juju combination; all of these performance improvements across the different parts of the stack are really coming together. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju 2.0~ Local LXD provider workflows are awesome!
On 03/02/16 12:09, James Page wrote: > juju create-model midonet-review > juju switch midonet-review Thanks for the feedback James, it's great to see these bits coming together so nicely :) Should we automatically switch to a new model when you create it? I suspect the common case is create-model-then-work-in-it rather than create-model-then-do-something-else. Thoughts? Mark -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Problem deploying a bundle
You'll need to update your revisions in the bundle file. We ran into this problem as well yesterday and it has to deal with charmhelpers regex when matching package_names -> openstack_versions. On Tue, Feb 2, 2016 at 10:10 PM, Pshem Kowalczyk wrote: > Hi, > > I've created my own openstack bundle (attached) that I use to re-deploy > our staging environment. I've used that bundle a number of times in the > past. > > I've attempted to upgrade to 16.01 charms and try the trusty-mitaka > openstack, but ran into issues so decided to wipe out the whole environment > and start from scratch. > > To my great surprise the bundle doesn't deploy any more. Multiple charms > fail with messages like: > > 2016-02-03 02:49:19 ERROR juju-log FATAL ERROR: Could not determine > OpenStack codename for version 8.0.1 (keystone) > 2016-02-03 02:47:49 ERROR juju-log FATAL ERROR: Could not determine > OpenStack codename for version 11.0.1 (glance) > 016-02-03 02:48:30 ERROR juju-log FATAL ERROR: Could not determine > OpenStack codename for version 7.0.1 (cinder) > > etc. > > Why are they failing now? And the more important question - how do I make > it work again? Do I have to upgrade my bundle file to use the new charms? > > kind regards > Pshem > > > -- > 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
Juju 2.0~ Local LXD provider workflows are awesome!
Hi All I've been using Juju 2.0 (built from source with an in-flight patch for LXD 2.0 right now - but that should be resolved soon) with the local LXD provider on Ubuntu Xenial development to test some work we've been doing to get OpenStack running on-top of LXD in a single machine. That's now working quite well (a few rough edges), but is not the main topic for my post. 1) Multiple models, single controller Alongside LXD support, you can also create multiple models against a single controller, so I've been creating models to deploy, test and review specific pieces of work (reviewing the midonet charms right now for example): juju bootstrap juju create-model midonet-review juju switch midonet-review and then deploy away; Not having to re-bootstrap a controller every-time I want to tear-down and redeploy, or push something new up for test optimizes my workflow nicely. 2) Tweaking container profiles For each model, Juju creates a profile in LXD (named juju-)- and its quite possible to make additions to that profile for your specific model requirements - here's the one we wrote for openstack-on-lxd: name: juju-openstack-on-lxd config: boot.autostart: "true" linux.kernel_modules: openvswitch,nbd,ip_tables,ip6_tables security.nesting: "true" security.privileged: "true" devices: eth0: mtu: "9000" name: eth0 nictype: bridged parent: lxcbr0 type: nic eth1: mtu: "9000" name: eth1 nictype: bridged parent: lxcbr0 type: nic kvm: path: /dev/kvm type: unix-char root: path: / type: disk tun: path: /dev/net/tun type: unix-char This adds a-lot to the default profile, but at a high level ensures that each container gets two network interfaces with a high mtu to avoid packet fragmentation, can access a few devices required for virt networking and process management - and also switches the container into 'privileged' mode that we need for Open vSwitch support in a container right now (Tycho is working on fixing that so we can run unprivileged). Read more about LXD profiles here: https://github.com/lxc/lxd/blob/master/specs/configuration.md Editing is super easy - 'lxc profile edit '. 3) Pause/Resume containers I've found a few bits that LXD provides outside of Juju quite useful as well - specifically I've been away from regular power for the last few days, so I've been using the 'pause' feature of containers to freeze containers, stopping CPU consumption and making my battery last a alot longer without destroying and re-deploying the environment (which would consume far more battery anyway) - here's 'pause-juju': for container in `lxc list | grep RUNNING | grep juju | awk '{ print $2 }'`; do lxc pause $container done and 'resume-juju': for container in `lxc list | grep FROZEN | grep juju | awk '{ print $2 }'`; do lxc start $container done I'm doing this outside of Juju right now - but I think it would make a great feature! All container processes still consume memory, but stop consuming cpu cycles until resumed. Oh - and use the ZFS backend for LXD - its superfast!: https://insights.ubuntu.com/2015/11/06/using-lxd-with-a-file-based-zfs-pool-on-ubuntu-wily/ Hope people find that all useful! Cheers James -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Upgrading charms to 16.01 - Ceph
Hi Darryl On Wed, 3 Feb 2016 at 00:39 Darryl Weaver wrote: > This would therefore have implications for co-locating nova-compute with > ceph charms on physical nodes. > Upgrading nova-compute would update the apt repository regardless of what > the ceph charm is doing. > Yes - this is one of the drawbacks of pushing two services onto the same underlying machine. Fortunately in this case, only the ceph binaries on disk are updated by the package upgrade - the package maintainer scripts are explicitly configured to not restart ceph services, so that this can have appropriate rolling restart orchestration. > Presumably ceph would then upgrade the next time config-changed hook runs? > I was thinking more along the lines of: juju set ceph source=cloud:trusty-liberty # no-op reconfiguration of software sources juju action do ceph/0 upgrade # update && dist-upgrade && restart of services on unit juju action do ceph/1 upgrade juju action do ceph/2 upgrade This is esp. important for moving to >= infernalis where the ceph daemons run as the ceph user instead of root, requiring a filesystem permissions update for the ceph osd filesystems (which could be very slow depending on storage capacity of the cloud). Just as a sidenote; we're doing some work between now and 16.04 that will mean we deprecate the ceph charm in favour of a new 'ceph-mon' charm - this just runs the monitor process for a ceph cluster and can be placed in a LXC container, allowing for better control over physical server resources for the container once Juju makes the move to LXD. So deployments will be ceph-mon + ceph-osd - the storage team are working on a migration approach for existing ceph deployments as part of this plan. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju