Migration errors 9.1.2 to 21.6.1: 'Project' object has no attribute 'get_option'

Hello!

I’m migrating from a very old on-premise install which is using loose python installtion, into the dockerized config. Per instructions, i went to 9.1.2 first. Then, i exported my postgres database to a new database. I pointed sentry-web container at this new database (still 9.6) using the sentry/sentry.conf.py. I also set it to migrate ALL events. (many years worth!)

Per: https://develop.sentry.dev/self-hosted/#upgrading
“9.0.0 → 9.1.2 → 21.6.1 → latest”

Since my DB is currently on 9.1.2, I set the onprem bootstrap to go to sentry:21.6.1.

Migration gets here:

  Applying sentry.0023_hide_environment_none_20191126... OK
  Applying sentry.0024_auto_20191230_2052...Events to process: 231329

An error occured while trying to migrate the following event: <sentry.eventstore.models.Event object at 0x7ff941841ba8>

Project' object has no attribute 'get_option'

(this error repeated quite a lot of times,until i cancel)

Any ideas? Should I go through another release first?

thanks for the help.

My migration is still in progress, but it looks like going to 20.12.1 first is not producing this error (yet, at least :slight_smile: Will go to 21.6.1 after that and report results.

Well, I got it up (on 20.12.1) and it seems the projects came through, but no events show.

There were some migration errors – perhaps these caused the lack of events? Any idea on this one?

  Applying sentry.0046_auto_20200221_1735... OK
  Applying sentry.0047_auto_20200224_2319... OK
  Applying sentry.0048_auto_20200302_1825... OK
  Applying sentry.0049_auto_20200304_0254... OK
  Applying sentry.0050_auto_20200306_2346... OK
Audit Log Entrys: N/A% |                                        | ETA:  --:--:--NoneType: None
23:26:52 [ERROR] sentry.runner.initializer: django.compat.model-unpickle-compat (model_id=('sentry', 'Team') attrs=[] factory=<function __simple_class_factory_compat at 0x7f94dc103ea0>)
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/sentry/monkey/pickle.py", line 213, in py3_compat_pickle_loads
    return original_pickle_loads(*args, **kwargs)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xdd in position 1: ordinal not in range(128)
23:26:52 [ERROR] sentry.runner.initializer: django.compat.model-unpickle-compat (model_id=('sentry', 'Team') attrs=[] factory=<function __simple_class_factory_compat at 0x7f94dc103ea0>)
NoneType: None
23:26:52 [ERROR] sentry.runner.initializer: django.compat.model-unpickle-compat (model_id=('sentry', 'Team') attrs=[] factory=<function __simple_class_factory_compat at 0x7f94dc103ea0>)
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/sentry/monkey/pickle.py", line 213, in py3_compat_pickle_loads
    return original_pickle_loads(*args, **kwargs)

I have a suspicion this may have been caused by not fully wiping all the volumes after changing from 21.6.1 to 20.12.1, may wipe and try again.

Tried again doing 9.6.1 → 20.11.1, clean volumes, it came up with projects and users, but there’s still no events in the GUI of any of my projects after migration. Any tips for investigating why?

Perhaps will try going to some other versions in the 21.x series.

Same kind of issue here! I just did these steps: 9.0.0 -> 9.1.2 -> 21.6.1 as described here.

I will try these steps again: 9.0.0 -> 9.1.2 -> 20.12.1 -> 21.5.1 -> 21.6.1 since this is what DID work a couple of weeks ago.

Going from 9.1.2 to 20.12.1 no more Postgres migration errors, but this time however Kafka errors that will block a successful upgrade eventually.
From the sentry_install_log:

Creating sentry_onpremise_kafka_1      ...
Creating sentry_onpremise_kafka_1      ... done
Creating sentry_onpremise_snuba-api_run ...
Creating sentry_onpremise_snuba-api_run ... done
+ '[' b = - ']'
+ snuba bootstrap --help
+ set -- snuba bootstrap --no-migrate --force
+ set gosu snuba snuba bootstrap --no-migrate --force
+ exec gosu snuba snuba bootstrap --no-migrate --force
%3|1624452273.814|FAIL|rdkafka#producer-1| [thrd:kafka:9092/bootstrap]: kafka:9092/bootstrap: Connect to ipv4#172.21.0.5:9092 failed: Connection refused (after 1ms in state CONNECT)
%3|1624452274.813|FAIL|rdkafka#producer-1| [thrd:kafka:9092/bootstrap]: kafka:9092/bootstrap: Connect to ipv4#172.21.0.5:9092 failed: Connection refused (after 0ms in state CONNECT, 1 identical error(s) suppressed)
2021-06-23 12:44:34,813 Connection to Kafka failed (attempt 0)
Traceback (most recent call last):
  File "/usr/src/snuba/snuba/cli/bootstrap.py", line 55, in bootstrap
    client.list_topics(timeout=1)
cimpl.KafkaException: KafkaError{code=_TRANSPORT,val=-195,str="Failed to get metadata: Local: Broker transport failure"}
%3|1624452275.818|FAIL|rdkafka#producer-2| [thrd:kafka:9092/bootstrap]: kafka:9092/bootstrap: Connect to ipv4#172.21.0.5:9092 failed: Connection refused (after 0ms in state CONNECT)
2021-06-23 12:44:36,819 Connection to Kafka failed (attempt 1)
Traceback (most recent call last):
  File "/usr/src/snuba/snuba/cli/bootstrap.py", line 55, in bootstrap
    client.list_topics(timeout=1)
cimpl.KafkaException: KafkaError{code=_TRANSPORT,val=-195,str="Failed to get metadata: Local: Broker transport failure"}
2021-06-23 12:44:38,300 Topic events created
2021-06-23 12:44:38,301 Topic event-replacements created
2021-06-23 12:44:38,301 Topic snuba-commit-log created
2021-06-23 12:44:38,301 Topic ingest-sessions created
2021-06-23 12:44:38,301 Topic cdc created
2021-06-23 12:44:38,301 Topic outcomes created
2021-06-23 12:44:38,302 Topic errors-replacements created
--no-ansi option is deprecated and will be removed in future versions. Use `--ansi never` instead.
Creating sentry_onpremise_snuba-api_run ...
Creating sentry_onpremise_snuba-api_run ... done

Trying to find the sweet spot. Again.
Going from 9.0.0 -> 9.1.2 -> 21.3.1 is not having the Kafka errors, but does give the 1000s Postgres migration errors.

UPDATE: In the end I went through 9.0.0 -> 9.1.2 -> 20.12.1 -> 21.6.1.
So it seems better to have the mentioned Kafka errors instead of the Postgres ones. :wink:
It’s working at the moment.