Hi,
I was wondering what is best practice in regards to juju when deploying and maintaining an Openstack cloud.
Specifically if i should should write my bundles with a specific charm version or always use latest?
Ex:
nova-compute:
charm: cs:nova-compute-296
Compared to:
nova-compute:
charm: cs:nova-compute
Thanks 
I recommend pinning specific charm revisions so you have an environment which is a bit easier to reproduce and keep in version control.
There are definitely benefits to specifying the charm revision in your bundle such as reproducible results as @szeestraten mentions, however, Canonical’s best practice for new cloud builds is to not specify a version in the bundle when deploying a new cloud in order to get the latest and greatest versions and bug-fixes on day one.
Do note, however, if you re-use the same bundle without specified charm release numbers to make config change updates, re-application of the bundle with new options settings can unintentionally upgrade your charms to latest revisions if they are not version-pinned in your bundle.
To avoid this, I recommend starting your deployment without a pinned version, and then using “juju export-bundle > bundle-to-update.yaml; vi bundle-to-update.yaml; juju deploy ./bundle-to-update.yaml” to make updates to your juju model w/out losing any live changes or charm upgrades you may have made, and to avoid unintended charm upgrades during re-application of the bundle.
If you do pin your revisions in your bundle, be sure to keep up to date on the patches applied to the stable release branches to ensure you adopt any relevant bug fixes that are released ad-hoc between major charm releases.
Also of note, with the regular charm release cycle (19.04, 19.10, 20.04, 20.10), if you’re testing a bundle in august w/out pinned versions and you go to re-deploy in October after the release of 19.10, your deployment will benefit from the new charm revisions which will have many feature enhancements and bug fixes, but may require reading release notes for other required changes to your bundle to ensure compatibility of your configuration with the next major charm release.
The balance between version pinning (stability, full control) and automatic resolution (always up-to-date) is a hard one.
As one data point, we recently encountered an issue where a pinned bundle stopped working because of upstream changes
Regarding to manually updating the revision in the bundle. I seem to not be able to easily track the revision number in Git.
For example charm-nova-compute
It has branches with all the major stable releases but does not contain the charm revision number. I can’t seem to find a easy way to track that.
Am i missing something?
The charm revision number is actually managed by the charm store itself. Currently the charm store is accessible via Store | Juju. It’s monotonically increasing–every time an authorized user issues charm push, it increments–and isn’t (directly) related to version numbers within charm’s source code.
Also note that if you go to the charm in the charm store you can often get the git info for the charm from the source of the charm.
e.g. if you look at
In the files section to the right is the file “repo-info”
https://api.jujucharms.com/charmstore/v5/~openstack-charmers-next/nova-compute-307/archive/repo-info
@emiljacero, Here is a capture of the information @rick_h is commenting about in a yaml format. this was captured sometime last month, so there may be updates in the charmstore newer than this document, but should help for identifying historical versions.
This yaml is set up to provide branch_revision = data[charm_name][charmstore_revision][release], and data[charm_name][“last_revision”] shows the latest release that was known at the time of generation of this report.
There is work being done to track and expose revisions for openstack charms more readily for version-managed clouds or to at least expose what version is running on a cloud, however the intent is to always be running latest revisions from the charmstore to benefit from any bug fixes and added features. This version information is used by our operational teams to validate which revision of charms are currently running on a given model. We always update to the latest in the charmstore when performing updates.
I’d recommend deploying without revisions in your bundle and running ‘juju status --format yaml|grep charm:’ to determine which revisions are current in the charm store, and then map those versions into your bundle for repeated deployments.
@afreiberger, thanks for the list and the info. Very much looking forward to getting more info about which revisions relate to which OpenStack charms release in the future.