Change to layer:basic: use_venv & include_system_packages on by default
Greetings, A change to layer:basic just landed[1] that changes the default value for the use_venv and include_system_packages layer options[2] to be enabled by default. This change will prevent a confusing bug that people run into when dealing with subordinates or co-located charms on a single machine: if co-located charms have different versions of some of their dependencies, especially charms.reactive or charmhelpers, they would conflict and sometimes cause one of the charms to break. This fixes the issue by isolating the charm's Python dependencies in a virtual environment. The change to include_system_packages is to ensure that charms that rely on Python libraries installed via apt will still function. In general, this should be transparent to almost every charm. The only real concern is if the charm relies on command-line tools provided by any of the Python packages; with the packages now in the venv, the venv will need to be activated before the CLI tools can be used. The PR does provide shims for the charms.reactive CLI and charmhelpers CLI (chlp), as well as the layer_option CLI provided by the basic layer itself. These can be accessed globally and will use Juju context information to activate the correct virtual environment. On the off chance that you do run into an issue with this change, it's easy to disable it for your charm. Just add the following to your layer.yaml: options: basic: use_venv: false [1]: https://github.com/juju-solutions/layer-basic/pull/105 [2]: https://charmsreactive.readthedocs.io/en/latest/layer-basic.html#layer-configuration -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: juju deploys with a vsphere controller using hardware vm version 10
We've done some digging on this. It turns out that we can fairly easily request VSphere to deploy the best version it knows about (ESXi 5.5 supports 10, 6.0 supports 11, 6.5 supports 13). It is fairly easy to change our descriptor to request any of them, and we saw that 6.0 picked 11 and ignored 13. However, there seems to be a problem with the ubuntu image when booted in version 11. We've filed a bug with the people generating the images, but it starts to boot, but fails to get to a login prompt. So while it is fairly easy for Juju to start requesting newer hardware versions, there is a potential issue with the actual images not supporting them. John =:-> On Wed, Feb 7, 2018 at 11:32 AM, Mark Shuttleworth wrote: > > Seems we should support a range of widely used versions, rather than > only the latest. > > Mark > > On 02/07/2018 04:24 AM, Ian Booth wrote: > > Hi Daniel > > > > The Juju vSphere provider currently only supports hardware version 10, > but 14 is > > now the most recent according to the VMWare website. If we were simply > to track > > and support the most recent hardware version, would that work for you? > > > > On 05/02/18 12:38, Daniel Bidwell wrote: > >> Is there anyway to make the vsphere controller to deploy vms with > >> hardware vm version 13 instead of version 10? > >> > > > -- > Juju-dev mailing list > juju-...@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju-dev > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
