[Fly.io] Upcoming App(s) migration to our V2 Platform

[dlphnkck]

Hi, I've been using the LiveSync plugin in Obsidian for a while now. I've been using the LiveSync plugin in Obsidian for a while now and can't imagine my life without it!

BTW, I received an email from Fly.io with the subject "[Fly.io] Upcoming App(s) migration to our V2 Platform".

Is there anything users of the Obsidian LiveSync plugin should do?

To make sure none of your data is lost during migration, we strongly suggest it’s stored in a volume. Any data your app has written to its root file system will be deleted on migration. This is not due to the migration, but due to the fact that Fly.io customer VMs are rebuilt on every restart. Data that’s stored on persistent Fly Volumes is preserved through the migration process. If you need help or extra time to prepare your app for migration, please reach out via your support contact or our community forums.

You’ll receive an email after each app is migrated. If you prefer, you can migrate your apps now using ‘flyctl migrate-to-v2’, check out the docs for more details!

[vrtmrz]

Thank you for opening the topic! And, I am so happy to hear that the plug-in is working well for us!

If our (yes, my one for the test was also migrated) CouchDB has been configured without persistence or without disabling auto-stop-machine, the configuration might be lost on every automatic suspension.

I thought that automatic suspension might be a good choice (They say that we do not have to pay while the instance fell asleep). Therefore, I made this Colab-note to make the v2 machine which has persistence.
And the note also enables the swap, owning to address lesser resistance to OOM of v2 machines.

There are some ways to adjust the configuration. However, making it again is almost the easiest. And it means we have a place to back while in process.

I hope that this might help us!

[dlphnkck]

Hi. Sorry for the late reply.
Thanks for taking the time to reply.

I have reviewed the instructions and settings for running "deploy_couchdb_to_flyio_v2_with_swap.ipynb" in the Jupyter Notebook that you provided.
I understand that running "deploy_couchdb_to_flyio_v2_with_swap.ipynb" in Jupyter Notebook seems manageable.

Now I'm a little concerned because it seems to take more time to fetch data from the newly created Fly.io's CouchDB to each device than it does to rebuild the database.

Thank you for your reply on this issue.
I would like to run "deploy_couchdb_to_flyio_v2_with_swap.ipynb" in Jupyter Notebook this Saturday and Sunday.

Thank you very much for your time and guidance on this issue.

[vrtmrz]

I am glad to hear that the note was useful.

As additional information, we can also replicate from the existing remote database to a new remote using CouchDB UI without Self-hosted LiveSync.
If we have replicated and prepared it in advance before using it from Self-hosted LiveSync, we can use the new remote in the same way as before. Replication could be set up in either the old or new database. (from https://your-instance/#/replication).

[dlphnkck]

Hi. I have successfully followed the procedure of running deploy_couchdb_to_flyio_v2_with_swap.ipynb in Google Colab as you instructed.

It was very easy compared to the last time because I did not have to type in the commands by hand, just by flicking the buttons for each cell.
Thank you very much.

• However, I had trouble using the flyctl scale command to free the CPU from the previous application and assign it to the new application because the previous application was still hogging a CPU even though the VM only had one CPU.

Well, here's the main problem. Thanks to your help, we have successfully migrated to Fly.io v2, but the VM is often in "Suspended" state.

Creating fly.toml with deploy_couchdb_to_flyio_v2_with_swap.ipynb will set the following

auto_stop_machines = true
auto_start_machines = true
min_machines_running = 0

Read The Automatically Stop and Start Machines · Fly Docs
https://fly.io/docs/apps/autostart-stop/

Existing V2 Apps—or any V2 Apps that don’t have these settings in fly.toml—have the default values auto_start_machines = true and auto_stop_machines = false.

In general, we recommend setting auto_stop_machines and auto_start_machines to the same value to avoid having Machines that either never start or never stop.

It says something like.

1. In this case, is there any problem setting the VM to stop?
2. If the VM is stopped, how can I manually force the VM to restart?

That's all.
Thanks in advance.