superset-init-db job on 1.5.0rc4 image fails with no error messages #19836

majidazimi · 2022-04-25T13:56:46Z

I'm using helm chart 0.6.0 with 1.5.0rc4, however superset-init-db fails with no obvious errors:

Upgrading DB schema...
logging was configured successfully
2022-04-25 13:32:15,777:INFO:superset.utils.logging_configurator:logging was configured successfully
2022-04-25 13:32:15,781:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO  [alembic.runtime.migration] Will assume transactional DDL.
Loaded your LOCAL configuration at [/app/pythonpath/superset_config.py]

Here is my superset config:

import os
from cachelib.redis import RedisCache

def env(key, default=None):
    return os.getenv(key, default)

MAPBOX_API_KEY = env('MAPBOX_API_KEY', '')
CACHE_CONFIG = {
      'CACHE_TYPE': 'redis',
      'CACHE_DEFAULT_TIMEOUT': 300,
      'CACHE_KEY_PREFIX': 'superset_',
      'CACHE_REDIS_HOST': env('REDIS_HOST'),
      'CACHE_REDIS_PORT': env('REDIS_PORT'),
      'CACHE_REDIS_PASSWORD': env('REDIS_PASSWORD'),
      'CACHE_REDIS_DB': env('REDIS_DB', 1),
}
DATA_CACHE_CONFIG = CACHE_CONFIG

SQLALCHEMY_DATABASE_URI = f"postgresql+psycopg2://{env('DB_USER')}:{env('DB_PASS')}@{env('DB_HOST')}:{env('DB_PORT')}/{env('DB_NAME')}"
SQLALCHEMY_TRACK_MODIFICATIONS = True
SECRET_KEY = env('SECRET_KEY', 'thisISaSECRET_1234')

# Flask-WTF flag for CSRF
WTF_CSRF_ENABLED = True
# Add endpoints that need to be exempt from CSRF protection
WTF_CSRF_EXEMPT_LIST = []
# A CSRF token that expires in 1 year
WTF_CSRF_TIME_LIMIT = 60 * 60 * 24 * 365
class CeleryConfig(object):
  CELERY_IMPORTS = ('superset.sql_lab', )
  CELERY_ANNOTATIONS = {'tasks.add': {'rate_limit': '10/s'}}
  BROKER_URL = f"redis://:{env('REDIS_PASSWORD')}@{env('REDIS_HOST')}:{env('REDIS_PORT')}/0"
  CELERY_RESULT_BACKEND = f"redis://:{env('REDIS_PASSWORD')}@{env('REDIS_HOST')}:{env('REDIS_PORT')}/0"

CELERY_CONFIG = CeleryConfig
RESULTS_BACKEND = RedisCache(
      host=env('REDIS_HOST'),
      password=env('REDIS_PASSWORD'),
      port=env('REDIS_PORT'),
      key_prefix='superset_results'
)


# Overrides
# cache_config
FILTER_STATE_CACHE_CONFIG = {
    'CACHE_TYPE': 'redis',
    'CACHE_DEFAULT_TIMEOUT': 600,
    'CACHE_KEY_PREFIX': 'superset_filter_state_',
    'CACHE_REDIS_HOST': env('REDIS_HOST'),
    'CACHE_REDIS_PORT': env('REDIS_PORT'),
    'CACHE_REDIS_PASSWORD': env('REDIS_PASSWORD'),
    'CACHE_REDIS_DB': env('REDIS_DB', 1),
}
EXPLORE_FORM_DATA_CACHE_CONFIG = {
      'CACHE_TYPE': 'redis',
      'CACHE_DEFAULT_TIMEOUT': 600,
      'CACHE_KEY_PREFIX': 'superset_explore_form_data_',
      'CACHE_REDIS_HOST': env('REDIS_HOST'),
      'CACHE_REDIS_PORT': env('REDIS_PORT'),
      'CACHE_REDIS_PASSWORD': env('REDIS_PASSWORD'),
      'CACHE_REDIS_DB': env('REDIS_DB', 1),
  }

I realized superset fab create-admin is the part that is failing [returning exit code 1]

My superset installation is already in place [older version 1.4.2] and I can login to superset. I can see all dashboards, create databases, datasets, ...

Essentially everything works, except this init job.

The text was updated successfully, but these errors were encountered:

