When `pulumi import`ing an AWS Route Table with A...
# general
When `pulumi import`ing an AWS Route Table with AWS Classic (
), it appears that it also imports routes associated with the route table. The attributes on a route are set to
if there is no value associated. I’m seeing an issue where
"ipv6CidrBlock": ""
then causes
pulumi preview
to complain that
"" is not a valid CIDR block: invalid CIDR address
. Is there a workaround to get this working, without manually removing those ipv6CidrBlock attributes from the state?
Don't know if it will make a difference but perhaps using the import resource option will help https://www.pulumi.com/docs/concepts/options/import/
@big-architect-71258 Thanks for that, we’re using the import resource option in some places already, I was trying to build a list of resources that could be used to do a one-time import so that we didn’t have to add conditional logic permanently to our Pulumi code.
I’m not even sure if the existing code that uses the import resource option is being done correctly, it generally does:
Copy code
  .. try to import existing resource ..
catch all exceptions:
  .. create new resource ..
Which catches programming errors and probably other things that we don’t really want it to be catching.
Ha! A "classical" use case from the wild. I once wrote a Pulumi program for a customer which automatically tried to import existing resources. I never got it successfully run in complete automatic mode, i.e. the program detects if the resource exists then imports it or otherwise create it. I ended up with an "import mode" which could be used to import existing resources. And a "normal" mode, which simply creates resources if they are not in the stack. In the end you should normally need the import stuff to move resources under control of Pulumi only once. After import Pulumi should fully control all resources automatically. Aside that I know that there is an "old" open issue in the
repo which is around the fact that Pulumi should do this "detection" automatically and even more that you can ensure that a resource is only created once even if the code creates it multiple times. Didn't save the ID though and I couldn't find it by a quick search.
Yeah, this is absolutely a one-off to bring existing stuff under Pulumi’s control.
I think I might end up doing something similar, just running an import-only stack.. I haven’t had much luck with the
pulumi import
CLI in general.
Have you tried the bulk import via a JSON file?
Yeah, that’s what I’m doing.
These changes run across multiple AWS accounts, so one issue I ran into was that I can’t use a non-default provider with the
pulumi import
CLI properly. I have to run a provider initialisation only stack, then grab the URNs.. put those into the
in the JSON file.
But once you provide non-default providers, it breaks the
pulumi import
codegen (I don’t actually want the code it generates, just the state)
I’m thinking at this point, probably just running an import only stack might work better.
The issue that I'm always facing is "how to get dependencies right", i.e. which resources has to be present before importing dependents. But I know this year Pulumi got an improved import process which can (theoretically) sort the resources topologically. And yes I never used the created source code of
pulumi import
I once wrote a PowerShell script which analyzed the JSON output of
pulumi pre
to create various JSON import files.
Ah right yeah, I’m probably underestimating the amount of complexity that’ll be involved in creating the import-only stack too.
Seems like a lot of effort when it’s just this one resource that’s not being imported correctly 😞
By re-reading your initial post, I wonder if this might be a bug in the AWS Classic provider or the upstream Terraform provider. Perhaps worth opening an issue in `pulumi/pulumi-aws`https://github.com/pulumi/pulumi-aws/issues
So I had a look at the respective resource in the Terraform provider. And according to the documentation they're doing some stunts here, especially with existing routes. The resource can be run in, let's call it, ignore mode (property
not set) in contrast to
which forcefully clears all existing routes. All this back and forth might cause issues while importing the resource, even when importing using Terraform. https://github.com/hashicorp/terraform-provider-aws/blob/main/internal/service/ec2/vpc_route_table.go https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/route_table
The state seems to look okay that it generates, other than there being
values for unused attributes.. whereas a newly created resource with Pulumi just omits the unused attributes.
So if I
pulumi state edit
and remove the
ipv6Cidr: ""
line, it stops producing the
"": Invalid CIDR
Created an issue, thanks for the discussion and ideas on this!
Created an issue, thanks for the discussion and ideas on this!
@cuddly-orange-36960 My pleasure!
@big-architect-71258 I updated that github issue thread, as I think the problem is only triggered by the use of
on the RouteTable resource for some reason.. which I believe is unnecessary from what I read in the docs.
I’m not sure why that’s there, has been there since before I started working on this project.. so I’ll remove that and let it soak to see if it introduces any issues.
It does sound like there is a legitimate problem there with import though, as you pointed out that validation rules don’t seem to match the state that import is producing.