+1 and thanks for all your contributions Felipe!
On Wed, Sep 12, 2018 at 6:51 AM Chris MacNaughton <
chris.macnaugh...@canonical.com> wrote:
> +1 Felipe has been a solid contributor to the Openstack Charms for some
> time now.
>
> Chris
>
> On 11-09-18 23:07, Ryan Beisner wrote:
>
> +1 I'm
fwiw this appears to be due to a bug in nova. I've raised
https://bugs.launchpad.net/nova/+bug/1785235 and proposed a fix
https://review.openstack.org/588520
On Thu, Aug 2, 2018 at 5:47 PM Liam Young wrote:
> Hi,
>
> I have a fresh pike deployment and the guests are not getting
Hi,
I have a fresh pike deployment and the guests are not getting metadata. To
investigate it further it would really help me to understand what the
metadata flow is supposed to look like.
In my deployment the guest receives a 404 when hitting
http://169.254.169.254/latest/meta-data. I have
On Mon, Feb 19, 2018 at 9:05 AM, Dmitrii Shcherbakov
wrote:
> Hi Liam,
>
>> I was recently looking at how to support custom configuration that relies
>> on post deployment setup.
>
> I would describe the problem in general as follows:
>
> 1) charms can get
Hi,
I was recently looking at how to support custom configuration that relies on
post deployment setup. Specifically about how to support designate optional
configuration for the sink service. The configuration lives on the application
units but needs the domain id of the designate domain that
Hi,
I would like to propose that we do not support the notifications
method for automatically creating DNS records in Queens+. This method
for achieving Neutron integration has been superseded both upstream
and in the charms. By removing support for it in Queens we prevent the
charm from
Hi James,
I like option 2 but I think there is a problem with it. I don't
think the hacluster charm sets any data down the relation with the
principle until it has first received data from the principle. As I
understand it option 2 would change this behaviour so that hacluster
immediately sets
The Designate sink service relies on sink file(s) that contain the domain
id(s) of the domains that automatically generated records should be added
to.
At the moment the designate charm creates a server and domains during charm
installation if the neutron-domain and/or nova-domain config options
Hi,
Firstly, apologies for the cross post from openstack@l.o.o but I think this
is a more appropriate mailing list and I'd like to add some more
information.
I have been running tempest full against a Keystone v3 enabled cloud using
the stable newton policy.v3cloudsample.json *1 and it is
Hi Brad,
Thanks for looking into it. I think things should actually work out of the
box as they are now. So,
juju deploy nrpe nrpe-glance
juju deploy nrpe nrpe-cinder
juju deploy nagios
juju deploy glance
juju deploy cinder
juju add-relation nrpe-glance glance
juju add-relation nrpe-glance
On Fri, Nov 11, 2016 at 12:41 AM, James Beedy wrote:
> Concerning the Juju Keystone charm, and api v3, can someone shed some
> light on how to find the default admin creds needed to access the keystone
> api, or what the novarc file might look like? I'm setting the
>
Hi Heidi,
We'd like to go for a Cobra as our first choice ('[snake] charming
openstack') and as a backup a giant squid ('many armed animal managing
openstack'). It was discussed on the mailing list and voted for in
yesterdays OpenStack Charms IRC meeting.
Thanks
Liam
Hi,
I'm trying to add a new bind9 pool_target to an existing pool. The problem
is that the new bind server has no knowledge of the existing zones as it
missed the addzone commands when the domains where created. It seems to me
I have 3 options:
1) To sync the zone + nzf files from an existing
13 matches
Mail list logo