<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace">Kevin,<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">In interests of 'keeping it simple', I'm going to try and prioritize the use-cases and pick implementation strategies which target the higher priority ones without needlessly excluding other (lower priority) ones.<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">Thanks,<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">-amrith<br></div><div class="gmail_extra"><br><div><div class="gmail_signature"><span style="font-family:courier new,monospace">--</span><br style="font-family:courier new,monospace"><span style="font-family:courier new,monospace">Amrith Kumar</span><br style="font-family:courier new,monospace"><div style="font-family:courier new,monospace" class="gmail_default">​<br>P.S. Verizon is hiring ​OpenStack engineers nationwide. If you are interested, please contact me or visit <a href="https://t.co/gGoUzYvqbE">https://t.co/gGoUzYvqbE</a><br></div><br></div></div>
<br><div class="gmail_quote">On Wed, Jul 12, 2017 at 5:46 PM, Fox, Kevin M <span dir="ltr"><<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There is a use case where some sites have folks buy whole bricks of compute nodes that get added to the overarching cloud, but using AZ's or HostAggregates/Flavors to dedicate the hardware to the users.<br>
<br>
You might want to land the db vm on the hardware for that project and one would expect the normal quota would be dinged for it rather then a special trove quota. Otherwise they may have more quota then the hosts can actually handle.<br>
<br>
Thanks,<br>
Kevin<br>
______________________________<wbr>__________<br>
From: Doug Hellmann [<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>]<br>
Sent: Wednesday, July 12, 2017 6:57 AM<br>
To: openstack-dev<br>
Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
Excerpts from Amrith Kumar's message of 2017-07-12 06:14:28 -0500:<br>
> All:<br>
><br>
> First, let me thank all of you who responded and provided feedback<br>
> on what I wrote. I've summarized what I heard below and am posting<br>
> it as one consolidated response rather than responding to each<br>
> of your messages and making this thread even deeper.<br>
><br>
> As I say at the end of this email, I will be setting up a session at<br>
> the Denver PTG to specifically continue this conversation and hope<br>
> you will all be able to attend. As soon as time slots for PTG are<br>
> announced, I will try and pick this slot and request that you please<br>
> attend.<br>
><br>
> ----<br>
><br>
> Thierry: naming issue; call it Hoard if it does not have a migration<br>
> path.<br>
><br>
> ----<br>
><br>
> Kevin: use a container approach with k8s as the orchestration<br>
> mechanism, addresses multiple issues including performance. Trove to<br>
> provide containers for multiple components which cooperate to provide<br>
> a single instance of a database or cluster. Don't put all components<br>
> (agent, monitoring, database) in a single VM, decoupling makes<br>
> migraiton and upgrades easier and allows trove to reuse database<br>
> vendor supplied containers. Performance of databases in VM's poor<br>
> compared to databases on bare-metal.<br>
><br>
> ----<br>
><br>
> Doug Hellmann:<br>
><br>
> > Does "service VM" need to be a first-class thing?  Akanda creates<br>
> > them, using a service user. The VMs are tied to a "router" which is<br>
> > the billable resource that the user understands and interacts with<br>
> > through the API.<br>
><br>
> Amrith: Doug, yes because we're looking not just for service VM's but all<br>
> resources provisioned by a service. So, to Matt's comment about a<br>
> blackbox DBaaS, the VM's, storage, snapshots, ... they should all be<br>
> owned by the service, charged to a users quota but not visible to the<br>
> user directly.<br>
<br>
I still don't understand. If you have entities that represent the<br>
DBaaS "host" or "database" or "database backup" or whatever, then<br>
you put a quota on those entities and you bill for them. If the<br>
database actually runs in a VM or the backup is a snapshot, those<br>
are implementation details. You don't want to have to rewrite your<br>
quota management or billing integration if those details change.<br>
<br>
Doug<br>
<br>
><br>
> ----<br>
><br>
> Jay:<br>
><br>
> > Frankly, I believe all of these types of services should be built<br>
> > as applications that run on OpenStack (or other)<br>
> > infrastructure. In other words, they should not be part of the<br>
> > infrastructure itself.<br>
> ><br>
> > There's really no need for a user of a DBaaS to have access to the<br>
> > host or hosts the DB is running on. If the user really wanted<br>
> > that, they would just spin up a VM/baremetal server and install<br>
> > the thing themselves.<br>
><br>
> and subsequently in follow-up with Zane:<br>
><br>
> > Think only in terms of what a user of a DBaaS really wants. At the<br>
> > end of the day, all they want is an address in the cloud where they<br>
> > can point their application to write and read data from.<br>
> > ...<br>
> > At the end of the day, I think Trove is best implemented as a hosted<br>
> > application that exposes an API to its users that is entirely<br>
> > separate from the underlying infrastructure APIs like<br>
> > Cinder/Nova/Neutron.<br>
><br>
> Amrith: Yes, I agree, +1000<br>
><br>
> ----<br>
><br>
> Clint (in response to Jay's proposal regarding the service making all<br>
> resources multi-tenant) raised a concern about having multi-tenant<br>
> shared resources. The issue is with ensuring separation between<br>
> tenants (don't want to use the word isolation because this is database<br>
> related).<br>
><br>
> Amrith: yes, definitely a concern and one that we don't have today<br>
> because each DB is a VM of its own. Personally, I'd rather stick with<br>
> that construct, one DB per VM/container/baremetal and leave that be<br>
> the separation boundary.<br>
><br>
> ----<br>
><br>
> Zane: Discomfort over throwing out working code, grass is greener on<br>
> the other side, is there anything to salvage?<br>
><br>
> Amrith: Yes, there is certainly a 'grass is greener with a rewrite'<br>
> fallacy. But, there is stuff that can be salvaged. The elements are<br>
> still good, they are separable and can be used with the new<br>
> project. Much of the controller logic however will fall by the<br>
> wayside.<br>
><br>
> In a similar vein, Clint asks about the elements that Trove provides,<br>
> "how has that worked out".<br>
><br>
> Amrith: Honestly, not well. Trove only provided reference elements<br>
> suitable for development use. Never really production hardened<br>
> ones. For example, the image elements trove provides don't bake the<br>
> guest agent in; they assume that at VM launch, the guest agent code<br>
> will be slurped (technical term) from the controller and<br>
> launched. Great for debugging, not great for production. That is<br>
> something that should change. But, equally, I've heard disagreements<br>
> saying that slurping the guest agent at runtime is clever and good<br>
> in production.<br>
><br>
> ----<br>
><br>
> Zane: consider using Mistral for workflow.<br>
><br>
> > The disadvantage, obviously, is that it requires the cloud to offer<br>
> > Mistral as-a-Service, which currently doesn't include nearly as many<br>
> > clouds as I'd like.<br>
><br>
> Amrith: Yes, as we discussed, we are in agreement with both parts of<br>
> this recommendation.<br>
><br>
> Zane, Jay and Dims: a subtle distinction between Tessmaster and Magnum<br>
> (I want a database figure out the lower layers, vs. I want a k8s<br>
> cluster).<br>
><br>
> ----<br>
><br>
> Zane: Fun fact: Trove started out as a *complete fork* of Nova(!).<br>
><br>
> Amrith: Not fun at all :) Never, ever, ever, ever f5g do that<br>
> again. Yeah, sure, if you can have i18n, and k8s, I can have f5g :)<br>
><br>
> ----<br>
><br>
> Thierry:<br>
><br>
> > We generally need to be very careful about creating dependencies<br>
> > between OpenStack projects.<br>
> > ...<br>
> > I understand it's a hard trade-off: you want to reuse functionality<br>
> > rather than reinvent it in every project... we just need to<br>
> > recognize the cost of doing that.<br>
><br>
> Amrith: Yes, this is part of my concern re: Mistral, and earlier in<br>
> trove's life on depending on Manila for Oracle RAC. Clint raised a<br>
> similar concern about the dependency on Heat.<br>
><br>
> In response, Kevin:<br>
><br>
> > That view of dependencies is why Kubernetes development is outpacing<br>
> > OpenStacks and some users are leaving IMO. Not trying to be mean<br>
> > here but trying to shine some light on this issue.<br>
><br>
> I disagree, but that's a topic for another email thread and maybe not<br>
> even an email thread but an in-person conversation with suitable<br>
> beverages. It is a religious discussion which is best handled in a<br>
> different forum; such as the emacs-vi forum.<br>
><br>
> ----<br>
><br>
> I wrote:<br>
><br>
> > - A guest agent running on a tenant instance, with connectivity to a<br>
> > shared management message bus is a security loophole; encrypting<br>
> > traffic, per-tenant-passwords, and any other scheme is merely<br>
> > lipstick on a security hole<br>
><br>
> Clint asks:<br>
><br>
>  This is a broad statement, and I'm not sure I understand the actual<br>
>  risk you're presenting here as "a security loophole".<br>
><br>
>  How else would you administer a database server than through some<br>
>  kind of agent? Whether that agent is a python daemon of our making,<br>
>  sshd, or whatever kubernetes component lets you change things,<br>
>  they're all administrative pieces that sit next to the resource.<br>
><br>
> Amrith: The issue is that the guest agent (currently) running in a<br>
> tenants context needs to establish a connection to a shared rabbitmq<br>
> server running in the service (control plane) context. I am fine with<br>
> a guest agent running in the control plan establishing a connection<br>
> into a guest VM if required, not the other way around.<br>
><br>
> ----<br>
><br>
> Clint makes a distinction between a database cluster within an<br>
> OpenStack deployment and an uber database cluster spanning clouds,<br>
> recommending that the latter is best left to a tertiary<br>
> orchestrator. Further, these are two distinct things, pick one and do<br>
> it well.<br>
><br>
> Amrith: A valid approach and one that will allow Trove to focus on the<br>
> high value single OpenStack deployment of a db cluster (and to Jay's<br>
> point, do it well).<br>
><br>
> ----<br>
><br>
> Consensus:<br>
><br>
> Trove should expose (what Matt Fischer calls) BlackBox DB, not storage +<br>
> compute.<br>
><br>
> Address rabbitmq security concerns differently; move guest agent off<br>
> instance.<br>
><br>
> Don't reinvent the orchestration piece.<br>
><br>
> Fewer DB's better support<br>
><br>
> Clusters are first class citizens, not an afterthought<br>
><br>
> Clusters spanning regions and openstack deployments<br>
><br>
> Restart the service VM's discussion:<br>
> <a href="https://review.openstack.org/#/c/438134/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/438134/</a><br>
><br>
> ----<br>
><br>
> Several people emailed me privately and said they (or their companies)<br>
> would like to invest resources in Trove. Some indicated that they (or<br>
> their companies) would like to invest resources in Trove if the<br>
> commitment was towards a certain direction or technology choice.<br>
> Others have offered resources if the direction would be to provide<br>
> an AWS compatible API.<br>
><br>
> To anyone who wants to contribute resources to a project, please do<br>
> it. Big companies considering contributing one or two people to a<br>
> project and making it seem like a big decision is really an indication<br>
> of a lack of seriousness. If the project is really valuable to you,<br>
> you'd have put people on it already. The fact that you haven't speaks<br>
> volumes.<br>
><br>
> To those who want to place pre-conditions on technology choice, I have<br>
> no (good) words for you.<br>
><br>
> Thanks to all who participated, I appreciate all the input. I will be<br>
> setting up a session at the Denver PTG to specifically continue this<br>
> conversation and hope you will all be able to attend. As soon as time<br>
> slots for PTG are announced, I will try and pick this slot and request<br>
> that you please attend.<br>
><br>
> Thanks,<br>
><br>
> -amrith<br>
><br>
><br>
><br>
><br>
> On Sun, Jun 18, 2017 at 6:35 AM, Amrith Kumar <<a href="mailto:amrith.kumar@gmail.com">amrith.kumar@gmail.com</a>><br>
> wrote:<br>
><br>
> > Trove has evolved rapidly over the past several years, since integration<br>
> > in IceHouse when it only supported single instances of a few databases.<br>
> > Today it supports a dozen databases including clusters and replication.<br>
> ><br>
> > The user survey [1] indicates that while there is strong interest in the<br>
> > project, there are few large production deployments that are known of (by<br>
> > the development team).<br>
> ><br>
> > Recent changes in the OpenStack community at large (company realignments,<br>
> > acquisitions, layoffs) and the Trove community in particular, coupled with<br>
> > a mounting burden of technical debt have prompted me to make this proposal<br>
> > to re-architect Trove.<br>
> ><br>
> > This email summarizes several of the issues that face the project, both<br>
> > structurally and architecturally. This email does not claim to include a<br>
> > detailed specification for what the new Trove would look like, merely the<br>
> > recommendation that the community should come together and develop one so<br>
> > that the project can be sustainable and useful to those who wish to use it<br>
> > in the future.<br>
> ><br>
> > TL;DR<br>
> ><br>
> > Trove, with support for a dozen or so databases today, finds itself in a<br>
> > bind because there are few developers, and a code-base with a significant<br>
> > amount of technical debt.<br>
> ><br>
> > Some architectural choices which the team made over the years have<br>
> > consequences which make the project less than ideal for deployers.<br>
> ><br>
> > Given that there are no major production deployments of Trove at present,<br>
> > this provides us an opportunity to reset the project, learn from our v1 and<br>
> > come up with a strong v2.<br>
> ><br>
> > An important aspect of making this proposal work is that we seek to<br>
> > eliminate the effort (planning, and coding) involved in migrating existing<br>
> > Trove v1 deployments to the proposed Trove v2. Effectively, with work<br>
> > beginning on Trove v2 as proposed here, Trove v1 as released with Pike will<br>
> > be marked as deprecated and users will have to migrate to Trove v2 when it<br>
> > becomes available.<br>
> ><br>
> > While I would very much like to continue to support the users on Trove v1<br>
> > through this transition, the simple fact is that absent community<br>
> > participation this will be impossible. Furthermore, given that there are no<br>
> > production deployments of Trove at this time, it seems pointless to build<br>
> > that upgrade path from Trove v1 to Trove v2; it would be the proverbial<br>
> > bridge from nowhere.<br>
> ><br>
> > This (previous) statement is, I realize, contentious. There are those who<br>
> > have told me that an upgrade path must be provided, and there are those who<br>
> > have told me of unnamed deployments of Trove that would suffer. To this,<br>
> > all I can say is that if an upgrade path is of value to you, then please<br>
> > commit the development resources to participate in the community to make<br>
> > that possible. But equally, preventing a v2 of Trove or delaying it will<br>
> > only make the v1 that we have today less valuable.<br>
> ><br>
> > We have learned a lot from v1, and the hope is that we can address that in<br>
> > v2. Some of the more significant things that I have learned are:<br>
> ><br>
> > - We should adopt a versioned front-end API from the very beginning;<br>
> > making the REST API versioned is not a ‘v2 feature’<br>
> ><br>
> > - A guest agent running on a tenant instance, with connectivity to a<br>
> > shared management message bus is a security loophole; encrypting traffic,<br>
> > per-tenant-passwords, and any other scheme is merely lipstick on a security<br>
> > hole<br>
> ><br>
> > - Reliance on Nova for compute resources is fine, but dependence on Nova<br>
> > VM specific capabilities (like instance rebuild) is not; it makes things<br>
> > like containers or bare-metal second class citizens<br>
> ><br>
> > - A fair portion of what Trove does is resource orchestration; don’t<br>
> > reinvent the wheel, there’s Heat for that. Admittedly, Heat wasn’t as far<br>
> > along when Trove got started but that’s not the case today and we have an<br>
> > opportunity to fix that now<br>
> ><br>
> > - A similarly significant portion of what Trove does is to implement a<br>
> > state-machine that will perform specific workflows involved in implementing<br>
> > database specific operations. This makes the Trove taskmanager a stateful<br>
> > entity. Some of the operations could take a fair amount of time. This is a<br>
> > serious architectural flaw<br>
> ><br>
> > - Tenants should not ever be able to directly interact with the underlying<br>
> > storage and compute used by database instances; that should be the default<br>
> > configuration, not an untested deployment alternative<br>
> ><br>
> > - The CI should test all databases that are considered to be ‘supported’<br>
> > without excessive use of resources in the gate; better code modularization<br>
> > will help determine the tests which can safely be skipped in testing changes<br>
> ><br>
> > - Clusters should be first class citizens not an afterthought, single<br>
> > instance databases may be the ‘special case’, not the other way around<br>
> ><br>
> > - The project must provide guest images (or at least complete tooling for<br>
> > deployers to build these); while the project can’t distribute operating<br>
> > systems and database software, the current deployment model merely impedes<br>
> > adoption<br>
> ><br>
> > - Clusters spanning OpenStack deployments are a real thing that must be<br>
> > supported<br>
> ><br>
> > This might sound harsh, that isn’t the intent. Each of these is the<br>
> > consequence of one or more perfectly rational decisions. Some of those<br>
> > decisions have had unintended consequences, and others were made knowing<br>
> > that we would be incurring some technical debt; debt we have not had the<br>
> > time or resources to address. Fixing all these is not impossible, it just<br>
> > takes the dedication of resources by the community.<br>
> ><br>
> > I do not have a complete design for what the new Trove would look like.<br>
> > For example, I don’t know how we will interact with other projects (like<br>
> > Heat). Many questions remain to be explored and answered.<br>
> ><br>
> > Would it suffice to just use the existing Heat resources and build<br>
> > templates around those, or will it be better to implement custom Trove<br>
> > resources and then orchestrate things based on those resources?<br>
> ><br>
> > Would Trove implement the workflows required for multi-stage database<br>
> > operations by itself, or would it rely on some other project (say Mistral)<br>
> > for this? Is Mistral really a workflow service, or just cron on steroids? I<br>
> > don’t know the answer but I would like to find out.<br>
> ><br>
> > While we don’t have the answers to these questions, I think this is a<br>
> > conversation that we must have, one that we must decide on, and then as a<br>
> > community commit the resources required to make a Trove v2 which delivers<br>
> > on the mission of the project; “To provide scalable and reliable Cloud<br>
> > Database as a Service provisioning functionality for both relational and<br>
> > non-relational database engines, and to continue to improve its<br>
> > fully-featured and extensible open source framework.”[2]<br>
> ><br>
> > Thanks,<br>
> ><br>
> > -amrith​<br>
> ><br>
> ><br>
> > [1] <a href="https://www.openstack.org/assets/survey/April2017SurveyReport.pdf" rel="noreferrer" target="_blank">https://www.openstack.org/<wbr>assets/survey/<wbr>April2017SurveyReport.pdf</a><br>
> > [2] <a href="https://wiki.openstack.org/wiki/Trove#Mission_Statement" rel="noreferrer" target="_blank">https://wiki.openstack.org/<wbr>wiki/Trove#Mission_Statement</a><br>
> ><br>
> ><br>
> ><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>