Skip to content

Feature: Add connection libraries to the superset instance #616

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Maleware opened this issue Apr 9, 2025 · 2 comments
Open

Feature: Add connection libraries to the superset instance #616

Maleware opened this issue Apr 9, 2025 · 2 comments

Comments

@Maleware
Copy link
Member

Maleware commented Apr 9, 2025

Current Situation

if a user want's to have e.g. mssql as a database connector present in a superset instance, he'd need to either

  1. Build a custom image using pip install pymssql
  2. kubectl exec -- pip install pymssql
  3. Overrite startup commands to execute pip install pymssql

a list of possible connector options can be found here

Proposal

As a platform provider we should enable a user to be flexible and on the other hand ensure that our images are as lean and secure as possible.

Option 1

Include common connectors in our image.

Upside

  1. User has maintained and out of the box images that "just work" for their purposes
  2. Stackable has full control over versioning and can ensure and guarantee that specific scenarios will work
  3. Low hanging fruit ( up to decision on what include, that might be bigger than it seems )

Downside

  1. We'd need to be responsible for upcoming bugs, CVE's as well as maintaining library versions.
  2. Larger images and delivery of not needed software

Option 2

Allow users to specify python packages to install in crds

Upside

  1. Users can specify the libraries they want to be installed
  2. Lean and secure base images
  3. No maintenance on Stackable end needed
  4. Mechanism might be reusable for Airflow

Downside

  1. Open up the installation to malicious software
  2. Needs to be an Override as we can't take guarantee of user defined packages
  3. Larger development efforts expected
@stefanigel
Copy link
Member

I like the idea of making users' life easier. I like option 2 more than option 1, as it also maybe a license issue as there are many commercial db drivers in the world.
Adding db drivers / libs / connections may easily become a never ending story as every user might look for sth different.

@Maleware
Copy link
Member Author

Maleware commented Apr 9, 2025

Me too, but we'd need to estimate effort and security. I like that this could be reused in python based products.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants