terraform

Commit Graph

Author	SHA1	Message	Date
James Bardin	e93d69f18b	more nil/known checks before val.LengthInt	8 years ago
Martin Atkins	9b4b43c077	plans/objchange: Don't panic when a prior value with a set is null ProposedNewObject intentionally replaces a null prior with an unknown prior in order to easily fill in unknown values where they "show through" under values not set explicitly in config, but it was failing to handle that situation when dealing with nested blocks that are backed by sets.	8 years ago
Kristin Laemmert	c661157999	plans/objchange: further harden ProposedNewObject against ~weird~ incoming values Addresses an odd state where the priorV of an object to be changed is known but null. While this situation should not happen, it seemed prudent to ensure that core is resilient to providers sending incorrect values (which might also occur with manually edited state).	8 years ago
Kristin Laemmert	2a8aa6a139	plans/objchange: if priorV is unknown, fall through to the recursive call to `ProposedNewObject`	8 years ago
Martin Atkins	3f8a973846	plans/objchange: when prior is null, computed attributes are unknown	8 years ago
Martin Atkins	549544f201	configschema: Handle nested blocks containing dynamic-typed attributes We need to make the collection itself be a tuple or object rather than list or map in this case, since otherwise all of the elements of the collection are constrained to be of the same type and that isn't the intent of a provider indicating that it accepts any type.	8 years ago
Martin Atkins	0317da9911	plans/objchange: logic for merging prior state with config This produces a "proposed new state", which already has prior computed values propagated into it (since that behavior is standard for all resource types) but could be customized further by the provider to make the "_planned_ new state". In the process of implementing this it became clear that our configschema DecoderSpec behavior is incorrect, since it's producing list values for NestingList and map values for NestingMap. While that seems like it should be right, we should actually be using tuple and object types respectively to allow each block to have a different runtime type in situations where an attribute is given the type cty.DynamicPseudoType. That's not fixed here, and so without a further fix list and map blocks will panic here. The DecoderSpec implementation will be fixed in a subsequent commit.	8 years ago

7 Commits (a5ef403dfd46121baadef1c69c7b9b83fccdcda5)