+1 on moving away from Riak and using postgres instead. Riak can be a pain(atleast for new users) to set up and debug.
--Srijeet From: John Rushford <jjrushf...@gmail.com> Date: Monday, December 7, 2020 at 8:07 PM To: dev@trafficcontrol.apache.org <dev@trafficcontrol.apache.org> Subject: Re: [EXTERNAL] Re: Replace Riak w/ PostgreSQL +1 on using Postgres. I’ve played around with Postgres and pgcrypto. Keeping certs and sig keys encrypted is easily done in postgres. I used asymmetric public private key encryption with pgcrypto where I stored the public key to encrypt in a database table. The private key was stored apart from the database and used by an api that had secure access to the private key. This worked quite well and is mostly done with Postgres queries Sent from my iPhone > On Dec 7, 2020, at 4:00 PM, Gray, Jonathan > <jonathan_g...@comcast.com.invalid> wrote: > > HashiCorp Vault and/or Consul is the only other primary contender I think > we've had proposed, but I'm +1/+1 as well. > > Jonathan G > > On 12/7/20, 3:58 PM, "Rawlin Peters" <raw...@apache.org> wrote: > > Yes, I agree with the plugin interface as well, but that is what I was > hoping to defer to a follow-up thread, preferably with a rough draft > of a blueprint in hand. First, I just want to get an official > consensus on PostgreSQL (in this case as the _main_ plugin > implementation). > > - Rawlin > >> On Mon, Dec 7, 2020 at 2:24 PM Robert O Butts <r...@apache.org> wrote: >> >> +1 and +1 to what @neuman said. I'd vote this be framed more like "change >> TO secret store to a Plugin interface, and ATC will provide a Postgres >> Plugin." >> >> I'd also like to note, I believe our company has a legal requirement to >> have a separate "secret" database, so the Postgres secret store needs to at >> least have the ability to be a separate DB URL+auth than the primary TO >> Postgres DB. >> >> >>> On Mon, Dec 7, 2020 at 2:13 PM Dave Neuman <neu...@apache.org> wrote: >>> >>> I am +1 for using Postgres, however we should consider implementing the >>> "secret store" functionality in such a way that people can choose to >>> implement whatever backend they want. I think it can be accomplished using >>> the TO plugin functionality but I am sure people more familiar with the >>> code these days would know better. This would also provide a built in way >>> to migrate from one to the other without forcing everyone to change. >>> >>> >>> >>>> On Mon, Dec 7, 2020 at 1:48 PM Rawlin Peters <raw...@apache.org> wrote: >>> >>>> Hey folks, >>>> >>>> I hope by now everyone can agree that we need to replace Riak (it's >>>> been unmaintained for quite some time now). However, we might not all >>>> agree yet on what it should be replaced with (at least not >>>> officially). We've discussed it in threads here and there, but I'd >>>> like to get some official consensus before we really hit the ground >>>> running. >>>> >>>> I would like to propose that we replace Riak with PostgreSQL. >>>> >>>> Here are some of the reasons that I can think of (and have been >>>> mentioned by others in the past) for us to use PostgreSQL: >>>> - we all have much experience running it in production (because we >>>> already run it for the Traffic Ops database) >>>> - it would simplify ATC deployments by removing one more component >>>> from the system >>>> - it would simplify development as ATC devs are already familiar with >>>> traditional SQL databases, and we could reuse a lot of the existing >>>> code >>>> - it has a healthy community of support and doesn't seem to be losing >>>> steam anytime soon (it still remains the 2nd most popular OSS >>>> relational database behind MySQL [1]) >>>> >>>> I would like this thread to focus on the merits (or lack thereof) of >>>> using PostgreSQL as a replacement for Riak. We can discuss the >>>> low-level implementation details separately in the blueprint I will >>>> propose as a follow-up to this discussion. Unless someone is >>>> vehemently -1 on using PostgreSQL to replace Riak, I will take silence >>>> as assent and move forward with the blueprint process. >>>> >>>> - Rawlin >>>> >>>> [1] >>>> https://urldefense.com/v3/__https://db-engines.com/en/ranking_osvsc__;!!CQl3mcHX2A!Xy7f_5hSaPy1VOI6G3s7dnOKEWWmrpYJK1noQ67A3gTlldrSM596Zx4YjjbMHFUITPk4$<https://urldefense.com/v3/__https:/db-engines.com/en/ranking_osvsc__;!!CQl3mcHX2A!Xy7f_5hSaPy1VOI6G3s7dnOKEWWmrpYJK1noQ67A3gTlldrSM596Zx4YjjbMHFUITPk4$> >>>> >>> >
