On 19.10.2018 10:21, Florian Engelmann wrote:
On 17.10.2018 15:45, Florian Engelmann wrote:
On 10.10.2018 09:06, Florian Engelmann wrote:
Now I get you. I would say all configuration templates need to be
changed to allow, eg.
$ grep http /etc/kolla/cinder-volume/cinder.conf
@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] add service discovery, proxysql, vault,
fabio and FQDN endpoints
> No, I mean, Consul would be an extra dependency in a big list of dependencies
> OpenStack already has. OpenStack has so many it is causing operators to
> reconsider
currently we are testing what is needed to get consul + registrator and
kolla/kolla-ansible play together nicely.
To get the services created in consul by registrator all kolla
containers running relevant services (eg. keystone, nova, cinder, ...
but also mariadb, memcached, es, ...) need to
On 17.10.2018 15:45, Florian Engelmann wrote:
On 10.10.2018 09:06, Florian Engelmann wrote:
Now I get you. I would say all configuration templates need to be
changed to allow, eg.
$ grep http /etc/kolla/cinder-volume/cinder.conf
glance_api_servers = http://10.10.10.5:9292
auth_url =
nks,
Kevin
From: Florian Engelmann [florian.engelm...@everyware.ch]
Sent: Wednesday, October 10, 2018 12:18 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] add service discovery, proxysql, vault,
fabio and FQDN endpoints
by "
On 17.10.2018 15:45, Florian Engelmann wrote:
On 10.10.2018 09:06, Florian Engelmann wrote:
Now I get you. I would say all configuration templates need to be
changed to allow, eg.
$ grep http /etc/kolla/cinder-volume/cinder.conf
glance_api_servers = http://10.10.10.5:9292
auth_url =
Engelmann [florian.engelm...@everyware.ch]
Sent: Wednesday, October 10, 2018 12:18 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] add service discovery, proxysql, vault,
fabio and FQDN endpoints
by "another storage system" you mean the KV store of consul? T
currently we are testing what is needed to get consul + registrator and
kolla/kolla-ansible play together nicely.
To get the services created in consul by registrator all kolla
containers running relevant services (eg. keystone, nova, cinder, ...
but also mariadb, memcached, es, ...) need to
On 10.10.2018 09:06, Florian Engelmann wrote:
Now I get you. I would say all configuration templates need to be
changed to allow, eg.
$ grep http /etc/kolla/cinder-volume/cinder.conf
glance_api_servers = http://10.10.10.5:9292
auth_url = http://internal.somedomain.tld:35357
On 10.10.2018 09:06, Florian Engelmann wrote:
Now I get you. I would say all configuration templates need to be
changed to allow, eg.
$ grep http /etc/kolla/cinder-volume/cinder.conf
glance_api_servers = http://10.10.10.5:9292
auth_url = http://internal.somedomain.tld:35357
service discovery, proxysql, vault,
fabio and FQDN endpoints
On 10/09/2018 03:10 PM, Fox, Kevin M wrote:
> Oh, this does raise an interesting question... Should such information be
> reported by the projects up to users through labels? Something like,
> "percona_multimaster=safe" I
On Wed, 10 Oct 2018 at 08:08, Florian Engelmann <
florian.engelm...@everyware.ch> wrote:
> Am 10/9/18 um 1:47 PM schrieb Mark Goddard:
> >
> >
> > On Tue, 9 Oct 2018 at 12:03, Florian Engelmann
> > mailto:florian.engelm...@everyware.ch>>
>
> > wrote:
> >
> > Am 10/9/18 um 11:04 AM schrieb
by "another storage system" you mean the KV store of consul? That's just
someting consul brings with it...
consul is very strong in doing health checks
Am 10/9/18 um 6:09 PM schrieb Fox, Kevin M:
etcd is an already approved openstack dependency. Could that be used instead of
consul so as to
Am 10/9/18 um 1:47 PM schrieb Mark Goddard:
On Tue, 9 Oct 2018 at 12:03, Florian Engelmann
mailto:florian.engelm...@everyware.ch>>
wrote:
Am 10/9/18 um 11:04 AM schrieb Mark Goddard:
> Thanks for these suggestions Florian, there are some interesting
ideas
> in here. I'm a
On 10/09/2018 03:10 PM, Fox, Kevin M wrote:
Oh, this does raise an interesting question... Should such information be reported by the
projects up to users through labels? Something like, "percona_multimaster=safe"
Its really difficult for folks to know which projects can and can not be used
C question?
Thanks,
Kevin
From: melanie witt [melwi...@gmail.com]
Sent: Tuesday, October 09, 2018 10:35 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] add service discovery, proxysql, vault,
fabio and FQDN endpoints
On Tue, 9 Oct
On Tue, 9 Oct 2018 10:35:23 -0700, Melanie Witt wrote:
On Tue, 9 Oct 2018 07:23:03 -0400, Jay Pipes wrote:
That explains where the source of the problem comes from (it's the use
of SELECT FOR UPDATE, which has been removed from Nova's quota-handling
code in the Rocky release).
Small
On Tue, 9 Oct 2018 07:23:03 -0400, Jay Pipes wrote:
That explains where the source of the problem comes from (it's the use
of SELECT FOR UPDATE, which has been removed from Nova's quota-handling
code in the Rocky release).
Small correction, the SELECT FOR UPDATE was removed from Nova's
etcd is an already approved openstack dependency. Could that be used instead of
consul so as to not add yet another storage system? coredns with the
https://coredns.io/plugins/etcd/ plugin would maybe do what you need?
Thanks,
Kevin
From: Florian
, October 08, 2018 10:48 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] add service discovery, proxysql, vault,
fabio and FQDN endpoints
On 10/08/2018 06:14 AM, Florian Engelmann wrote:
> 3. HAProxy is not capable to handle "read/write" split with Galera. I
Am 10/9/18 um 1:23 PM schrieb Jay Pipes:
On 10/09/2018 06:34 AM, Florian Engelmann wrote:
Am 10/9/18 um 11:41 AM schrieb Jay Pipes:
On 10/09/2018 04:34 AM, Christian Berendt wrote:
On 8. Oct 2018, at 19:48, Jay Pipes wrote:
Why not send all read and all write traffic to a single haproxy
On Tue, 9 Oct 2018 at 12:03, Florian Engelmann <
florian.engelm...@everyware.ch> wrote:
> Am 10/9/18 um 11:04 AM schrieb Mark Goddard:
> > Thanks for these suggestions Florian, there are some interesting ideas
> > in here. I'm a little concerned about the maintenance overhead of adding
> >
On 10/09/2018 06:34 AM, Florian Engelmann wrote:
Am 10/9/18 um 11:41 AM schrieb Jay Pipes:
On 10/09/2018 04:34 AM, Christian Berendt wrote:
On 8. Oct 2018, at 19:48, Jay Pipes wrote:
Why not send all read and all write traffic to a single haproxy
endpoint and just have haproxy spread all
Am 10/9/18 um 11:04 AM schrieb Mark Goddard:
Thanks for these suggestions Florian, there are some interesting ideas
in here. I'm a little concerned about the maintenance overhead of adding
support for all of these things, and wonder if some of them could be
done without explicit support in
Am 10/9/18 um 11:41 AM schrieb Jay Pipes:
On 10/09/2018 04:34 AM, Christian Berendt wrote:
On 8. Oct 2018, at 19:48, Jay Pipes wrote:
Why not send all read and all write traffic to a single haproxy
endpoint and just have haproxy spread all traffic across each Galera
node?
Galera, after
On 10/09/2018 04:34 AM, Christian Berendt wrote:
On 8. Oct 2018, at 19:48, Jay Pipes wrote:
Why not send all read and all write traffic to a single haproxy endpoint and
just have haproxy spread all traffic across each Galera node?
Galera, after all, is multi-master synchronous
Thanks for these suggestions Florian, there are some interesting ideas in
here. I'm a little concerned about the maintenance overhead of adding
support for all of these things, and wonder if some of them could be done
without explicit support in kolla and kolla-ansible. The kolla projects
have
> On 8. Oct 2018, at 19:48, Jay Pipes wrote:
>
> Why not send all read and all write traffic to a single haproxy endpoint and
> just have haproxy spread all traffic across each Galera node?
>
> Galera, after all, is multi-master synchronous replication... so it shouldn't
> matter which node
On 10/08/2018 06:14 AM, Florian Engelmann wrote:
3. HAProxy is not capable to handle "read/write" split with Galera. I
would like to introduce ProxySQL to be able to scale Galera.
Why not send all read and all write traffic to a single haproxy endpoint
and just have haproxy spread all traffic
29 matches
Mail list logo