sujiplr · 2022-04-26T06:54:11Z

in 0.6.0 helm we are changing the postgresql version from 10 to 14. Can you try with helm 0.5.10 and check, whether still getting the same issue.

majidazimi · 2022-04-26T07:27:06Z

I'm using my own postgresql installation (14.2.0).

sujiplr · 2022-04-26T12:48:32Z

Can you try with helm chart 0.5.10 once

majidazimi · 2022-04-26T13:04:37Z

Still fails. The script fails with no error messages so I can't provide you with more info for debugging. Is there any flag to enable and get deeper insight on this?

sujiplr · 2022-04-26T14:04:04Z

Can you take the complete pod log and check, also you can check the
pods events

Jap8nted · 2022-05-04T14:52:20Z

I have the same error, superset-init-db never starts

`postgresql 14:51:46.43
postgresql 14:51:46.43 Welcome to the Bitnami postgresql container
postgresql 14:51:46.43 Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-postgresql
postgresql 14:51:46.43 Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-postgresql/issues
postgresql 14:51:46.43
postgresql 14:51:46.44 INFO ==> ** Starting PostgreSQL setup **
postgresql 14:51:46.47 INFO ==> Validating settings in POSTGRESQL_* env vars..
postgresql 14:51:46.48 INFO ==> Loading custom pre-init scripts...
postgresql 14:51:46.48 INFO ==> Initializing PostgreSQL database...
postgresql 14:51:46.49 INFO ==> pg_hba.conf file not detected. Generating it...
postgresql 14:51:46.50 INFO ==> Generating local authentication configuration
postgresql 14:51:46.51 INFO ==> Deploying PostgreSQL with persisted data...
postgresql 14:51:46.52 INFO ==> Configuring replication parameters
postgresql 14:51:46.56 INFO ==> Configuring fsync
postgresql 14:51:46.59 INFO ==> Configuring synchronous_replication
postgresql 14:51:46.63 INFO ==> Loading custom scripts...
postgresql 14:51:46.63 INFO ==> Enabling remote connections
postgresql 14:51:46.64 INFO ==> ** PostgreSQL setup finished! **

postgresql 14:51:46.66 INFO ==> ** Starting PostgreSQL **
2022-05-04 14:51:46.677 GMT [1] FATAL: database files are incompatible with server
2022-05-04 14:51:46.677 GMT [1] DETAIL: The data directory was initialized by PostgreSQL version 11, which is not compatible with this version 14.2.`

This is for 0.6.0 Chart.

When I change to 0.5.10

superset-init-db does not start

client.go:596: [debug] superset-init-db: Jobs active: 1, jobs failed: 0, jobs succeeded: 0 Error: INSTALLATION FAILED: failed post-install: timed out waiting for the condition helm.go:84: [debug] failed post-install: timed out waiting for the condition

sujiplr · 2022-05-04T16:50:41Z

@Jap8nted In your case , seems you are already having PostgreSQL 11 version database files and on on you current installation it's asking for 14.2 version. Are you using master branch for the installation or any specific version of superset.

Jap8nted · 2022-05-05T14:21:07Z

Well I just installed using helm version 0.6.0 and 0.5.10, dont really know what branch are those using.

emilija-omnisend · 2022-06-03T10:28:31Z

Having the same issue with 1.5.0 or 1.5.1rc1 tags. The superset-init-job fails but nothing seems wrong in the logs. Deleting the pod, deployment, restarting, nothing helps.

Here's a full log:

Requirement already satisfied: psycopg2-binary==2.9.1 in /usr/local/lib/python3.8/site-packages (2.9.1)
Collecting pybigquery==0.10.2
  Downloading pybigquery-0.10.2-py2.py3-none-any.whl (23 kB)
Requirement already satisfied: redis==3.5.3 in /usr/local/lib/python3.8/site-packages (3.5.3)
Collecting google-auth<3.0.0dev,>=1.25.0
  Downloading google_auth-2.6.6-py2.py3-none-any.whl (156 kB)
Requirement already satisfied: future in /usr/local/lib/python3.8/site-packages (from pybigquery==0.10.2) (0.18.2)
Collecting google-cloud-bigquery>=2.19.0
  Downloading google_cloud_bigquery-3.1.0-py2.py3-none-any.whl (211 kB)
