Re: Multi-series charm authors: new functionality for comparing ubuntu versions

2017-04-13 Thread Colin Watson 
On Thu, Apr 13, 2017 at 09:15:08PM +0100, Alex Kavanagh wrote:
> So instead of:
> 
> if ubuntu_version > 'trusty':
> 
> We do:
> 
> cmp_version = CompareHostReleases(ubuntu_version)
> if cmp_version > 'trusty':
> 
> This version of the code checks that ubuntu_version and 'trusty' strings
> are known releases and makes it easy to fix existing code.  >, <, >=< <=,
> ==, != are all supported.

I have déjà vu: I did exactly the same thing in lp:ubuntu-cdimage in
2012. :-)  I agree that this style makes things pretty nice for calling
code.

The one problem I've had with it is that every so often somebody looks
at a bit of code and says "hey, isn't this going to break after 17.04?"
and then I have to explain that it's actually magically OK, which as
problems go is not really a bad one to have.

-- 
Colin Watson   [cjwat...@ubuntu.com]

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

Multi-series charm authors: new functionality for comparing ubuntu versions

2017-04-13 Thread Alex Kavanagh 
Hi

I just wanted to highlight some new functionality that has been added to
charm-helpers [1] to make comparing Ubuntu versions more robust.  In the
OpenStack team, all of our charms are 'multi-series' in that a single charm
support multiple versions of Ubuntu and multiple versions of OpenStack
(often simultaneously).

The code was using statements along the lines of:

if ubuntu_version > 'trusty':

The eagle-eyed amongst you will have noticed the impending y2k-type bug,
with the (possible) imminent wrap from 'zesty' -> '???'.

So we decided to fix this across our 30-odd charms and add a couple of
functions to charm-helpers to aid in this.

Firstly, charm-helpers.core.strutils.BasicStringComparator class is an
abstract-ish class to be used as a base class for building a comparator of
an ordered list.  It provides __eq__, __ne__, __lt__ (and so on)
comparisons for two strings.  it also checks that the strings provided are
in the defined list, which helps with mistyping of string literals.

Then for the Ubuntu releases, the
charmhelpers.core.host.CompareHostReleases class is used to compare two
Ubuntu release for equality or 'earlier than' and 'later than;.

So instead of:

if ubuntu_version > 'trusty':

We do:

cmp_version = CompareHostReleases(ubuntu_version)
if cmp_version > 'trusty':

This version of the code checks that ubuntu_version and 'trusty' strings
are known releases and makes it easy to fix existing code.  >, <, >=< <=,
==, != are all supported.

We did consider a number of approaches, but felt that this one was simple
to retro-fit to existing charms and also spot in reviews going forward if
they have been missed.

Also, for charms in the OpenStack ecosystem, there is an additional
comparator class:

charmhelpers.contrib.openstack.utils.CompareOpenStackReleases

which is used in the same way, but works with all of the OpenStack releases.

Thus:

cmp_os_release = CompareOpenStackReleases(os_release)
if cmp_os_release > 'mitaka':

We're now in the process of finalises the fixes to the OpenStack charms and
they'll be in 'next' over the coming week.

Thanks, and hope this is useful.
Best
Alex.


[1] -- charm-helpers: https://launchpad.net/charm-helpers

-- 
Alex Kavanagh - Software Engineer
Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Check out the openvpn charm form the tengu team

2017-04-13 Thread Rick Harding 
I wrote up a quick blog post [1] as I was tinkering with VPNs and the
OpenVPN charm [2] from the Tengu team is really nice and easy. It also does
some great work using metrics in Juju to output operational data. Running
juju metrics --all will show you how many clients are connected on each
unit. If you're a charmer, it might give you some new ideas for exposing
internal data in a really nice standard way.

I just wanted to highlight it as something really useful for folks if
you've ever found yourself wishing you had a VPN around somewhere.

1:
http://mitechie.com/blog/2017/4/12/three-reasons-you-need-to-keep-a-vpn-in-your-pocket
2: https://jujucharms.com/openvpn/

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

Re: Kubernetes charms now support 1.6!

