mutually_exclusive and exactly_one aren't clever enough to deal with AWS::NoValue

So as part of #765 I was asked to add some validations to AWS::EC2::Route, which makes sense, however it turns out this validation is too naïve to deal with a property being set, and it's value is either Ref('AWS::NoValue') or an even more complex scenario inside a conditional where one of the possible values might be Ref('AWS::NoValue'). Such things appear to be perfectly legitimate in CloudFormation because if the property has no value, then CloudFormation will simply ignore it after its conditionals have been satisfied.

For a real world example of why one might need this, consider a stack that configures a VPC, and in setting up the Routes also needs to set up NAT, but the value of some property may determine if the stack creates a NAT Gateway, or NAT instances. Inside the Route object you may need something like:

    Route(
        'Route66',
        DestinationCidrBlock='0.0.0.0/0',
        RouteTableId=Ref('RouteTable66'),
        InstanceId=If(
            'UseNat',
            Ref('AWS::NoValue'),
            Ref('UseNat')
        ),
        NatGatewayId=If(
            'UseNat',
            Ref('UseNat'),
            Ref('AWS::NoValue')
        )
    )

I see a few potential options to solve this:

• Rip out the validation from AWS::EC2::Route. This is the simplest but makes foot-gunning easier, not harder.
• Extend the validation in mutually_exclusive to not count properties that have either Ref('AWS::NoValue') or any type of conditional that has at least one outcome value as Ref('AWS::NoValue'). This would add complexity, and it would still remain somewhat non-deterministic if the correct value would be applied.
• Some other option my non-caffienated brain has yet to conjur up.

So, I've made a first round attempt in trying to solve this, however I'm left with the following conclusions:

• Fn::If and friends effectively make CloudFormation NP complete in terms of traversing every entity and understanding the validity.
• It's looking really tempting to move away from trying to solve this issue with more validation and instead add functionality so people can opt-out of these validations where they, like me have decided to do these kinds of non-deterministic approaches to stack design.

Any thoughts, @markpeek?

[markpeek]

@TigerToes thanks for looking into this issue further. There have been some increasingly complicated use cases which has made me think having a property expression parser might be needed in the future. But as you mention it might still have issues giving a right answer. Although I consider some validations as "best effort", it is nice to have the mutually_exclusive ones available since it does help catch some good issues. I did like your "opt-out" idea so I prototyped it here (a256a9f) if you want to give me your feedback.

[benbridts]

Just a suggestion, and it will probably break down on some other uses of troposphere, but wouldn't it be more readable to be able to use:

t.add_resource_no_validation(route), or t.add_resource(route, validate=False)

or maybe have the option to do both?

Thanks @markpeek, that's exactly the kind of thing I was thinking of with regards to controlling validation. If we are taken down the path of an expression parser, it would probably need some sort of DAG (or even an abstract semantic graph) in order to resolve every intra-dependency.

@ikben at least in the tooling that I build, tens/hundreds of resources are created and are pushed straight into .add_resource(), making a separate call (or having additional arguments) for those that require validation disabled will at least complicate my use cases. Having a near-global attribute in my opinion makes more sense as at the time I'm defining the resource (and not putting into the template) I can explicitly disable validation.

[markpeek]

There are two different validation schemes in troposphere. The first is when a property is added which does simple type checking operations (which is comparing the types or sometimes runs a per-property validator like positive_integer() or network_port()). This should always work with the caveat that AWSHelperFn are always accepted. The second validation step happens in to_dict() where the finalization of the object allows for checking inter-property values. @ikben since that validation step is on an object basis I thought it best to control validation at a finer granularity so you only had to override the validation for the problematic object and get validation for all other objects in the resource. While I could add it at a resource boundary, that is not as natural and would require passing it down through the to_dict() call tree. I'm not opposed to it if there is a need but if the current implementation on an object basis works for the current use case for @TigerToes then I'm inclined to just add it to the object itself. Thanks both for your input.

[benbridts]

I agree with most of your points. The reason I mentioned it, is that it avoids mixing troposphere kwargs and cloudformation kwargs.

[markpeek]

BTW, I just updated PR #780:

• Change the param name from "validate" to "validation"
• Add no_validation() method able to be chained

That last one allows for a simple call like this without needing to add the kwarg:
route = Route(...).no_validation()

Thanks @markpeek, what you've done looks good and I guess we can close this issue once #780 is merged? From that, any idea on when a new release of troposphere is to be made available?