Collecting google-api-core>=1.30.0
  Downloading google_api_core-2.8.1-py3-none-any.whl (114 kB)
Requirement already satisfied: sqlalchemy<1.5.0dev,>=1.2.0 in /usr/local/lib/python3.8/site-packages (from pybigquery==0.10.2) (1.3.24)
Requirement already satisfied: requests<3.0.0dev,>=2.18.0 in /usr/local/lib/python3.8/site-packages (from google-api-core>=1.30.0->pybigquery==0.10.2) (2.26.0)
Collecting protobuf<4.0.0dev,>=3.15.0
  Downloading protobuf-3.20.1-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.whl (1.0 MB)
Collecting googleapis-common-protos<2.0dev,>=1.56.2
  Downloading googleapis_common_protos-1.56.2-py2.py3-none-any.whl (211 kB)
Collecting pyasn1-modules>=0.2.1
  Downloading pyasn1_modules-0.2.8-py2.py3-none-any.whl (155 kB)
Collecting rsa<5,>=3.1.4
  Downloading rsa-4.8-py3-none-any.whl (39 kB)
Requirement already satisfied: six>=1.9.0 in /usr/local/lib/python3.8/site-packages (from google-auth<3.0.0dev,>=1.25.0->pybigquery==0.10.2) (1.16.0)
Collecting cachetools<6.0,>=2.0.0
  Downloading cachetools-5.2.0-py3-none-any.whl (9.3 kB)
Requirement already satisfied: python-dateutil<3.0dev,>=2.7.2 in /usr/local/lib/python3.8/site-packages (from google-cloud-bigquery>=2.19.0->pybigquery==0.10.2) (2.8.2)
Collecting google-cloud-core<3.0.0dev,>=1.4.1
  Downloading google_cloud_core-2.3.0-py2.py3-none-any.whl (29 kB)
Collecting google-resumable-media<3.0dev,>=0.6.0
  Downloading google_resumable_media-2.3.3-py2.py3-none-any.whl (76 kB)
Collecting grpcio<2.0dev,>=1.38.1
  Downloading grpcio-1.46.3-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (4.4 MB)
Requirement already satisfied: packaging>=14.3 in /usr/local/lib/python3.8/site-packages (from google-cloud-bigquery>=2.19.0->pybigquery==0.10.2) (21.3)
Collecting proto-plus>=1.15.0
  Downloading proto_plus-1.20.5-py3-none-any.whl (46 kB)
Collecting google-cloud-bigquery-storage<3.0.0dev,>=2.0.0
  Downloading google_cloud_bigquery_storage-2.13.1-py2.py3-none-any.whl (180 kB)
Requirement already satisfied: pyarrow<9.0dev,>=3.0.0 in /usr/local/lib/python3.8/site-packages (from google-cloud-bigquery>=2.19.0->pybigquery==0.10.2) (5.0.0)
Collecting grpcio-status<2.0dev,>=1.33.2
  Downloading grpcio_status-1.46.3-py3-none-any.whl (10.0 kB)
Collecting google-crc32c<2.0dev,>=1.0
  Downloading google_crc32c-1.3.0-cp38-cp38-manylinux_2_12_x86_64.manylinux2010_x86_64.whl (37 kB)
Requirement already satisfied: pyparsing!=3.0.5,>=2.0.2 in /usr/local/lib/python3.8/site-packages (from packaging>=14.3->google-cloud-bigquery>=2.19.0->pybigquery==0.10.2) (3.0.6)
Requirement already satisfied: numpy>=1.16.6 in /usr/local/lib/python3.8/site-packages (from pyarrow<9.0dev,>=3.0.0->google-cloud-bigquery>=2.19.0->pybigquery==0.10.2) (1.21.1)
Collecting pyasn1<0.5.0,>=0.4.6
  Downloading pyasn1-0.4.8-py2.py3-none-any.whl (77 kB)
