Support multiple backends & minor fixes

[armenr]

Related Issue

Closes #249

Related Conversation(s)

armenr#1

Description of changes

• Generate env-specific props.json as ${env}-props.json
• Generate unique name for each public key (avoid name collision/resource already exists error)
• Enable multi-env support --> Successfully check out of/create multiple backend envs, each with its own set of amplify-video resources.
• Capitalize generated GraphQL Models (VodAsset, VideoObject) for compliance with Admin-UI constraints (data modeling, etc.)

Breaking changes

• Existing backend environments with already-deployed video resources require a user to run amplify update video
• Existing backends which already leverage signed URLS require amplify update video + rotate keys CLI flow

Pending PR code that's in this branch

• added resource level tagging added resource level tagging #205
• Added env to tokenGen Added env to tokenGen #219
• Fix CloudFront Token Gen lambda Fix CloudFront Token Gen lambda #247

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

[armenr]

@wizage - currently working through a minor issue we've hit during testing (uncertain about the difference in behavior between @arturocanalda 's results and mine...my best guess is we're using different versions of the amplify libs).

Actively working to resolve...

Additionally, I wasn't sure whether to add my code to build.js or video-staging.js...or both. Please feel free to call out anything I've missed, or any duplicative logic I should remove. Thank you! :)

[arturocanalda]

@armenr

As mentioned somewhere in another comment, I was using nodeJS 12.x, which I just upgraded and re-tested.

Current versions:

OS: macOS v10.14.6
Node: v14.16.1
Amplify: v4.50.2

Steps of my test:

• Initial Amplify environment: dev (I have: dev stg prd)
• run: rm stg-props.json to force a re-creation when checking out stg.
• run: amplify env checkout stg
• output: A new stg-props.json is created:

{
    "shared": {
        "resourceName": "vod"
    },
    "template": {
        "name": "Amplify_Video_System_Accelerated_Ott_Hls_Ts_Avc_Aac.json"
    },
    "contentDeliveryNetwork": {
        "signedKey": true,
        "publicKey": "-----BEGIN PUBLIC KEY-----\\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuF9uG+JnbtDe9sGT+m1+\\nNCiIMtS0w6O7ajkJCX3jTfYv4fHTlOFN/VW+aPSbstgucU7I4BdIB4YPBumTDYxK\\nJXawTUm2ZVQUDOFXUMI0S5etoQKFZNcMFkXLjw0r8jjc4Hav6BZ+CFc5pq2djgJM\\nKQwbM6u3bJZNo5RBpNGNVjkd7JUKxuW77w1woBjX+yRdNRucFhAxnkxycjTpi31S\\nkM3gjazJXPY7rk5eVfDw6s8MqJgv3M03NTZtyuzlY81D5G3+rJ1K33ZroGhXt05K\\n1F3Qh6X6uayQYLlQzeVRXibbZTSFVEX5Bx0PAO2ZVe+yEItX3eobx5Gs/UW1/CW+\\nUwIDAQAB\\n-----END PUBLIC KEY-----\\n",
        "rPublicName": "rCloudFrontPublicKeyvv37ttp5",
        "publicKeyName": "vod-stg-publickey-vv37ttp5",
        "secretPem": "vod-stg-pem-vv37ttp5",
        "secretPemArn": "arn:aws:secretsmanager:eu-west-1:*******:secret:vod-stg-pem-vv37ttp5-zwGPAB",
        "functionName": "vod-stg-tokenGen",
        "functionNameSchema": "vod-${env}-tokenGen",
        "enableDistribution": true
    },
    "parameters": {
        "authRoleName": {
            "Ref": "AuthRoleName"
        }
    }
}

• run: amplify push
• output:

UPDATE_FAILED               rCloudFrontPublicKeyvv37ttp5                                                            AWS::CloudFront::PublicKey Fri May 07 2021 10:18:59 GMT+0200 (Central European Summer Time) Resource handler returned message: "Invalid request provided: AWS::CloudFront::PublicKey" (RequestToken: dcd0e952-a380-eb89-c257-d83aa49fa1a3, HandlerErrorCode: InvalidRequest)

