Adding a stateless service provider on the existing etcd key value store would be pretty easy with something like coredns I think without adding another stateful storage dependency.
I don't really have a horse in the game other then I'm an operator and we're feeling overwhelmed by all the state stuff to maintain. If consul is entirely optional, its probably fine to add the feature. But I worry operators may avoid it. Thanks, Kevin ________________________________________ From: Florian Engelmann [florian.engelm...@everyware.ch] Sent: Friday, October 19, 2018 1:17 AM To: firstname.lastname@example.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 adoption. I'm asking, if existing dependencies can be made to > solve the problem without adding more? > > Stateful dependencies are much harder to deal with then stateless ones, as > they take much more operator care/attention. Consul is stateful as is etcd, > and etcd is already a dependency. > > Can etcd be used instead so as not to put more load on the operators? While etcd is a strong KV store it lacks many features consul has. Using consul for DNS based service discovery is very easy to implement without making it a dependency. So we will start with a "external" consul and see how to handle the service registration without modifying the kolla containers or any kolla-ansible code. All the best, Flo > > Thanks, > Kevin > ________________________________________ > From: Florian Engelmann [florian.engelm...@everyware.ch] > Sent: Wednesday, October 10, 2018 12:18 AM > To: email@example.com > 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? 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 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 Engelmann [florian.engelm...@everyware.ch] >> Sent: Monday, October 08, 2018 3:14 AM >> To: firstname.lastname@example.org >> Subject: [openstack-dev] [kolla] add service discovery, proxysql, vault, >> fabio and FQDN endpoints >> >> 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. >> >> 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 HTTPS. >> 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. >> >> 4. HAProxy is fine but fabio integrates well with consul, statsd and >> could be connected to a vault cluster to manage secure certificate access. >> >> 5. I would like to add vault as Barbican backend. >> >> 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). >> >> What do you think about it? >> >> All the best, >> Florian >> >> __________________________________________________________________________ >> 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 >> > > -- > > EveryWare AG > Florian Engelmann > Systems Engineer > Zurlindenstrasse 52a > CH-8003 Zürich > > tel: +41 44 466 60 00 > fax: +41 44 466 60 10 > mail: mailto:florian.engelm...@everyware.ch > web: http://www.everyware.ch > > __________________________________________________________________________ > 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 > -- EveryWare AG Florian Engelmann Systems Engineer Zurlindenstrasse 52a CH-8003 Zürich tel: +41 44 466 60 00 fax: +41 44 466 60 10 mail: mailto:florian.engelm...@everyware.ch web: http://www.everyware.ch __________________________________________________________________________ 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