<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Sorry for bringing this thread back to the top again.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">But I am wondering if there are people who have already deployed Trove in production? If yes, are you using service tenant model(create the database vm and related resources in the admin project) or using the flatten mode that the end user has access to the database vm and the control plane network as well?</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default"><font face="verdana, sans-serif">I am asking because we are going to deploy Trove in a private cloud, and we want to take more granular control of the resources created, e.g for every database vm, we will create the vm in the admin tenant, plug a port to the control plane(`CONF.default_neutron_networks`</font><span style="font-family:verdana,sans-serif">) and the other ports to the network given by the users, we also need to specify different security groups to different types of neutron ports for security reasons, etc.</span></div><div class="gmail_default"><span style="font-family:verdana,sans-serif"><br></span></div><div class="gmail_default"><span style="font-family:verdana,sans-serif">There are something missing in trove in order to achieve the above, I'm working on that, but I'd like to hear more suggestions.</span></div><div class="gmail_default"><span style="font-family:verdana,sans-serif"><br></span></div><div class="gmail_default"><span style="font-family:verdana,sans-serif">My irc name is lxkong in #openstack-trove, please ping me if you have something to share.</span></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><font face="verdana, sans-serif">Cheers,<br>Lingxian Kong</font></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 23, 2019 at 7:35 PM Darek Król <<a href="mailto:dkrol3@gmail.com">dkrol3@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Jan 23, 2019 at 9:27 AM Fox, Kevin M<br><<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a><mailto:<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>>> wrote:<br>
<br>> > I'd recommend at this point to maybe just run kubernetes across the vms and push the guest agents/workload to them.<br>
<br>> 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.<br>
<br>> 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.<br>> Cheers,<br>> Lingxian Kong<br>
<br>The Octavia way of communication was discussed by Trove several times<br>in the context of secuirty. However, the security threat has been<br>eliminated by encryption.<br>I'm wondering if the Octavia way prevents DDOS attacks also ?<br>
<br>Implementation of two-way SSL authentication API could be included in<br>the Trove priority list IMHO if it solves all issues with<br>security/DDOS attacks. This could also creates some share code between<br>both projects and help other services as well.<br>
<br>Best,<br>Darek<br>
</blockquote></div></div></div></div>