Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node Migrations #4442

Open
3 tasks
bwaidelich opened this issue Aug 4, 2023 · 4 comments · May be fixed by #4685
Open
3 tasks

Node Migrations #4442

bwaidelich opened this issue Aug 4, 2023 · 4 comments · May be fixed by #4685
Assignees

Comments

@bwaidelich
Copy link
Member

bwaidelich commented Aug 4, 2023

The current implementation could use some documentation and tweaking:

  • Document the new API and CLI commands on docs.neos.io
  • Adjust the behavior of the nodemigration:migrate command such that it applies changes to the live workspace by default
    • There should be an option to allow creating that explicit "migration workspace" which is the default behavior currently
  • Apply all migrations to a single content stream (by default?) – currently an array of contentStreamIdsForWriting is passed
@bwaidelich bwaidelich added the 9.0 label Aug 4, 2023
@crydotsnake
Copy link
Member

Also the ./flow nodemigration:migrationstatus command is still missing (if i checked the existing code correctly)

@dlubitz
Copy link
Contributor

dlubitz commented Oct 3, 2023

ATM the ExecuteMigration can get passed an array of contentStreamIdsForWriting. Which means per entry in a migration file, I could pass a different contentStreamId as target. Is this really necessary?

I would like to replace that with a targetWorkspace and apply the migrations there (default "live"). If no targetWorkspace is given, we create a new one with unique name.

I would also remove the logic of "submigrations" where each submigration creates a new content stream. IMHO this creates unnecessary complexity, moreover I would consider each migration(-file) as ONE atomic migration.

* For every "submigration" (i.e. every "line" from above), we fork a new content stream,
* to make the migration roll-back-able.
* In the first "submigration", we use the base content stream identifier (of $workspaceName) for *reading*, and
* use the first content stream identifier of this list for writing.
* In the second "submigration", we use the content stream of the *first* submigration for reading, and the next one
* from this list for writing.

@bwaidelich
Copy link
Member Author

IIRC the idea was to be able to recover from failed migrations more easily but I agree that this makes things rather complex.. Maybe we can make the "submigrations" an option, too?

@dlubitz dlubitz removed their assignment Oct 22, 2023
@dlubitz
Copy link
Contributor

dlubitz commented Nov 3, 2023

  • No "Submigrations"
  • Create new workspace per migration(-file) ("targetworkspacename-20231102123456")
  • Rename "workspace" to "sourceWorkspace"
  • Flag to publish targetWorkspace to sourceWorkspace after success ("publishOnSuccess", default: true)
  • Remove content stream ids from outside
  • Behat Tests

@dlubitz dlubitz linked a pull request Nov 12, 2023 that will close this issue
@bwaidelich bwaidelich mentioned this issue Nov 27, 2023
2 tasks
@dlubitz dlubitz linked a pull request May 12, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: In Progress 🚧
Development

Successfully merging a pull request may close this issue.

4 participants