Open fabian4cast opened 4 weeks ago
@fabian4cast Good afternoon. I was able to reproduce the issue by:
BetaStage
).Using the below bare minimal code and running cdk synth
:
from aws_cdk import (
Stack,
aws_apigateway as apigateway
)
from constructs import Construct
class PythonStack(Stack):
def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
super().__init__(scope, construct_id, **kwargs)
restapi = apigateway.RestApi.from_rest_api_id(self, id="MyRestApi", rest_api_id="<<id-from-aws-console>>")
stage = apigateway.Stage.from_stage_attributes(self, "MyStage", rest_api=restapi, stage_name="BetaStage")
restapi.deployment_stage = stage
The reason you are getting the error is that apigateway.Stage.from_stage_attributes()
returns IStage
interface variable, whereas restapi.deployment_stage
expects a concrete type Stage
per below devompiled definition form VS Code:
@jsii.interface(jsii_type="aws-cdk-lib.aws_apigateway.IRestApi")
class IRestApi(_IResource_c80c4260, typing_extensions.Protocol):
@builtins.property
@jsii.member(jsii_name="restApiId")
def rest_api_id(self) -> builtins.str:
'''The ID of this API Gateway RestApi.
:attribute: true
'''
...
@builtins.property
@jsii.member(jsii_name="deploymentStage")
def deployment_stage(self) -> "Stage":
'''API Gateway stage that points to the latest deployment (if defined).'''
...
@deployment_stage.setter
def deployment_stage(self, value: "Stage") -> None:
...
Using the similar code in TypeScript reports same issue where IRestApi.deploymentStage is of type Stage.
I'm unsure about the workaround right now. Would review this with team.
Thanks, Ashish
Hi
The override_logical_id
approach is an interesting hack that makes your CDK code to synthesize into exactly the same logical ID of the existing resource from an existing CFN stack deployed by serverless framework but this could lead to some other issues off the top of my head:
We do not have any public reference on migrating from serverless framework to CDK as there might be some different migration strategies, each has its pros and cons to consider.
I would suggest to reach out to AWS specialists to work together with your team to help you define the migration strategy. Feel free to ping me on cdk.dev if you need any further assistance.
This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.
Hey, thanks for the replies!
@ashishdhingra as of my experience it often is not so much of an issue whether a method returns e.g. Stage
or IStage
. Usually with from_xxx_attributes
doesn't cause any issues (e.g. for iam.User
, which we also use in the app).
@pahud
Stage
here to just be in interface becauseStage
currently is already not part of the Stack managed by Serverless. It might be that Serverless can manage the Stage anyways since it somehow knows about it, but apparently it doesn't appear as a resource of the Stack in the CloudFormation console.For this is, however, a blocker for us, but we are considering to find any other workaround that might help us for now.
Describe the bug
Hello folks,
We previously deployed a Stack with an API Gateway via the Serverless framework, and decided to switch to CDK and hence rewrote the Stack configuration in CDK.
We managed to let CDK recognize most of the existing resources by overriding the logical IDs, e.g.
This way CDK recognizes (or imports) the resources in the already existing Stack and updates them (if required) instead of deleting and re-creating. This works well for the RestApi. However, we also have a Stage that already exists for the RestApi, and doing the same with the existing Stage leads to the error
Stage already exists
. Here it seems that CDK is not able to recognize the existing Stage and just import it, but attempts to create a new one with the same name instead.Hence, we attempted to just reference the existing Stage using
aws_apigateway.Stage.from_stage_attributes
asand this then fails because
According to the docs
aws_apigateway.Stage.from_stage_attributes
should returnIStage
, but apparently it seems to return_StageBaseProxy
instead.Thanks for the help in advance!
Moving from Serverless to CDK has generally been a great experience, at least from the point where we discovered the
override_logical_id
"hack", since that allowed us to import all previously existing resources that were part of the stacks, and didn't requirecdk import
.Expected Behavior
aws_cdk.aws_apigateway.Stage.from_stage_attributes
returnsaws_cdk.aws_apigateway.IStage
Current Behavior
aws_cdk.aws_apigateway.Stage.from_stage_attributes
returnsaws_cdk.aws_apigateway._StageBaseProxy
Reproduction Steps
then
cdk synth
Possible Solution
No response
Additional Information/Context
It is also worth mentioning that the Stage (and its corresponding Deployment) do currently not appear as a Resource of the Stack as of the state Serverless created! It just exists in the AWS API Gateway Console (or area, idk how to describe it). It seems that it was previously implicitly created by setting
Stage
attributes in Serverless, e.g.CDK CLI Version
2.138.0 (build 6b41c8b)
Framework Version
No response
Node.js Version
v21.7.3
OS
Ubuntu 22.04 LTS
Language
Python
Language Version
3.12.0
Other information