Requirement already satisfied: certifi>=2017.4.17 in /usr/local/lib/python3.8/site-packages (from requests<3.0.0dev,>=2.18.0->google-api-core>=1.30.0->pybigquery==0.10.2) (2021.5.30)
Requirement already satisfied: charset-normalizer~=2.0.0 in /usr/local/lib/python3.8/site-packages (from requests<3.0.0dev,>=2.18.0->google-api-core>=1.30.0->pybigquery==0.10.2) (2.0.4)
Requirement already satisfied: urllib3<1.27,>=1.21.1 in /usr/local/lib/python3.8/site-packages (from requests<3.0.0dev,>=2.18.0->google-api-core>=1.30.0->pybigquery==0.10.2) (1.26.6)
Requirement already satisfied: idna<4,>=2.5 in /usr/local/lib/python3.8/site-packages (from requests<3.0.0dev,>=2.18.0->google-api-core>=1.30.0->pybigquery==0.10.2) (3.2)
Installing collected packages: pyasn1, rsa, pyasn1-modules, protobuf, cachetools, grpcio, googleapis-common-protos, google-auth, grpcio-status, google-api-core, proto-plus, google-crc32c, google-resumable-media, google-cloud-core, google-cloud-bigquery-storage, google-cloud-bigquery, pybigquery
Successfully installed cachetools-5.2.0 google-api-core-2.8.1 google-auth-2.6.6 google-cloud-bigquery-3.1.0 google-cloud-bigquery-storage-2.13.1 google-cloud-core-2.3.0 google-crc32c-1.3.0 google-resumable-media-2.3.3 googleapis-common-protos-1.56.2 grpcio-1.46.3 grpcio-status-1.46.3 proto-plus-1.20.5 protobuf-3.20.1 pyasn1-0.4.8 pyasn1-modules-0.2.8 pybigquery-0.10.2 rsa-4.8
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
WARNING: You are using pip version 21.2.4; however, version 22.1.2 is available.
You should consider upgrading via the '/usr/local/bin/python -m pip install --upgrade pip' command.
Upgrading DB schema...
logging was configured successfully
2022-06-03 09:06:52,220:INFO:superset.utils.logging_configurator:logging was configured successfully
2022-06-03 09:06:52,229:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
Falling back to the built-in cache, that stores data in the metadata database, for the followinng cache: `FILTER_STATE_CACHE_CONFIG`. It is recommended to use `RedisCache`, `MemcachedCache` or another dedicated caching backend for production deployments
2022-06-03 09:06:52,233:WARNING:superset.utils.cache_manager:Falling back to the built-in cache, that stores data in the metadata database, for the followinng cache: `FILTER_STATE_CACHE_CONFIG`. It is recommended to use `RedisCache`, `MemcachedCache` or another dedicated caching backend for production deployments
Falling back to the built-in cache, that stores data in the metadata database, for the followinng cache: `EXPLORE_FORM_DATA_CACHE_CONFIG`. It is recommended to use `RedisCache`, `MemcachedCache` or another dedicated caching backend for production deployments
2022-06-03 09:06:52,240:WARNING:superset.utils.cache_manager:Falling back to the built-in cache, that stores data in the metadata database, for the followinng cache: `EXPLORE_FORM_DATA_CACHE_CONFIG`. It is recommended to use `RedisCache`, `MemcachedCache` or another dedicated caching backend for production deployments
INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO  [alembic.runtime.migration] Will assume transactional DDL.
Loaded your LOCAL configuration at [/app/pythonpath/superset_config.py]

Upon further inspection, this command superset db upgrade returns exit code 1.

And upon even further inspection, the hidden errors appear to be related to this: miguelgrinberg/Flask-Migrate#434 . There's a hackish way to see the actual error message, though, it's in the linked issue.

rusackas · 2022-06-10T23:49:12Z

@john-bodley wondering if you have any insight here, or know someone good to redirect this to :)

adberger · 2022-07-07T15:07:26Z

For me it works with 1.5.1 but fails with latest, just FYI

b3nk3nobi · 2022-10-03T13:49:39Z

Same thing happens on 1.5.2 image :

Upgrading DB schema...
logging was configured successfully
2022-10-03 11:04:19,607:INFO:superset.utils.logging_configurator:logging was configured successfully
2022-10-03 11:04:19,617:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO  [alembic.runtime.migration] Will assume transactional DDL.
Loaded your LOCAL configuration at [/app/pythonpath/superset_config.py]

Chart version: 0.7.1

huyhandes · 2022-10-27T08:24:30Z

Same thing happens on 1.5.2 image :

