search

awslabs / aws-api-gateway-developer-portal

A Serverless Developer Portal for easily publishing and cataloging APIs
Apache License 2.0
927 stars 399 forks source link

Create migration for Cognito user pool changes #419

Closed ghost closed 4 years ago

ghost commented 4 years ago

Issue #, if available:

Description of changes:

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

ghost commented 4 years ago

@MynockSpit

This looks very static. What do we do next time we need to migrate users? i.e. Can we think of a way to have them provide an arbitrary list of user pools to import users from?

If we ever need to upgrade pools in this system, we'll have to do the following:

  1. Clone the pool and all existing groups.
  2. Update all references from the old pool and related groups to the new pool + related groups.
  3. Optional: strip all the lambdas and such (minus the user migration lambda) from the old pool.
  4. Remove references to the oldest pool.

Long-term, I want to do away with this system entirely, and just have the user handle both the groups and the user pool. We can just create a (rather involved) custom resource to handle the case where a user wants us to magically generate everything, wants to use existing pools with existing roles, and anything in between.

(If the answer is, "yes, but not in the short term," please think about/explain how we're going to clean up the template in the future without breaking customers when we do provide the ability to migrate from arbitrary user pools.)

The custom resource can be coded to start migrating from the existing autogenerated pool to a new pool, using S3 to store whatever build data is necessary for bookeeping. (I created most of the infrastructure already for edge lambdas - it just needs a FIFO SQS queue put in front of it to avoid race conditions and a custom resource to ping back when it empties.)

The process would be similar to today, spreading the change across two releases:

  1. Release a version with both. (Non-breaking)
  2. Drop the old and import everything automatically into the new one, resetting the passwords of anyone who hasn't logged in since the update and updating groups accordingly. (Non-breaking because of the old pools' DeletionPolicy.)
    • This would use a standard SQS queue + a Lambda to ensure it all gets processed properly, and a DLQ in case things got left behind.

And to clarify, I'm suggesting not "migrating from pools", but actually using external pools directly without import.

ghost commented 4 years ago

Closing as I'm abandoning this route for now, due to issues with CFN and Cognito. I can open a new pull request later with something better.