5 Commits (a15a4acf2f0e4e8a749d9cb9a46ac09f224d5e90)

Author	SHA1	Message	Date
Martin Atkins	c07b0a7806	configs: Re-unify the ManagedResource and DataResource types ... Initially the intent here was to tease these apart a little more since they don't really share much behavior in common in core, but in practice it'll take a lot of refactoring to tease apart these assumptions in core right now and so we'll keep these things unified at the configuration layer in the interests of minimizing disruption at the core layer. The two types are still kept in separate maps to help reinforce the fact that they are separate concepts with some behaviors in common, rather than the same concept.	8 years ago
Martin Atkins	5dd6b839d0	configs: Export MergeBodies and new SynthBody function ... We have a few special use-cases in Terraform where an object is constructed from a mixture of different sources, such as a configuration file, command line arguments, and environment variables. To represent this within the HCL model, we introduce a new "synthetic" HCL body type that just represents a map of values that are interpreted as attributes. We then export the previously-private MergeBodies function to allow the synthetic body to be used as an override for a "real" body, which then allows us to combine these various sources together while still retaining the proper source location information for each individual attribute. Since a synthetic body doesn't actually exist in configuration, it does not produce source locations that can be turned into source snippets but we can still use placeholder strings to help the user to understand which of the many different sources a particular value came from.	8 years ago
Martin Atkins	5661ab5991	configs: allow full type constraints for variables ... Previously we just ported over the simple "string", "list", and "map" type hint keywords from the old loader, which exist primarily as hints to the CLI for whether to treat -var=... arguments and environment variables as literal strings or as HCL expressions. However, we've been requested before to allow more specific constraints here because it's generally better UX for a type error to be detected within an expression in a calling "module" block rather than at some point deep inside a third-party module. To allow for more specific constraints, here we use the type constraint expression syntax defined as an extension within HCL, which uses the variable and function call syntaxes to represent types rather than values, like this: - string - number - bool - list(string) - list(any) - list(map(string)) - object({id=string,name=string}) In native HCL syntax this looks like: variable "foo" { type = map(string) } In JSON, this looks like: { "variable": { "foo": { "type": "map(string)" } } } The selection of literal processing or HCL parsing of CLI-set values is now explicit in the model and separate from the type, though it's still derived from the type constraint and thus not directly controllable in configuration. Since this syntax is more complex than the keywords that replaced it, for now the simpler keywords are still supported and "list" and "map" are interpreted as list(any) and map(any) respectively, mimicking how they were interpreted by Terraform 0.11 and earlier. For the time being our documentation should continue to recommend these shorthand versions until we gain more experience with the more-specific type constraints; most users should just make use of the additional primitive type constraints this enables: bool and number. As a result of these more-complete type constraints, we can now type-check the default value at config load time, which has the nice side-effect of allowing us to produce a tailored error message if an override file produces an invalid situation; previously the result was rather confusing because the error message referred to the original definition of the variable and not the overridden parts.	8 years ago
Martin Atkins	7c8efe103e	configs: allow overrides files to omit args that primary files can't ... Some of the fields in our config structs are either mandatory in primary files or there is a default value that we apply if absent. Unfortunately override files impose the additional constraint that we be allowed to omit required fields (which have presumably already been set in the primary files) and that we are able to distinguish between a default value and omitting a value entirely. Since most of our fields were already acceptable for override files, here we just add some new fields to deal with the few cases where special handling is required and a helper function to disable the "Required" flag on attributes in a given schema.	8 years ago
Martin Atkins	4e5efa498a	configs: Parser.LoadConfigDir ... This method wraps LoadConfigFile to load all of the .tf and .tf.json files in a given directory and then bundle them together into a Module object. This function also deals with the distinction between primary and override files, first appending together the primary files in lexicographic order by filename, and then merging in override files in the same order. The merging behavior is not fully implemented as of this commit, and so will be expanded in future commits.	8 years ago