Open Stack

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 at gmail.com]
Sent: Tuesday, January 22, 2019 3:08 PM
To: openstack-discuss at lists.openstack.org
Subject: Re: Subject: Re: [Trove] State of the Trove service tenant deployment model

On Wed, Jan 23, 2019 at 9:27 AM Fox, Kevin M <Kevin.Fox at pnnl.gov<mailto:Kevin.Fox at pnnl.gov>> wrote:

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.
Cheers,
Lingxian Kong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190122/599c40ee/attachment-0001.html>