Upgrading DB schema...
logging was configured successfully
2022-10-03 11:04:19,607:INFO:superset.utils.logging_configurator:logging was configured successfully
2022-10-03 11:04:19,617:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO  [alembic.runtime.migration] Will assume transactional DDL.
Loaded your LOCAL configuration at [/app/pythonpath/superset_config.py]

Chart version: 0.7.1

Same with me for 2.0.1rc2, there's no error message and init failed completely.

stasDomb · 2022-10-27T11:43:09Z

The same problem.
Superset versions: 2.0.0, 2.0.1, 1.5.1,1.5.2.
And for me it's unstable. At some point it starts working good...

stasDomb · 2022-11-01T10:53:48Z

Could somebody help with that?
Checked with helm chart 0.7.6 and 2.0.1rc2. Still have this problem.

dangal95 · 2022-11-07T11:47:08Z

I am having the same issue issue using the Superset image 1.5.2 and HELM chart version 0.7.6. Any idea why this happens? The application itself runs, I can access the UI and the superset-, superset-worker-, and superset-celerybeat- pods are running. I can also see that tables are generated by Superset in my Postgres database. Does this failing actually effect the application in any way?

stasDomb · 2022-11-19T10:20:45Z

I've resolved this issue with removing all deployments and re-deploy after that. Looks like when you migrate from one version to another sometimes there are some problems with DB initialisation

josechudev · 2022-12-02T19:24:57Z

I downgraded from helm chart 0.7.7 to 0.7.6 and it worked.

anemyte · 2023-02-08T12:49:55Z

After manually applying changes from #22991 I can see the following:

Loaded your LOCAL configuration at [/app/pythonpath/superset_config.py]
logging was configured successfully
2023-02-08 12:45:19,384:INFO:superset.utils.logging_configurator:logging was configured successfully
INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO  [alembic.runtime.migration] Will assume transactional DDL.
ERROR [flask_migrate] Error: Can't locate revision identified by '9d8a8d575284'

superset 1.5.3
postgres 12.12
chart 0.7.6 (also tested with 0.5.10 and 0.8.2)

The alembic_version table contains one row:

# select * from alembic_version ;
 version_num  
--------------
 9d8a8d575284
(1 row)

Inspecting /app/superset/migrations/versions inside the container I found that revision 9d8a8d575284 is not present there. I created it and pasted there contents of this file but it didn't help:

root@superset-init-db-debug:/app# superset db upgrade --sql 
Loaded your LOCAL configuration at [/app/pythonpath/superset_config.py]
logging was configured successfully
2023-02-08 13:48:20,004:INFO:superset.utils.logging_configurator:logging was configured successfully
INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO  [alembic.runtime.migration] Generating static SQL
INFO  [alembic.runtime.migration] Will assume transactional DDL.
BEGIN;

