Jira (PDB-2124) Please support some database besides PostgresQL

2 views
Skip to first unread message

Johnson Earls (JIRA)

unread,
Nov 3, 2015, 10:53:13 AM11/3/15
to puppe...@googlegroups.com
Johnson Earls created an issue
 
PuppetDB / New Feature PDB-2124
Please support some database besides PostgresQL
Issue Type: New Feature New Feature
Assignee: Unassigned
Components: Platform
Created: 2015/11/03 7:42 AM
Priority: Normal Normal
Reporter: Johnson Earls

My company will not allow the use of PostgresQL without written approval from the CEO. Because of this, I cannot use PuppetDB and therefore can't make use of exported resources or external orchestration utilities.

Please provide official support for some back-end database besides PostgresQL.

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
Atlassian logo

Kenneth Barber (JIRA)

unread,
Nov 3, 2015, 11:30:19 AM11/3/15
to puppe...@googlegroups.com
Kenneth Barber commented on New Feature PDB-2124
 
Re: Please support some database besides PostgresQL

Hi,

So there has been requests in the past for different database support, but without a lot of good reasons, we possibly won't be doing this in a hurry. Of course if we had enough support from the community to support a database variant this would make it easier. More so, what is the correct database to choose, for example in your case - what would be the preferred database? Up until now we've only really received requests for Oracle support from our commercial customers, if this fits the bill and you are a commercial customer I'd reach out to our sales guys.

I'm curious, why won't your company allow PostgreSQL without written approval from the CEO? Whats the reasoning behind this decision in your company? I've never heard of a company making this call before, although I'm sure it happens. Is there a technical reason why PostgreSQL isn't acceptable? In the past most of the reasons for a company choosing one database over another is for local support reasons (ie. you have DBA's skilled in other tech) but usually doesn't result in a complete block on using PostgreSQL, just a reluctance to implement it.

Johnson Earls (JIRA)

unread,
Nov 3, 2015, 12:03:06 PM11/3/15
to puppe...@googlegroups.com
Johnson Earls commented on New Feature PDB-2124

MySQL is the most acceptable choice; Oracle would be a second choice.

PostgreSQL has been declared taboo by the corporate security team, for some reason I cannot fathom.

Kenneth Barber (JIRA)

unread,
Nov 4, 2015, 8:59:07 AM11/4/15
to puppe...@googlegroups.com

> PostgreSQL has been declared taboo by the corporate security team, for some reason I cannot fathom.

Well a reasoning would be helpful. I'm not sure I can build up a case because your company doesn't like PostgreSQL for some unknown reason . I hope you can understand that isn't a good argument .

Most of the reasons for choosing PG only are technical in-fact, and its about reducing the amount of development. We don't use an ORM by choice, because our requirements need to push the database heavily so we work with transformation layers (HoneySQL) but not ORM's, basically we're pretty much translating our query language to SQL on our own.

So for translating some of our uses into other platforms, this isn't trivial. We'd need to write the abstractions for this, and whats more - make sure the platforms are constantly tested like anything. This is why we'd welcome help from the community if it was required, but as yet we've only had a couple of people offer to help, but alas no patches.

And, we're not sure that translating it brings technical benefits either - although I would argue Oracle as a platform might help - especially considering some of its performance related tooling. We use a lot of JSON features, and planning on doing more of that - and each of these platforms has their own ways of dealing with JSON, which would make it tricky. When one diverges at this level, we find ourselves cutting support in PDB for certain backends, which we ended up doing all the time for HSQLDB (which is why we removed it), which is okay for the consumer but the code and our API decisions can be very murky in this world - ie. we have to design around the ability that certain backends won't have XyZ feature.

So if anything, the reason for transferring to other platforms isn't very technical by most peoples standards, except for perhaps the familiarity argument. So in that case, the reasoning I think needs to become a non-technical one - a space we as engineers don't really make calls on most of the time. I personally can't be convinced to work on a MySQL port (and continue to maintain it also, alongside PG) without good reason, when we have so many other problems that need solving above and beyond that, for example - problems that stop our currently happy PostgreSQL users go further and do more things.

Having said all that, we do welcome patches . If someone sent us a MySQL patch, we'd happily review and consider it, TBH.

Johnson Earls (JIRA)

unread,
Mar 30, 2016, 8:39:02 PM3/30/16
to puppe...@googlegroups.com
Johnson Earls commented on New Feature PDB-2124

Since PostgreSQL is still taboo (I think the real reason is that it's a competing product, and not any real security issue), I'm coming back to this with a different tack:

Is there any documentation on how to extend puppet with a new backend/plugin for storeconfigs_backend or facts_terminus - some way that I can at least have puppet record somewhere each time an agent runs, and what facts were used for that agent run? I thought I could use the puppet reports for this, but the puppet reports do not include the facts.

Thanks,
– Johnson

This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
Atlassian logo

Kenneth Barber (JIRA)

unread,
Mar 31, 2016, 5:02:03 AM3/31/16
to puppe...@googlegroups.com

Johnson Earls aah, so you work for Oracle, and PostgreSQL is a no-no for competitive reasons, hence why Larry needs to sign off on it.

The interfaces for storeconfigs and facts_terminus are just termini for the indirector interfaces which are written in ruby today ... there is some documentation here: https://docs.puppetlabs.com/puppet/latest/reference/indirection.html

You can also look at the puppetdb source for examples on the interface: https://github.com/puppetlabs/puppetdb/tree/master/puppet/lib/puppet/indirector

Claudia Petty (Jira)

unread,
Jun 21, 2023, 10:56:08 AM6/21/23
to puppe...@googlegroups.com
Claudia Petty updated an issue
 
Change By: Claudia Petty
Labels: new-feature
This message was sent by Atlassian Jira (v8.20.21#820021-sha1:38274c8)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages