Etcd Charm Revision 3 released

[Charles Butler]

Before we get into the release notes, lets talk first about what to expect:

I would highly recommend users avoid using revision 3 if they wish to keep
their Etcd services insecure (read: no TLS certificates wrapping the
endpoints). It was not deemed mission critical to maintain insecure
backwards compatibility when straw-polling the mailing list. *If you *need*
this functionality*, either use revision-2 of the charm for the near-term,
or file a bug on the upstream layer project here:
https://github.com/juju-solutions/layer-etcd/issues.

It's highly recommended that you also start with a fresh Etcd cluster on
revision-3. If you notice any upgrade issues, please file bugs on the layer
repo so we can address them and discuss if further work is required to
ensure upgrades retain behavior moving forward.

I'm pretty excited to release this charm to the world. You can get started
right away today by:

juju deploy cs:~containers/etcd-3

This was a *monster* update from revision 2 of the Etcd charm. And as such,
it brings with it many new features:

- Xenial series support
- Moved from charmhelpers.core.hookenv leadership to layer-leadership which
makes the state machine at work much easier to grokk
- Cluster Health Reporting is now reported constantly via the units
juju-status output (you can lose a member, and know via juju-status)
- TLS support using ClientAuth/ServerAuth certificates (self signed PKI)
- CoreOS ETCD bins are now delivered via resources instead of being fetched
from github with curl (read: offline/firewall friendly deployment)
    - This is the default delivery path for the Etcd Charm
    - Currently deploys 2.3.6 - which is the latest stable
    - There is a fallback apt-installation path when using a local charm of
Xenial series.
- port defaults were migrated to the IANA standard ports: 2379,2380
- Ports are now expose-able  (you can juju expose etcd, do maintenance, and
juju unexpose)
- Ports are configureable
- Upgrades EtcdProxy interface to support TLS connections
- Upgrades Etcd interface to support TLS connections
- Etcdctl on the host is configured to use TLS certificates (in /etc/ssl/
etcd/) - if you're using a non bash shell, see: $HOME/.bash_aliases on the
ubuntu user.
-  /etc/default environment file support - on both upstart and SystemD
flavors
- Leader now reports itself via status as a pre-pended identifier:
"(Leader) Cluster is healthy."
- Proper scaling up/down - (prior you could only scale up, happy panda
here!)
   - Units properly register, and un-register themselves depending on the
event taking place
   - The leader proxies all these commands on behalf of the unit, so the
cluster stays consistent
   - Units halt during turn up if there is a unit already participating in
the registration sequence
- Quorem / peering is now based on communication between the leader etcd
application during turn-up, making initial cluster deployment far superior
to any previous experience.
- * Client certificates can be generated via an action for download


* workflow:

  juju action do ectd/0 package-client-credentials
  juju scp etcd/0:etcd_credentials.tar.gz .
  tar xvfz etcd_package.tar.gz
... query etcd to validate package ...


Which will give you a tar.gzip with the SSL certificates and README
instructions on how to use them.


All the best,


-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160616/2f763c6e/attachment.html>