Open btrump opened 8 years ago
@hunner @DavidS Here is another case where a create_only
method would be useful, or some means to ignore a property once the thing already exists.
This might also just be a bug in the in_sync? method on the property, but if we can't modify it, then whats the point of checking other than to report a warning.
@btrump I too don't think this should be an error. Would a warning suffice for you in the case where the desired state does not match the actual state?
@zleslie @zleswomp a warning would be great. I just don't want a compilation failure, because I'm only setting the state of routes at creation, but hitting the same resource declaration every run.
Yeah, I agree with that assessment @btrump. I've been chatting with Hunner and DavidS about this issue and filed a ticket to track this effort: https://tickets.puppetlabs.com/browse/MODULES-3703
Thank you! It would mean huge progress for our team.
btrump: what is the settings of your route table currently after running Puppet? Did it perhaps switch to the CIDR of the AWS instance?
For example, my subnet for the VPC is 10.15.0.0/16. But I push the route table using 10.0.0.0/16 to 'local'. AWS changes this to 10.15.0.0/16, hence Puppet decides it needs to change it again, and thats not allowed. When I correct it to 10.15.0.0/16, then i can keep running the resource without issues.
I understand the desire to come up with a pattern for handling create-once resources but I'm left wondering how hard it would be to have the Provider simply compare desired state with actual state and error out if they don't match as opposed to what appears to be happening now: "error out if resource has parameter/property (sorry, forget the diff right now) which cannot be mutated."
If it cannot be mutated but it also doesn't need to be there's no reason to generate an error. The Provider is being too generous with its errors, IMO.
The PR to replace the error with a warning has been merged here. https://github.com/puppetlabs/puppetlabs-aws/pull/334
This will only throw a warning now, and only in the case where the desired state doesn't match actual state. If no changes are made to the Puppet resource, and there is still a warning that is being thrown, than the provider is not correctly describing the actual state, and thats a bug in the provider.
I'm using the following simple manifest to create a VPC, internet gateway, and routetable:
A one-time run works just fine:
However, subsequent runs produce an error stating that the routes property is read-only once ec2_vpc_routetable is created:
I understand that the property is currently read-only, but should it not check that the values passed are identical to the current route property, thereby allowing the code to run multiple times without error?