Right now, if you've already attempted an upgrade and try to do it again, it will fail because it's trying to create migrations that already exist. What should the form do in this case, and what do we in general tell people who attempted an upgrade that failed (or succeeded but want to start over)?

What to tell people:

  1. Restore your database backup (remember, the one we told you take when we started this?)
  2. Have a "start over" button - this would rollback any migrations that can be rolled back (i.e., not configuration) and delete the generated migrations. The problem - we cannot guarantee returning to the same state from which we started, because configuration.
  3. Other options?

What the form should do:

  1. Detect that migrations already exist.
  2. If we have "start over" capability, warn that previously-migrated content will be removed and the migrations started from scratch.
  3. If we don't, tell them to restore their backup.
  4. Other options?

Comments

mikeryan created an issue. See original summary.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

So in my ideal happy sunshine universe I think how I'd love this to work is there'd be like a status page that shows me Red/Green what did and did not get successfully migrated in. So instead of starting from scratch, what it would do is attempt to import a) data that was new since last time or b) data that hasn't been migrated yet. And I would keep clicking the damn button and trying over and over again until the entire board was green. That is how migrations work in the "real world" in my experience... you never get the whole thing in one go (esp. given contrib modules will be involved), and you need to go over it several times in a row in order to make it actually work.

However, we also want to aim for something actually achievable ;)

1. Does not seem like an option to me. I mean we can say that, but it's basically like Nelson "HAW-HAW." No one reads help text.

2. Could also work. I wonder if we could save some kind of a "snapshot" of the database/files as it was before the migration was attempted.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Title: What to do when upgrade has already been done? » [meta] What to do when upgrade has already been done?

There are actually two scenarios for returning to the upgrade page after the upgrade process has been run:

  1. The original one above, based on webchick's first attempt at a D7 upgrade (mucho errors) - everything went wrong, let's start over from scratch.
  2. The second one, based on more successful attempts since - there's new content added to the source site since the initial upgrade, and/or there are more migration paths available now (contrib modules installed).

So, in the first case, we want to rollback what we can, delete the migration configurations, and start fresh (more-or-less, since we can't back out simple configuration changes, although configuration entities can be rolled back). This also would be really helpful for those of us developing/testing these migrations, enabling us to turn around and rerun that much more quickly.

In the second case, we want to proceed, adding any newly-available migrations and rerunning all the migrations. Existing migration configuration would not be overwritten.

I'll add child issues...

benjy’s picture

benjy commented

From the first day I started on Migrate chx always told me that there would be no "second attempt" when it came to the upgrade path, if your migration/upgrade fails you'd need to reinstall Drupal 8. And that would certainly make things simpler for getting the UI in if we went with that approach, none of this "delayed" creating of migrations etc during the form wizard.

The second one, based on more successful attempts since - there's new content added to the source site since the initial upgrade, and/or there are more migration paths available now (contrib modules installed).

Incremental migrations, re-running specific migrations IMO shouldn't be something that is baked into the core upgrade path/ui, you couldn't go adding extra nodes to your D6 site after running the D6->D7 upgrade.php scripts.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented

I'm not totally opposed to removing the rerun capability, actually - it's worth considering backing off for the sake of getting something into core. Not sure how that relates to the "delayed creation" - we still want the review step, so we still do need to "precreate" the migrations to know what migrations will be run, but we don't want to really create them until confirming so they aren't hanging around if someone simply abandons the form at the review step.

chx’s picture

chx commented
Status: Active » Closed (won't fix)

Thanks for everyone participating, there's nothing new to see here, as you were.