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
> > 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 been able to move quickly by providing a flexible
> > configuration mechanism that avoids the need to maintain support for
> > every OpenStack feature. Other thoughts inline.
> >
> I do understand your apprehensions Mark. For some of the suggested
> changes/additions I agree. But adding those components without
> kolla/kolla-ansible integration feels not right.

I'm not entirely against adding some of these things, if enough people in
the community want them. I'd just like to make sure that if they can be
done in a sane way without changes, then we do that and document how to do
it instead.

> >
> > On Mon, 8 Oct 2018 at 11:15, Florian Engelmann
> > <florian.engelm...@everyware.ch <mailto:florian.engelm...@everyware.ch>>
> > wrote:
> >
> >     Hi,
> >
> >     I would like to start a discussion about some changes and additions I
> >     would like to see in in kolla and kolla-ansible.
> >
> >     1. Keepalived is a problem in layer3 spine leaf networks as any
> >     floating
> >     IP can only exist in one leaf (and VRRP is a problem in layer3). I
> >     would
> >     like to use consul and registrar to get rid of the "internal"
> floating
> >     IP and use consuls DNS service discovery to connect all services with
> >     each other.
> >
> >
> > Without reading up, I'm not sure exactly how this fits together. If
> > kolla-ansible made the API host configurable for each service rather
> > than globally, would that be a step in the right direction?
> No that would not help. The problem is HA. Right now there is a
> "central" floating IP (kolla_internal_vip_address) that is used for all
> services to connect to (each other). Keepalived is failing that IP over
> if the "active" host fails. In a layer3 (CLOS/Spine-Leaf) network this
> IP is only available in one leaf/rack. So that rack is a "SPOF".
> Using service discovery fits perfect in a CLOS network and scales much
> better as a HA solution.
> Right, but what I'm saying as a thought experiment is, if we gave you the
required variables in kolla-ansible (e.g. nova_internal_fqdn) to make this
possible with an externally managed consul service, could that work?

> >
> >     2. Using "ports" for external API (endpoint) access is a major
> headache
> >     if a firewall is involved. I would like to configure the HAProxy (or
> >     fabio) for the external access to use "Host:" like, eg. "Host:
> >     keystone.somedomain.tld", "Host: nova.somedomain.tld", ... with
> >     Any customer would just need HTTPS access and not have to open all
> >     those
> >     ports in his firewall. For some enterprise customers it is not
> possible
> >     to request FW changes like that.
> >
> >     3. HAProxy is not capable to handle "read/write" split with Galera. I
> >     would like to introduce ProxySQL to be able to scale Galera.
> >
> >
> > It's now possible to use an external database server with kolla-ansible,
> > instead of deploying a mariadb/galera cluster. This could be implemented
> > how you like, see
> >
> https://docs.openstack.org/kolla-ansible/latest/reference/external-mariadb-guide.html
> .
> Yes I agree. And this is what we will do in our first production
> deployment. But I would love to see ProxySQL in Kolla as well.
> As a side note: Kolla-ansible does use:
> option mysql-check user haproxy post-41
> to check Galera, but that check does not fail if the node is out of sync
> with the other nodes!
> http://galeracluster.com/documentation-webpages/monitoringthecluster.html
> That's good to know. Could you raise a bug in kolla-ansible on launchpad,
and offer advice on how to improve this check if you have any?

> >
> >     4. HAProxy is fine but fabio integrates well with consul, statsd and
> >     could be connected to a vault cluster to manage secure certificate
> >     access.
> >
> > As above.
> >
> >     5. I would like to add vault as Barbican backend.
> >
> > Does this need explicit support in kolla and kolla-ansible, or could it
> > be done through configuration of barbican.conf? Are there additional
> > packages required in the barbican container? If so, see
> >
> https://docs.openstack.org/kolla/latest/admin/image-building.html#package-customisation
> .
> True but the vault (and consul) containers could be deployed and managed
> by kolla-ansible.
> I'd like to see if anyone else is interested in this. Kolla ansible
already deploys a large number of services, which is great. As with many
other projects I'm seeing the resources of core contributors fall off a
little, and I think we need to consider how to ensure the project is
maintainable long term. In my view a good way of doing that is to enable
integration with existing services, rather than deploying them. We need to
decide where the line is as a community. We have an IRC meeting at 3pm UTC
if you'd like to bring it up then.

> >     6. I would like to add an option to enable tokenless authentication
> for
> >     all services with each other to get rid of all the openstack service
> >     passwords (security issue).
> >
> > Again, could this be done without explicit support?
> We did not investigate here. Changes to the apache configuration are
> needed. I guess we will have to change the kolla container itself to do
> so? Is it possible to "inject" files in a container using kolla-ansible?
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to