15 Commits (e024960c745f0a464cb081d04765d93f94deaba0)

Author	SHA1	Message	Date
Martin Atkins	135121562e	helper/plugin: Implement Schema.SkipCoreTypeCheck ... The previous commit added this flag but did not implement it. Here we implement it by adjusting the shape of schema we return to Terraform Core to mark the attribute as untyped and then ensure that gets handled correctly on the SDK side.	7 years ago
Martin Atkins	4de0b33097	helper/schema: Honor ConfigMode when building core schema ... This makes some slight adjustments to the shape of the schema we present to Terraform Core without affecting how it is consumed by the SDK and thus the provider. This mechanism is designed specifically to avoid changing how the schema is interpreted by the SDK itself or by the provider, so that prior behavior can be preserved in Terraform v0.11 mode. This also includes a new rule that Computed-only (i.e. not also Optional) schemas _always_ map to attributes, because that is a better mapping of the intent: they are object values to be used in expressions. Nested blocks conceptually represent nested objects that are in some sense independent of what they are embedded in, and so they cannot themselves be computed.	7 years ago
Martin Atkins	ae0be75ae0	helper/schema: TypeMap of Resource is actually of TypeString ... Historically helper/schema did not support non-primitive map attributes because they cannot be represented unambiguously in flatmap. When we initially implemented CoreConfigSchema here we mapped that situation to a nested block of mode NestingMap, even though that'd never worked until now, assuming that it'd be harmless because providers wouldn't be using it. It turns out that some providers are, in fact, incorrectly populating a TypeMap schema with Elem: &schema.Resource, apparently under the false assumption that it would constrain the keys allowed in the map. In practice, helper/schema has just been ignoring this and treating such attributes as map of string. (#20076) In order to preserve the behavior of these existing incorrectly-specified attribute definitions, here we mimic the helper/schema behavior by presenting as an attribute of type map(string). These attributes have also been shown in some documentation as nested blocks (with no equals sign), so that'll need to be fixed in user configurations as they upgrade to Terraform 0.12. However, the existing upgrade tool rules will take care of that as a natural consequence of the name being indicated as an attribute in the schema, rather than as a block type. This fixes #20076.	7 years ago
Martin Atkins	3d54af9c09	helper/schema: Better mimic some undocumented behaviors in Core schema ... Since the SDK's schema system conflates attributes and nested blocks, it's possible to state some nonsensical schema situations such as: - A nested block is both optional but has MinItems > 0 - A nested block is entirely computed but has MinItems or MaxItems set Both of these weird situations are handled here in the same way that the existing helper/schema validation code would've handled them: by effectively disabling the MinItems/MaxItems checks where they would've been ignored before. the MinItems/MaxItems	8 years ago
Martin Atkins	37da625ee9	helper/schema: Tell Core attribute is optional if set conditionally ... The SDK has a mechanism that effectively makes it possible to declare an attribute as being _conditionally_ required, which is not a concept that Terraform Core is aware of. Since this mechanism is in practice only used for a small UX improvement in prompting for these values interactively when the environment variable is not set, we avoid here introducing all of this complexity into the plugin protocol by just having the provider selectively modify its schema if it detects that such an attribute might be set dynamically. This then prevents Terraform Core from validating the presence of the argument or prompting for a new value for it, allowing the null value to pass through into the provider so that the default value can be generated again dynamically. This is a kinda-kludgey solution which we're accepting here because the alternative would be a much-more-complex two-pass decode operation within Core itself, and that doesn't seem worth it. This fixes #19139.	8 years ago
James Bardin	b88410984b	legacy provider needs to handle StateUpgraders ... In order to not require state migrations to be supported in both MigrateState and StateUpgraders, the legacy provider codepath needs to handle the StateUpgraders transparently during Refresh.	8 years ago
James Bardin	0120d53baf	only add "id" to top-level resources ... Make sure we only add "id" to the top-level resource, since Resource is also used for nested blocks.	8 years ago
James Bardin	15ccf2dda5	use a custom comparer for cty.Type ... Make sure we also compare cty.Types in `cmp.Equal`, even though they contain unexported fields.	8 years ago
James Bardin	befa81c74f	add implicit "id" to resource attribute schemas ... When converting a legacy schemaMap to a configschema, we need to add "id" as a required attribute to top-level resources if it's not declared. The "id" field will be required to interoperate with the legacy helper schema, since the presence of an id was used to indicate the existence of a resource.	8 years ago
Martin Atkins	479c6b2466	move "configschema" from "config" to "configs" ... The "config" package is no longer used and will be removed as part of the 0.12 release cleanup. Since configschema is part of the "new world" of configuration modelling, it makes more sense for it to live as a subdirectory of the newer "configs" package.	8 years ago
Martin Atkins	3c10a3b213	helper/schema: Tolerate incorrectly-specified collection elems ... We historically tolerated this, so we need to tolerate it here too in order to work correctly with existing provider code.	8 years ago
Martin Atkins	d6c6f8852c	configschema: include description in schema ... We will need access to this information in order to render interactive input prompts, and it will also be useful in returning schema information to external tools such as text editors that have autocomplete-like functionality.	8 years ago
Martin Atkins	183833affc	core: terraform.ResourceProvider.GetSchema method ... In order to parse provider, resource and data source configuration from HCL2 config files, we need to know the relevant configuration schema. This new method allows Terraform Core to request these from a provider. This is a breaking change to this interface, so all of its implementers in this package are updated too. This includes concrete implementations of the new method in helper/schema that use the schema conversion code added in an earlier commit to produce a configschema.Block automatically. Plugins compiled against prior versions of helper/schema will not have support for this method, and so calls to them will fail. Callers of this new method will therefore need to sniff for support using the SchemaAvailable field added to both ResourceType and DataSource. This careful handling will need to persist until next time we increment the plugin protocol version, at which point we can make the breaking change of requiring this information to be available.	9 years ago
Martin Atkins	b91bd62747	config/configschema: Sensitive flag for attributes ... We don't currently have any need for this information, but we're propagating it out of helper/schema here pre-emptively so that once we later have a use for it we will not need to rebuild the providers to gain access to it. The long-term expected use-case for this is to have Terraform Core use static analysis techniques to trace the path of sensitive data through interpolations so that intermediate results can be flagged as sensitive too, but we have a lot more work to do before such a thing would actually be possible.	9 years ago
Martin Atkins	69650b0bbc	helper/schema: conversion of Schema to configschema.Block ... As part of moving to the next-generation HCL implementation, Terraform Core is getting its own representation of configuration schema that is tailored for configuration-processing use-cases. The capabilities of this are a subset of the helper/schema model primarily concerned with the configuration structure and value types, leaving detailed validation and defaults for helper/schema to still solve. These new methods allow mechanical creation of a schema in the new Core schema model from a schema expressed in the helper/schema model. This is not yet used as of this commit, but will be used later to implement some new ResourceProvider methods that will allow core to obtain the schema for provider, resource and data source configuration while remaining source-compatible with existing provider implementations.	9 years ago