Necessary values are propagated to veda-routes repo for CloudFront distribution origin management

[botanical]

Context

• Epic Link: https://github.com/NASA-IMPACT/veda-architecture/issues/469
• ADR: https://github.com/NASA-IMPACT/veda-architecture/pull/464

Propagate the necessary values for CloudFront distribution origin management

• stac-api
• raster-api
• ingest-api
• s3 stac browser for s3 origin for CF

Acceptance Criteria

• veda-backend's API Gateway values are configured to be passed down to veda-routes
• veda-backend's S3 STAC Browser is configured to be passed down to veda-routes

[ciaransweet]

@botanical could you define what you mean by 'propagate'? And what values from those services are being propagated? URLs?

[botanical]

@botanical could you define what you mean by 'propagate'? And what values from those services are being propagated? URLs?

@ciaransweet, definitely! I added some links in the issue description, hopefully that's helpful. In our veda-deploy-pipeline, I would like each service's job run to pass their origin values (potentially to $GITHUB_OUTPUT or some useful equivalent) so that, eventually, when we integrate veda-routes into the deploy pipeline, it can use those values to set the origin values in the CloudFront distribution. So, in the case of veda-backend, it will be passing the values for the stac-api, raster-api, ingest-api (which are all API Gateway values) and the S3 STAC browser. For more context, we have a CDK construct veda-backend which creates the distribution, adding origins using the env vars it has access to in veda-backend.

[ciaransweet]

@botanical Gotcha.

So in terms of the specific values of the origins, do you mean the domains? à la: https://docs.aws.amazon.com/cdk/api/v2/python/aws_cdk.aws_cloudfront_origins/HttpOrigin.html which will return a https://docs.aws.amazon.com/cdk/api/v2/python/aws_cdk.aws_cloudfront/OriginBindConfig.html#aws_cdk.aws_cloudfront.OriginBindConfig which will have a: https://docs.aws.amazon.com/cdk/api/v2/python/aws_cdk.aws_cloudfront/CfnDistribution.html#aws_cdk.aws_cloudfront.CfnDistribution.OriginProperty which contains the final domain?

[botanical]

@botanical Gotcha.

So in terms of the specific values of the origins, do you mean the domains? à la: https://docs.aws.amazon.com/cdk/api/v2/python/aws_cdk.aws_cloudfront_origins/HttpOrigin.html which will return a https://docs.aws.amazon.com/cdk/api/v2/python/aws_cdk.aws_cloudfront/OriginBindConfig.html#aws_cdk.aws_cloudfront.OriginBindConfig which will have a: https://docs.aws.amazon.com/cdk/api/v2/python/aws_cdk.aws_cloudfront/CfnDistribution.html#aws_cdk.aws_cloudfront.CfnDistribution.OriginProperty which contains the final domain?

Yeah, the origin domain names! Sorry if my verbiage was confusing, @ciaransweet.

I think we could use CfnDistribution.OriginProperty, but we also could use addBehavior. It takes in an origin that is an IOrigin object. In our case for our API GW origins, we would be using an HttpOrigin and pass in the domain name and origin Id.

This is an example of how we do it currently in veda-backend.

self.distribution.add_behavior(
                path_pattern="/api/stac*",
                origin=origins.HttpOrigin(
                    f"{stac_api_id}.execute-api.{region}.amazonaws.com",
                    origin_id="stac-api",
                ),
                cache_policy=cf.CachePolicy.CACHING_DISABLED,
                allowed_methods=cf.AllowedMethods.ALLOW_ALL,
                origin_request_policy=cf.OriginRequestPolicy.ALL_VIEWER_EXCEPT_HOST_HEADER,
            )

The API Gateway values should be included in the cloudformation output, so we can write something to retrieve the API GW values. For example, here are the constructs for the APIs that call CfnOutput:

• stac_api
• raster_api
• ingest_api

As for the s3 bucket for the s3 origin, I will get back to you on how that can be retrieved 🤔 For example, using the aws cloudformation describe-stacks for the VEDA UAH dev stack, I see

{
                    "OutputKey": "stacbrowserbucketname088B771F",
                    "OutputValue": "veda-dev-stac-browser",
                    "ExportName": "veda-backend-uah-dev-bucket-name"
}

in the cloudformation output but don't see where we actually output that in veda-backend.

[ciaransweet]

Ah, I think I got confused. So right now those add_behaviors will remain till we're ready with the distribution being created/maintained in veda-routes. So right now anywhere exposing a URL that's being added to the distribution in veda-backend, should actually have that url, and it's ID as an output of the action, though we can probably hard code ID in the veda-routes?

We know what the services are we want to have in the distribution, not sure we have a usecase where it has to be able to add services dynamically yet?

If so, my idea on what we're doing is:

• Where we have a behaviour being added to the current distribution, take the origin value and expose that in the output of the stack
• In the github action, expose each of those outputs as actions outputs
• Setup veda-routes to expect those values to be available, I guess env vars? 🤷

STAC_API_ORIGIN_URL=
RASTER_API_ORIGIN_URL= 
# etc etc

• Create the distribution + behaviours in veda-routes - Where the origin_id can be hard coded, we know what origins we're adding.

I wondered if we wanted to expose what type of origin they were but again, right now it's not dynamic so we can effectively copy + paste the self.distribution.add_behavior( calls and sub in the urls.

[botanical]

Addressed in:

• feat: deterministic outputs of service urls #411
• https://github.com/NASA-IMPACT/veda-deploy/pull/42
• fix: output stac bucket name not host #417
• https://github.com/NASA-IMPACT/veda-deploy/pull/44