> So just changing your client isn't going to fix the issue, as it is a
server side issue that is refusing to destroy the models.
Aha. That makes more sense, actually.
I'll look forward to testing things out once things update on the JaaS side
:-)
~ PeteVG
On Thu, Oct 12, 2017 at 3:46 PM John
So just changing your client isn't going to fix the issue, as it is a
server side issue that is refusing to destroy the models.
https://bugs.launchpad.net/bugs/1714409
Is at least one of them that might be relevant for your issue.
I also know that we have:
Copying in the Juju list also
On 12/10/17 22:18, Ian Booth wrote:
> I'd like to understand the use case you have in mind a little better. The
> premise of the network-get output is that charms should not think about public
> vs private addresses in terms of what to put into relation data - the
Copying in the Juju list also
On 12/10/17 22:18, Ian Booth wrote:
> I'd like to understand the use case you have in mind a little better. The
> premise of the network-get output is that charms should not think about public
> vs private addresses in terms of what to put into relation data - the
I'd like to understand the use case you have in mind a little better. The
premise of the network-get output is that charms should not think about public
vs private addresses in terms of what to put into relation data - the other
remote unit should not be exposed to things in those terms.
There's
Hi Akshay
I think you've tripped over:
https://bugs.launchpad.net/charm-keystone/+bug/1722909
which I did as well last night - this only impacts the development version
of the charm which you are using with the bundle.
I have a fix up for this, should land in the next couple of hours (we've
Hi All,
We at Veritas Technologies LLC are trying to deploy juju based OpenStack Pike
bits, from location:
https://jujucharms.com/u/openstack-charmers-next/openstack-base-xenial-pike/ .
But it fails at keystone charm in 'shared-db-relation-changed' hook giving
following stack trace:
