Staging instance for D10 Localize port

Updated the IS to add the previous things.

Does this need integration with the SSO system?

Eventually, yes.

Postponing until migrations are definitely up and running.

Reopening as migrations are nearly ready.

I think this falls into the same blocker as the www.drupal.org migration. We need to put the old database into a new server somehow, with an updated DB version, and that needs infrastructure work.

Once this is done, we just need to add a "helm" folder to it and set the migrations to run, but we are not there yet.

I will communicate it with the team so they are aware of localize being almost ready.

One of the requirements will be to have Drupal core and the modules in use up to date, and preferably on the latest D10 version.

We are meeting later on and I will mention this, but wanted to leave it in the issue.

Steps before going live

• Finish the pending work
• The DA will need to do a review and add the infra-related files
• This project needs to be using the new SSO system first, which is not live yet
• Once the above is good, we should try running through the upgrade using staging’s data.
• For that, we need to make sure the upgrade steps are documented and work. So we'll need details on how to set it all up step by step, how and when to run the migrations, etc. This could be in the readme file in https://gitlab.com/drupal-infrastructure/sites/localize.drupal.org

We discussed today on this matter with fjgarlin and Gábor Hojtsy.

• As we mainly need this instance for tests, we will not be needing SSO at this point.
• As versions of MySQL greatly differ, database dumps need to be converted somehow before they can be imported into the instance. That is the reason why we will not be running migrations frequently: only once to begin with.
• Documentation (README) needs to be enhanced so that sysadmins can know what to do in order to launch a new instance on an actual server, not only locally.
• This instance might be ready after Drupalcon. In order to share environments with people who cannot or are not used to installing a local environment, we might be using tools like DDEV share (or maybe Drupalpod?).

As versions of MySQL greatly differ, database dumps need to be converted somehow before they can be imported into the instance. That is the reason why we will not be running migrations frequently: only once to begin with.

We are doing a general upgrade of MySQL for all Drupal.org production sites in the coming weeks, so this will get better.

This instance might be ready after Drupalcon. In order to share environments during the con with people who cannot or are not used to installing a local environment, we might be using tools like DDEV share (or maybe Drupalpod?).

Please remember to keep the actual data confidential. It is okay to make a public development instance of the site, but do keep it configured as securely as you would a production site.

Please remember to keep the actual data confidential. It is okay to make a public development instance of the site, but do keep it configured as securely as you would a production site.

Certainly, we will not grant users more privileged roles than needed to evaluate the new instance as a regular user, thanks for reminding me.

It took longer than expected™, but we have finally finished testing migrations. Drupal core and projects are up to date, and I added some instructions in the README file. We feel the time has come to set up a staging instance. Please tell us if something is missing.

Thanks for the work on that.

This is then in the same position as the D10 version of www.drupal.org, it needs:
- New SSO system to be in place
- A way to access the D7 database

Once we have these things, we'd be able to try in a dev/stage environment.

We would like to be able to allow testers to work on a common instance. We do not really need SSO right now. How long until you figure out a way to access the D7 database? Can't you work with a dump in the meantime? It is certainly far from being as huge as on drupal.org ^^

Do you need the migrations to be running constantly or is it just a one-off?

Would uploading the DB that you have locally (where I assume migrations where tested against) work? You wouldn’t be able to run migrations but would be able to use the site, right?

Do you need the migrations to be running constantly or is it just a one-off?

One-off.

Would uploading the DB that you have locally (where I assume migrations where tested against) work? You wouldn’t be able to run migrations but would be able to use the site, right?

Yes, that would do.

Yes, this will be a one-off migration with some downtime as the migration runs.

Before staging is built out, we’ll want to make sure the codebase is fully updated for Drupal core, modules, etc.

We recently launched the Drupal 10 version of API.Drupal.org. We’ll want to make sure everything we learned from that is incorporated into the site build.

We'll want to start a checklist for running and launching the migration, so it can be repeated a few times in staging to find issues, and get an idea of how long it will take. What commands are needed to run the migration? What else is needed?

@drumm we added some instructions in the README. Is it OK to you?

On these instances you should include either settings.production.php or settings.stage.php

Note that those files are automatically included in the right environment. Anything specific to stage or prod should go there, and if it's sensitive it should be a environment variable via "getenv".

Of particular importance is the activation of the "live" config split, since most languages are disabled on dev environments because too many of them dramatically slows down installation.

Is this something that is set up via the previously mentioned settings file for production? How is that expected to work per environment?

Queues are decoupled from cron, so we need to set up: ...

How often do those queues need to run? Are they one-offs or they need regular running?