2017-04-13 Thread Samuel Cozannet 
Yooohoo!! Congrats!

I tested the GPU deployment and it worked flawlessly. I have another team
using it now, also worked OOTB.

I'll be updating all my blog posts to outline the changes.

Good job on snaps as well, it makes reconfiguration of the cluster so much
easier. I intend to do a short write up about this in a near future.

++
Sam




--
Samuel Cozannet
Cloud, Big Data and IoT Strategy Team
Business Development - Cloud and ISV Ecosystem
Changing the Future of Cloud
Ubuntu   / Canonical UK LTD  / Juju

samuel.cozan...@canonical.com
mob: +33 616 702 389
skype: samnco
Twitter: @SaMnCo_23
[image: View Samuel Cozannet's profile on LinkedIn]


On Thu, Apr 13, 2017 at 12:34 AM, Matt Bruzek 
wrote:

> We are proud to release the latest Charms supporting Kubernetes version
> 1.6.1!
>
>
> Kubernetes 1.6 is a major milestone for the community, we’ve got a full
> write up of features and support on our blog  2017/04/12/general-availability-of-kubernetes-1-6-on-ubuntu/>
> Getting Started
>
> Here’s the simplest way to get a Kubernetes cluster up and running on an
> Ubuntu 16.04 system:
>
> sudo snap install conjure-up --classic
> conjure-up kubernetes
>
>
> During the installation conjure-up will ask you what cloud you want to
> deploy on and prompt you for the proper credentials. If you’re deploying to
> local containers (LXD) see these instructions  getting-started-guides/ubuntu/local/> for localhost-specific
> considerations.
>
> For production grade deployments and cluster lifecycle management it is
> recommended to read the full Canonical Distribution of Kubernetes
> documentation .
> Upgrading an existing cluster
>
> If you’ve got a cluster already deployed, we’ve got instructions to help
> get you upgraded. If possible, deploying a new cluster will be the easiest
> route. Otherwise, the instructions for upgrading are outlined here:
> https://insights.ubuntu.com/2017/04/12/general-
> availability-of-kubernetes-1-6-on-ubuntu/#upgrades
> Changes in this release
>
>-
>
>Support for Kubernetes v1.6, with the current release being 1.6.1
>-
>
>Installation of components via snaps: kubectl, kube-apiserver,
>kube-controller-manager, kube-scheduler, kubelet, and kube-proxy. To learn
>more about snaps: https://snapcraft.io
>-
>
>Added ‘allow-privileged’ config option on kubernetes-master and
>kubernetes-worker charms. Valid values are true|false|auto (default: auto).
>If the value is ‘auto’, containers will run in unprivileged mode unless GPU
>hardware is detected on a worker node. If there are GPUs, or the value is
>true, Kubernetes will set `--allow-privileged=true`. Otherwise the flag is
>set to false.
>-
>
>Added GPU support (beta). If Nvidia GPU hardware is detected on a
>worker node, Nvidia drivers and CUDA packages will be installed, and
>kubelet will be restarted with the flags required to use the GPU hardware.
>The ‘allow-privileged’ config option must be ‘true’ or ‘auto’.
>-
>
>   Nvidia driver version = 375.26; CUDA version = 8.0.61; these will
>   be configurable future charm releases.
>   -
>
>   GPU support does not currently work on lxd.
>   -
>
>   This feature is beta - feedback on the implementation is welcomed.
>   -
>
>Added support for running your own private registry, see the docs here
>
> 
>for instructions.
>
> General Fixes:
>
>-
>
>Fixed a bug in the kubeapi-load-balancer not properly forwarding
>SPDY/HTTP2 traffic for `kubectl exec` commands.
>
> Etcd specific changes:
>
>-
>
>Installation of etcd and etcdctl is now done using the `snap install`
>command.
>-
>
>We support upgrading the previous etcd charm, to the latest charm with
>snap delivery mechanism.  See manual upgrade process for updating existing
>etcd clusters.
>
> Changes to the bundles and layers:
>
>-
>
>Add registry action to the kubernetes-worker layer, which deploys a
>Docker registry in Kubernetes.
>-
>
>Add support for kube-proxy cluster-cidr option.
>
> Test results
>
> The Canonical Distribution of Kubernetes is running daily tests to verify
> it works with the upstream code. As part of the Kubernetes test
> infrastructructure we upload daily test runs. The test results are
> available on the dashboard. Follow along with our progress here:
>
> https://k8s-gubernator.appspot.com/builds/canonical-kubernetes-tests/logs/
> kubernetes-gce-e2e-node/
> How to contact us
>
> We're normally found in the Kubernetes Slack channels and attend these
> Special Interest Group (SIG) meetings

Re: How to add openstack cloud to juju 2.1.2-xenial

2017-04-13 Thread Daniel Bidwell 
That worked!  Except ...
It looks like it built the controller and then destroyed it.  I didn't
see any obvious reason though.  Here is what I ran and got back:

 juju bootstrap acauits --metadata-source=~/simplestreams/images --
debug
07:56:15 INFO  juju.cmd supercommand.go:63 running juju [2.1.2 gc
go1.6.2]
07:56:15 DEBUG juju.cmd supercommand.go:64   args: []string{"juju",
"bootstrap", "acauits", "--metadata-source=~/simplestreams/images", "
--debug"}
07:56:15 INFO  cmd cmd.go:141 no credentials found, checking
environment
07:56:15 DEBUG juju.cmd.juju.commands bootstrap.go:780 authenticating
with region "RegionOne" and credential "admin" (openstack region
"RegionOne" project "admin" user "admin")
07:56:15 DEBUG juju.cmd.juju.commands bootstrap.go:892 provider attrs:
map[external-network: use-floating-ip:false use-default-secgroup:false
network:]
07:56:16 INFO  cmd cmd.go:141 Adding contents of
"/home/bidwell/.local/share/juju/ssh/juju_id_rsa.pub" to authorized-
keys
07:56:16 INFO  cmd cmd.go:141 Adding contents of
"/home/bidwell/.ssh/id_rsa.pub" to authorized-keys
07:56:16 DEBUG juju.cmd.juju.commands bootstrap.go:948 preparing
controller with config: map[ignore-machine-addresses:false enable-os-
refresh-update:true external-network: development:false image-metadata-
url: apt-http-proxy: agent-stream:released image-stream:released
disable-network-management:false resource-tags: transmit-vendor-
metrics:true authorized-keys:ssh-rsa
B3NzaC1yc2EDAQABAAABAQDYVqxnI6EUKENu/WSapHYavwZk/Q430CkDerSdqjX
2hQWIpeMsy3FCiMyb3z6eL3bIiKWh8B2I8Hm8gTbKWPQG2495yZmHxcwOi8ECRPapp58d48
+qYKYYWwRioC07uMe4/SR3lT1zO0kQ3yPiJOBZbnhksgVV+M4Jwl7lxlsKZfgY6PQ3n7d61
Q5IjOwEU2KekwdNTxwIvYGl52Q6I3o8LY2mJqb+OeQggZH8iSL82M5jqDmOT1ni4D9ig2D1
s8jkj8O5gYsKGgRFY+nKh6eWtBuFzkkzXs8X4NRXSKE2OkqYf4Tjp/+1T6hUjAIio37IBbV
F8h2e2aUxUTGHm1pp juju-client-key
ssh-rsa
B3NzaC1yc2EDAQABAAABAQDU8V64uPSRxvs+FS3LmsWjEqEcI8LKHqBIwjTjC0S
qAk3rt4j8CA44jUTsILfJkitveaAtTU/qhY3/+u6kRh0KnpvihKoPm2//g5YvDn3rJsexz7
2ab0fDkw1KmQIJW6rnzgMYG3kkrVivxGfP5nxkS2N3cSX8qkkRnXY/wFNq7AdZEWSN3VZO5
jwIIgHEtWYoImsYO2AEmaXS485EQHR2TmBQ3tWS44IyFSANc6nNkJRCSwxVhblPi8aS1z6T
LpN0MRmzzOdE+AAm+IR30o3TkjQbtTClVP2QCVypZUJz9LtlTaUGgd9wyZm4ZqaTcW6oUSQ
S7NMuMN7e5cZo+mcn bidwell@samwise
 name:controller logforward-enabled:false provisioner-harvest-
mode:destroyed apt-ftp-proxy: test-mode:false no-proxy: ftp-proxy: apt-
https-proxy: agent-metadata-url: net-bond-reconfigure-delay:17 network:
firewall-mode:instance logging-config: use-floating-ip:false use-
default-secgroup:false default-series:xenial automatically-retry-
hooks:true apt-mirror: http-proxy: proxy-ssh:false uuid:5482ff53-12f0-
445b-84f1-9c9f4a0c7cc8 type:openstack https-proxy: ssl-hostname-
verification:true enable-os-upgrade:true]
07:56:16 INFO  juju.provider.openstack provider.go:131 opening model
"controller"
07:56:17 DEBUG goose :22 auth details:
&{Token:a2e15ae3122b4263a790c699cbe59075
TenantId:e69c1091bf744509a8853ea8e336ae26
UserId:865cd86178094f348c479f8d043dff83 Domain:
RegionServiceURLs:map[RegionOne:map[network:http://10.20.9.144:9696
volumev2:http://10.20.9.143:8776/v2/e69c1091bf744509a8853ea8e336ae26
image:http://10.20.9.140:9292
volume:http://10.20.9.143:8776/v1/e69c1091bf744509a8853ea8e336ae26
object-store:http://10.20.9.139:80/swift/v1 product-
streams:http://10.20.9.139:80/swift/v1/simplestreams/images
identity:http://10.20.9.138:5000/v2.0
compute:http://10.20.9.142:8774/v2/e69c1091bf744509a8853ea8e336ae26]]}
07:56:17 INFO  cmd cmd.go:129 Creating Juju controller "acauits-
RegionOne" on acauits/RegionOne
07:56:17 DEBUG goose :22 performing API version
discovery for "http://10.20.9.142:8774/;
07:56:17 DEBUG goose :22 discovered API versions:
[{Version:{major:2 minor:0} Links:[{Href:http://10.20.9.142:8774/v2/
Rel:self}] Status:SUPPORTED} {Version:{major:2 minor:1}
Links:[{Href:http://10.20.9.142:8774/v2.1/ Rel:self}] Status:CURRENT}]
07:56:18 INFO  juju.cmd.juju.commands bootstrap.go:526 combined
bootstrap constraints: 
07:56:18 DEBUG juju.environs.bootstrap bootstrap.go:199 model
"controller" supports service/machine networks: false
07:56:18 DEBUG juju.environs.bootstrap bootstrap.go:201 network
management by juju enabled: true
07:56:18 INFO  juju.environs.bootstrap bootstrap.go:662 Setting default
tools and image metadata sources: /home/bidwell/~/simplestreams/images
07:56:18 INFO  cmd cmd.go:141 Loading image metadata
07:56:18 DEBUG juju.environs imagemetadata.go:112 obtained image
datasource "keystone catalog"
07:56:18 DEBUG juju.environs imagemetadata.go:112 obtained image
datasource "default cloud images"
07:56:18 DEBUG juju.environs imagemetadata.go:112 obtained image
datasource "default ubuntu cloud images"
07:56:18 DEBUG juju.environs.bootstrap bootstrap.go:571 constraints for
image metadata lookup &{{{RegionOne http://10.20.9.138:5000/v2.0}
[precise win2008r2 win2012hv win2016hv win2016nano win10 vivid wily
win81 centos7 quantal raring saucy utopic zesty win2016 win7 win8
trusty xenial

Re: How to add openstack cloud to juju 2.1.2-xenial

2017-04-13 Thread Mark Shuttleworth 
On 12/04/17 22:09, Daniel Bidwell wrote:
> Connecting juju to MAAS was a whole lot simpler.

Yeah, this says it all really! It's nuts that bootstrapping Juju on MAAS
or VMware is much easier than OpenStack.

All the image management should Just Work on a cloud, or we are half-arsed.

Mark

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