[Feature Request] taskcat_stack_STACKNAME_OUTPUT magic parameter.

[webframp]

👋 Thanks for this tool! So far it's been very useful in testing a project to prep for the marketplace.

One thing I'm unable to find out so far is how to test a template that uses the AWS-Specific Parameter types such as:

  YourVpc:
    Description: The VPC ID of a pre-existing VPC to use
    Type: AWS::EC2::VPC::Id

This just kills the run with:

botocore.exceptions.ClientError: An error occurred (ValidationError) when calling the CreateStack operation: Parameters: [YourVpc] must have values

Not sure if this is something easy to add.

I have a situation where I need to launch an instance and security group resource and want to ensure my template works with a default VPC (in EC2-VPC) or if a pre-existing VPC ID is provided. I'd rather not use string types and then have to break apart tests to provide an override parameter for every region's unique VPC id but I don't currently see a way taskcat can support anything else.

Any ideas?

[andrew-glenn]

@webframp, for what it's worth, we got around this in our QuickStart templates by having "master" and "workload" constructs. For any resources that need to be created (VPC, etc), that's done in the "master" and the values are passed on to the "workload".

However... that's just a structured way of saying we provide an explicit VPC ID.

I looked at the spec for AWS::EC2::VPC::Id, and I didn't see any properties. It's just expecting a VPC ID; :-(

Would a 'magic parameter', such as $[taskcat_default_vpc_id], work for you?

This isn't something that is present right now, but something we can target potentially for v0.9.1 or v0.9.2 (the v0.9.0 release is no longer accepting feature requests)

[webframp]

Hey @andrew-glenn, I was toying with the idea of nested stack using some sort of approach like your "master" and "workload" concept but hadn't decided if it's worth it in this case.

I would be perfectly happy with a new 'magic parameter' and could try to make that work too. Thanks for looking into it!

[andrew-glenn]

@webframp - Sure thing. I'll leave this open for tracking purposes.

[webframp]

Was thinking about this a bit while working through issues further, a 'magic parameter' for the default vpc will certainly work in most cases and should be very helpful. I have a case where a few regions have no default VPC and still support legacy EC2 Classic.

One way to possibly make this more generic would be to support the filter/query syntax like the aws cli but represent them in a way as magic params.

In a specific example, I can query for the info I need if a stack exists named taskcat-testing-network using a cli call like:

aws ec2 describe-subnets --filters "Name=tag:aws:cloudformation:stack-name,Values=taskcat-testing-network" --query 'Subnets[0].VpcId' --region us-east-2

However, based on how params are transformed here: https://github.com/aws-quickstart/taskcat/blob/master/taskcat/template_params.py#L47

I imagine it would be way to much to try to safely map a filter/query into magic parameter usage, since that could lead to a very fragile regex.

What about a new magic parameter that would allow reading arbitrary stack outputs from a named stack?

Usage could maybe look something like: $[taskcat_stack_stackname_outputname]

It might allow pre-filling all kinds of generic param values that way if it's basically just "make sure a consistent stack output is available in the region"

[andrew-glenn]

You just validated a use-case we've been brainstorming for awhile. :)

In your case, the parameter could be something like this.. $[taskcat_stackout_taskcat-testing-network_vpcid]

I like it, and it'd be pretty easy to wire in.. throwing an exception if the stack/output name didn't exist in a given region. Between the two, I think the latter has a broader use-case, and I think I'll focus on that over a magic parameter that injects a default VPC.

[webframp]

That sounds great, I’ll keep an eye on changes here and will be happy to test prerelease stuff if needed

[webframp]

Hey @andrew-glenn any progress or PoC work on this enhancement that I could look at somewhere?

[webframp]

@andrew-glenn Happy to test code in a branch somewhere when the time comes, just let me know

[kaaelhaa]

:+1: to this request.

Would be fantastic to be able to refer to the output of a previous stack so exports and importvalue functions can be tested.

[danielc-salt]

👍 to this request.