For some reason Cloudformation doesn't accept that publicKey. But it does accept this one (my dev key that was created with amplify-video 3.1.0:

"-----BEGIN PUBLIC KEY-----\\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuF9uG+JnbtDe9sGT+m1+\\nNCiIMtS0w6O7ajkJCX3jTfYv4fHTlOFN/VW+aPSbdevucU7I4BdIB4YPBumTDYxK\\nJXawTUm2ZVQUDOFXUMI0S5etoQKFZNcMFkXLjw0r8jjc4Hav6BZ+CFc5pq2djgJM\\nKQwbM6u3bJZNo5RBpNGNVjkd7JUKxuW77w1woBjX+yRdNRucFhAxnkxycjTpi31S\\nkM3gjazJXPY7rk5eVfDw6s8MqJgv3M03NTZtyuzlY81D5G3+rJ1K33ZroGhXt05K\\n1F3Qh6X6uayQYLlQzeVRXibbZTSFVEX5Bx0PAO2ZVe+yEItX3eobx5Gs/UW1/CW+\\nUwIDAQAB\\n-----END PUBLIC KEY-----\\n"

[armenr]

@arturocanalda

I think I know what the issue might be.

1. It looks like you have an existing amplify-video category resource in your project which was created by the original plugin (not my version).
2. It looks like you checked into stg from the existing dev backend env, at which time, the new version (my version) of the plugin went ahead and rendered a new set of props and resources for you.
3. To solve your problem, I THINK the way to get through this is to check back into dev and run amplify video update --> and then choose to rotate your existing keys/create new keys.
4. THEN, remove your stg props file, and check back into the stg backend env and see if all of the props render correctly (specifically, rPublicName).

If this works, it would confirm my suspicions and I might be able to figure out a fix for this (on the plugin side).

I'm guessing this might be the case because the code I added looks like this:

      const searchAndReplaceProps = () => {
        const newPropsObj = {};

        for (const [key, value] of Object.entries(existingPropsToMutate.contentDeliveryNetwork)) {
          // look for any string values that contain existing env's name
          if (typeof value === 'string' && value.includes(`${envNameToReplace}`)) {
            // replace with new env name
            const newValue = value.replace(new RegExp(envNameToReplace, 'g'), `${newEnvName}`);
            newPropsObj[key] = newValue;
          } else {
            // copy existing values that do not match replacement conditions aka "generic props"
            newPropsObj[key] = value;
          }
        }
        return newPropsObj;
      };

SO, the reason you're not seeing a rCloudFrontPublicKeystgvv37ttp5 (note the stg string in the name) is because the existing props file that the plugin is parsing and mutating values from (dev) contains the name rCloudFrontPublicKeyvv37ttp5 and NOT rCloudFrontPublicKeydevvv37ttp5.

Therefore, the easiest path forward would be to quickly check back into dev, go through the amplify update video CLI flow, let it re-gen your props and resources (by selecting to rotate your keys/create new keys). THEN, checking into stg should correctly generate the expected resource names.

I need to think more deeply about what forward-facing migration for existing users/existing resources looks like...so this is a good bug to uncover!

Please try what I've described above and let me know what the results are. Thanks again!

[arturocanalda]

It makes sense. I will do as you suggest on Monday first thing (this weekend is far too busy :)

[arturocanalda]

@armenr

I did as you suggested and it worked 👍
What also worked is amplify update video directly from my stg environment.

So, I can say the problem I was facing is fixed. Thank you for working on it so fast :)

[armenr]

@wizage - should these be calling methods on amplify.** or context.amplify.** ?

[armenr]

@arturocanalda - Glad it's worked for you. It's been working really stable/well for me too!

@wizage - Anything I can do to help make sure this PR is compliant with expectations/merged? :)

[nathanagez]

@wizage did you had time to look at this PR ? Let me know if I can lighten your workload :)

[wizage]

LG2M - Will be expanding on this before releasing as some minor changes need to be made but overall needed.