superset
superset copied to clipboard
apache
superset-init-db job on 1.5.0rc4 image fails with no error messages
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.
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.
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?
Can you take the complete pod log and check, also you can check the pods events
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
@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.
Well I just installed using helm version 0.6.0 and 0.5.10, dont really know what branch are those using.
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: https://github.com/miguelgrinberg/Flask-Migrate/issues/434 . There's a hackish way to see the actual error message, though, it's in the linked issue.
@john-bodley wondering if you have any insight here, or know someone good to redirect this to :)
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 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.
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...
Could somebody help with that? Checked with helm chart 0.7.6 and 2.0.1rc2. Still have this problem.
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?
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
After manually applying changes from https://github.com/apache/superset/pull/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
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]
I'm struggling here with the same error, tried many versions of the chart, no success so far. Is there any workaround?
@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_versionusing 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';
Thanks @gamunu for sorting out the issue. As of https://github.com/apache/superset/pull/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.
