https://pulumi.com logo
Join Slack
Powered by
When `pulumi import`ing an AWS Route Table with A...
# general
c
When `pulumi import`ing an AWS Route Table with AWS Classic (
aws:ec2/routeTable:RouteTable
), 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?
b
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/
c
@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:
  .. 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.
b
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 
pulumi/pulumi
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.
c
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.
b
Have you tried the bulk import via a JSON file?
c
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 
nameTable
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.
b
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
either.
I once wrote a PowerShell script which analyzed the JSON output of 
pulumi pre
to create various JSON import files.
c
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 😞
b
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
c
👍
b
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 
routes
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
c
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
error.
Created an issue, thanks for the discussion and ideas on this!
b
Created an issue, thanks for the discussion and ideas on this!
@cuddly-orange-36960 My pleasure!
c
@big-architect-71258 I updated that github issue thread, as I think the problem is only triggered by the use of 
ignore_changes=["routes']
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.
3 Views
Open in Slack
PreviousNext
Powered by