Octavia is a slightly easier solution in that each tenanat's load balancer doesn't have to be a different version of the software being deployed, such as trove's users selection
of mysql 5 vs mysq 10 or postgres, or sahara's choice in hadoop, etc. Permutations of user's version vs guest agent's version, etc. lets not get into rpms vs debs, which image building tool you use to stamp out the images, test frameworks, etc.
Its simpler for a Developer, not to deal with it and just say its an Operators problem. But as a whole, including the Operators problems, its way more complex to deal with that way.
just my $0.02
Thanks,
Kevin
From: Lingxian Kong [anlin.kong@gmail.com]
Sent: Tuesday, January 22, 2019 3:08 PM
To: openstack-discuss@lists.openstack.org
Subject: Re: Subject: Re: [Trove] State of the Trove service tenant deployment model
I'd recommend at this point to maybe just run kubernetes across the vms and push the guest agents/workload to them.
This sounds like an overkill to me. Currently, different projects in openstack are solving this issue in different ways, e.g. Octavia is using two-way SSL authentication API between the
controller service and amphora(which is the vm running HTTP server inside), Magnum is using heat-container-agent that is communicating with Heat via API, etc. However, Trove chooses another option which has brought a lot of discussions over a long time.
In the current situation, I don't think it's doable for each project heading to one common solution, but Trove can learn from other projects to solve its own problem.