Is this charm currently published for Xenial?

[neiljerram]

This is just a question, not an issue. I tried this:

ubuntu@ip-172-31-48-36:~/calico-mitaka-juju2$ charm pull cs:~containers/xenial/etcd
ERROR cannot get archive: no matching charm or bundle for cs:~containers/xenial/etcd

[mbruzek]

@neiljerram We are moving to charms defining their own series in the metadata.yaml and not in the path to the resource. Try:

charm pull cs:~containers/etcd

[chuckbutler]

As an update, this is moving to a xenial series charm and we are dropping trusty support.

This was announced to the juju mailing list earlier this month. This will ease upgrade concerns considering in-place upgrades can very well cause a failed data migration and cause some serious operational friction.

The recommended method to update is to deploy a xenial cluster, and etcddump from the trusty deployment, and reimport on a node in the xenial cluster, then remove/relate as required.

[neiljerram]

Will you therefore be able to simplify the charm code by removing all the resource handling (+ associated README doc)?

[chuckbutler]

Resource handling is still the preferred delivery mechanism, to use the upstream etcd binaries published by CoreOS. If no resources are provided it will still fall back to xenial deb installation.

I have no plans on deprecating the resources being leveraged in the charm, as payloads should rev independently of the charm code. For the most part the operations have remained the same from the 2.x series to the 3.x series.

Is there a qualified reason for wanting to deprecate resources @neiljerram?

[neiljerram]

It just seems like a strange precedent to me - effectively starting down the road of ignoring the Ubuntu archive and inventing a complete parallel system for deploying application software. Isn't it? Why would not trust that the Ubuntu archive contains a workable version of etcd?

[chuckbutler]

It's not that there is a distrust of the ubuntu archive, it's that more often than not I've been asked to support the CoreOS binaries, as they are moving faster than the archive package gets ingested. This allows end users to specify their deployment concerns via those resources.

additionally, it cuts down on porting concerns for developers wishing to fork the layer and re-build for their own target platform, as in a Centos based layer to deploy etcd. If resources are the primary payload source, there's no packaging translation to sort through, just action on the blobs on disk.

[chuckbutler]

@neiljerram As i think through this more, I can strike a better middle of the road for you if this is desirable, to default to archive, and zero byte the resources coming from the store, leaving it up to the user to provide those CoreOS bins if they so wish to use them.

This has the following impact:

• If file size of resources is ~ 0bytes, we can proceed with apt (current behavior, but only if missing path)
• The charm will always look in archive
• We're always installing etcd from archive and then nuking their default deployment bits (this is the current behavior of the Xenial path with no resources)

Is this more in alignment with what you're looking for?

[chuckbutler]

Ok, the primary series for the charm has been set

This is also published in the store proper namespace: https://jujucharms.com/etcd/

[chuckbutler]

@neiljerram - conversation considered, and approved.

juju deploy cs:etcd-8

[neiljerram]

Thanks @chuckbutler !