/usr/local/lib/python3.8/site-packages/alembic/script/revision.py:188: UserWarning: Revision 8b841273bec3 referenced from 8b841273bec3, b0d0249074e4 -> 9d8a8d575284 (head) (mergepoint), merge point
Revision ID: 9d8a8d575284
Revises: ('8b841273bec3', 'b0d0249074e4')
Create Date: 2022-04-06 14:10:40.433050 is not present
  util.warn(
Traceback (most recent call last):
  File "/usr/local/bin/superset", line 33, in <module>
... truncated...
KeyError: '8b841273bec3'

Apparently, there are several revisions missing. I took the list from here and put it through some bash'n'grep until I got this list of missing revisions:

6f139c533bea
8b841273bec3
2ed890b36b94
a9422eeaae74
b0d0249074e4
cecc6bf46990
ad07e4fdbaba
cbe71abde154
e786798587de
e09b4ae78457
f3afaf1f11f0
7fb8bca906d2
409c7b420ab0
cdcf3d64daf4
c747c78868b6
06e1e70058c7
ffa79af61a56
a39867932713
6d3c6f9d665d
291f024254b5
deb4c9d4a4ef
f3c2d8ec8595
4ce1d9b25135

gamunu · 2023-03-27T05:25:44Z

Upgrading the chart version from 0.8.4 to 0.8.10 fails with the same no error

Requirement already satisfied: psycopg2-binary==2.9.1 in /usr/local/lib/python3.8/site-packages (2.9.1)
Collecting Authlib==1.2.0
  Downloading Authlib-1.2.0-py2.py3-none-any.whl (214 kB)
Requirement already satisfied: redis==3.5.3 in /usr/local/lib/python3.8/site-packages (3.5.3)
Requirement already satisfied: cryptography>=3.2 in /usr/local/lib/python3.8/site-packages (from Authlib==1.2.0) (3.4.7)
Requirement already satisfied: cffi>=1.12 in /usr/local/lib/python3.8/site-packages (from cryptography>=3.2->Authlib==1.2.0) (1.14.6)
Requirement already satisfied: pycparser in /usr/local/lib/python3.8/site-packages (from cffi>=1.12->cryptography>=3.2->Authlib==1.2.0) (2.20)
Installing collected packages: Authlib
Successfully installed Authlib-1.2.0
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
WARNING: You are using pip version 21.2.4; however, version 23.0.1 is available.
You should consider upgrading via the '/usr/local/bin/python -m pip install --upgrade pip' command.
Upgrading DB schema...
logging was configured successfully
2023-03-27 05:22:03,958:INFO:superset.utils.logging_configurator:logging was configured successfully
2023-03-27 05:22:03,965:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
We haven't found any Content Security Policy (CSP) defined in the configurations. Please make sure to configure CSP using the TALISMAN_CONFIG key or any other external software. Failing to configure CSP have serious security implications. Check https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP for more information. You can disable this warning using the CONTENT_SECURITY_POLICY_WARNING key.
2023-03-27 05:22:03,966:WARNING:superset.initialization:We haven't found any Content Security Policy (CSP) defined in the configurations. Please make sure to configure CSP using the TALISMAN_CONFIG key or any other external software. Failing to configure CSP have serious security implications. Check https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP for more information. You can disable this warning using the CONTENT_SECURITY_POLICY_WARNING key.
Falling back to the built-in cache, that stores data in the metadata database, for the following cache: `FILTER_STATE_CACHE_CONFIG`. It is recommended to use `RedisCache`, `MemcachedCache` or another dedicated caching backend for production deployments
2023-03-27 05:22:03,970:WARNING:superset.utils.cache_manager:Falling back to the built-in cache, that stores data in the metadata database, for the following cache: `FILTER_STATE_CACHE_CONFIG`. It is recommended to use `RedisCache`, `MemcachedCache` or another dedicated caching backend for production deployments
Falling back to the built-in cache, that stores data in the metadata database, for the following cache: `EXPLORE_FORM_DATA_CACHE_CONFIG`. It is recommended to use `RedisCache`, `MemcachedCache` or another dedicated caching backend for production deployments
2023-03-27 05:22:03,977:WARNING:superset.utils.cache_manager:Falling back to the built-in cache, that stores data in the metadata database, for the following cache: `EXPLORE_FORM_DATA_CACHE_CONFIG`. It is recommended to use `RedisCache`, `MemcachedCache` or another dedicated caching backend for production deployments
INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO  [alembic.runtime.migration] Will assume transactional DDL.
Loaded your LOCAL configuration at [/app/pythonpath/superset_config.py]

frafful · 2023-05-10T16:55:59Z

I'm struggling here with the same error, tried many versions of the chart, no success so far. Is there any workaround?

gamunu · 2023-05-10T19:26:31Z

@frafful I finally figured out the issue. The default helm chart uses the latest image, which is the dev build. I believe the random changeset gets introduced and removed into the dev docker image.

Note: following these steps may corrupt the database structure, so make a database backup before proceeding

The solution is to use the stable version of the superset docker image in the helm chart and then fix the version id in the alembic_version table of the superset database.

Add/Update the helm values
e.g:

image:
  repository: apache/superset
  tag: 2.1.0
  pullPolicy: IfNotPresent

I had to jump through several hoops to fix the init job. Initially, getting access to the Postgres database.

kubectl port-forward svc/superset-postgresql 5432:5432 -n <namespace>

With this now, you can use pgsql cli to access the database. I think the default username and password are superset and superset.

Next, find the latest migration file version.

kubectl exec <superset-pod-name> ls superset/migrations/versions

for me, it was 4ce1d9b25135 - 2022-11-28_17-51_4ce1d9b25135_remove_filter_bar_orientation.py

find the current version value in the alembic_version using a select query and update the version for this file version in the database

UPDATE alembic_version
SET version_num = '4ce1d9b25135'
WHERE version_num = '<current version>';

run the superset_init.sh, this will fail with an error saying the table/column exists in the database. That error message shows the next migration version the init is applying. You can copy that version and update the version table again. You will have to repeat this until you find the right version.

kubectl exec -it <superset-pod-name> bash

bash -c ". pythonpath/superset_init.sh"

The final version id worked for me is this f3c2d8ec8595 for v2.1.0,

UPDATE alembic_version
SET version_num = 'f3c2d8ec8595'
WHERE version_num = '4ce1d9b25135';

sfirke · 2023-10-13T16:42:38Z

Thanks @gamunu for sorting out the issue. As of #25373 the Helm chart is currently at pointing at 3.0.0, which should address the underlying issue here.

As that has been fixed, and most of this thread is about the no-longer-supported 1.5.x version, I am going to close this issue. If folks find this issue reappearing on the latest version of the helm chart, please feel free to open a new issue.

majidazimi added the #bug Bug report label Apr 25, 2022

garyng mentioned this issue Jun 4, 2022

superset-init-db job fails with relation "ab_permission_view_role" does not exist when init.adminUser.username is overriden in 1.5.1rc1 #20265

Closed

3 tasks

treygilliland mentioned this issue Feb 3, 2023

fix(migrations): Flask-Migrate output is not logged during alembic migrations #17991 #22991

Merged

9 tasks

sfirke closed this as completed Oct 13, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

superset-init-db job on 1.5.0rc4 image fails with no error messages #19836

superset-init-db job on 1.5.0rc4 image fails with no error messages #19836

majidazimi commented Apr 25, 2022

sujiplr commented Apr 26, 2022

majidazimi commented Apr 26, 2022

sujiplr commented Apr 26, 2022

majidazimi commented Apr 26, 2022

sujiplr commented Apr 26, 2022

Jap8nted commented May 4, 2022 •

edited

Loading

sujiplr commented May 4, 2022

Jap8nted commented May 5, 2022

emilija-omnisend commented Jun 3, 2022 •

edited

Loading

rusackas commented Jun 10, 2022

adberger commented Jul 7, 2022

b3nk3nobi commented Oct 3, 2022

huyhandes commented Oct 27, 2022

stasDomb commented Oct 27, 2022 •

edited

Loading

stasDomb commented Nov 1, 2022

dangal95 commented Nov 7, 2022

stasDomb commented Nov 19, 2022

josechudev commented Dec 2, 2022

anemyte commented Feb 8, 2023 •

edited

Loading

gamunu commented Mar 27, 2023

frafful commented May 10, 2023

gamunu commented May 10, 2023 •

edited

Loading

sfirke commented Oct 13, 2023

superset-init-db job on 1.5.0rc4 image fails with no error messages #19836

superset-init-db job on 1.5.0rc4 image fails with no error messages #19836

Comments

majidazimi commented Apr 25, 2022

sujiplr commented Apr 26, 2022

majidazimi commented Apr 26, 2022

sujiplr commented Apr 26, 2022

majidazimi commented Apr 26, 2022

sujiplr commented Apr 26, 2022

Jap8nted commented May 4, 2022 • edited Loading

sujiplr commented May 4, 2022

Jap8nted commented May 5, 2022

emilija-omnisend commented Jun 3, 2022 • edited Loading

rusackas commented Jun 10, 2022

adberger commented Jul 7, 2022

b3nk3nobi commented Oct 3, 2022

huyhandes commented Oct 27, 2022

stasDomb commented Oct 27, 2022 • edited Loading

stasDomb commented Nov 1, 2022

dangal95 commented Nov 7, 2022

stasDomb commented Nov 19, 2022

josechudev commented Dec 2, 2022

anemyte commented Feb 8, 2023 • edited Loading

gamunu commented Mar 27, 2023

frafful commented May 10, 2023

gamunu commented May 10, 2023 • edited Loading

sfirke commented Oct 13, 2023

Jap8nted commented May 4, 2022 •

edited

Loading

emilija-omnisend commented Jun 3, 2022 •

edited

Loading

stasDomb commented Oct 27, 2022 •

edited

Loading

anemyte commented Feb 8, 2023 •

edited

Loading

gamunu commented May 10, 2023 •

edited

Loading