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
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
