10 Commits (paddy_module_attribution_tmp)

Author	SHA1	Message	Date
Paddy Carver	93ab2881b7	Whitespace fixes.	6 years ago
Paddy Carver	d1febfb1f3	Start supporting ProviderMeta on all RPC calls. ... We want ProviderMeta information to be available to the provider during all the RPC calls, so extend the protocol to account for that, and fill out all the needed methods.	6 years ago
Paddy Carver	546b58befc	First implementation of module attribution. ... A pass at implementing module attribution ("provider_meta blocks in the terraform block", whatever, it's for module attribution). The general idea is that we're adding a new ProviderMeta struct to our configs package, which is then added to Files, Modules, and parsed as part of the terraform block. The configs.Config type then makes that available to the terraform.ProviderTransformer type, which is already scoped by module. It picks out the ProviderMeta for the provider we need in its Transform method, and checks to see if the node it's working on implements the terraform.GraphNodeAttachProviderMetaConfigs interface, which is a new interface we're adding. It has only one method: AttachProviderMetaConfigs, which is passed a *configs.ProviderMeta. We implement this on the terraform.NodeAbstractResource type, storing the passed *configs.ProviderMeta in a new property on that struct. That struct is eventually made available to the terraform.NodeApplyableResourceInstance type, and its method evalTreeManagedResources, which creates an EvalApply type. The EvalApply type gets a ProviderMeta type, which is set to the *configs.ProviderMeta obtained from the terraform.NodeAbstractResource available to it. This means that EvalApply now has the raw config values the user entered for the provider_meta block, but we also need a schema; providers can define their own schema for the provider_meta block, and we need that schema to know how to translate what is in the config into a cty.Value, which is what we eventually want here. Fortunately, EvalApply already has access to the provider's schema; we can augment the GetSchema RPC call to pass back the ProviderMeta schema (added to helper/schema.Provider) in addition to resource, data source, and provider schemas. This makes it available, eventually, to EvalApply. Now that EvalApply has both the config values and the schema, we can parse them into a cty.Value. Finally, we augment the ApplyResourceChange RPC call with a ProviderMeta field, which can be populated by EvalApply with the parsed cty.Value, which successfully makes the config values available to the provider. This still needs tests written for it to ensure it works, but no current tests are broken on it and it compiles, which is reassuring.	6 years ago
Martin Atkins	39e609d5fd	vendor: switch to HCL 2.0 in the HCL repository ... Previously we were using the experimental HCL 2 repository, but now we'll shift over to the v2 import path within the main HCL repository as part of actually releasing HCL 2.0 as stable. This is a mechanical search/replace to the new import paths. It also switches to the v2.0.0 release of HCL, which includes some new code that Terraform didn't previously have but should not change any behavior that matters for Terraform's purposes. For the moment the experimental HCL2 repository is still an indirect dependency via terraform-config-inspect, so it remains in our go.sum and vendor directories for the moment. Because terraform-config-inspect uses a much smaller subset of the HCL2 functionality, this does still manage to prune the vendor directory a little. A subsequent release of terraform-config-inspect should allow us to completely remove that old repository in a future commit.	6 years ago
Martin Atkins	e1af10b554	docs: README for the plugin-protocol directory ... This is an initial partial description of the plugin protocol focused mainly on explaining the purpose of the .proto files. In subsequent updates we will also document the negotiation protocol, etc. For this first pass the goal was just to publish some information that was already available in an internal design document so that it's visible to SDK implementers. It is focused on the .proto versioning strategy because that was the main topic of the internal design documentation this was based on.	7 years ago
James Bardin	fa1f9be539	add tfplugin proto docs files ... Add versioned tfplugin proto files to the docs directory, for easier reference. The latest version starts as a symlink to the current file used for generated the tfplugin package in ./internal/tfplugin5. When changing the protocol version, the old file must be copied to ./docs/plugin-protocol/, and a new symlink created for the latest version.	7 years ago
Martin Atkins	1f241f8f83	docs: Some updates to the architecture summary ... This doc was originally written in the middle of Terraform v0.12 development while some refactoring was already in progress. Here we update those parts to refer to where the relevant functionality finally landed, and also update some things that we did not anticipate changing at the time but ended up having to be changed during the v0.12 development anyway.	7 years ago
Martin Atkins	18c88f5a41	docs: Import some existing docs to bootstrap the codebase docs section ... For a while now we've been gathering some codebase-level docs that felt out-of-place on the main Terraform website (since they are about the implementation, not usage) but we had no existing suitable place to put them. In order to make this information more available (and, hopefully, more likely to stay up-to-date as we change things), here we'll establish the "docs" directory as a place to keep documentation aimed at those who are working on code changes to the Terraform Core codebase. User-oriented docs should never appear in this directory. The Terraform website is always the better place for those. The set of docs here is rudimentary to start and we'll see if it makes sense to expand and reorganize it over time based on the experience with having these initial docs available.	7 years ago
Julien Pivotto	a4f4c70c60	mons-months: fix typo in maintainer-etiquette	9 years ago
Radek Simko	df26c5460c	docs: Add Maintainer's etiquette	9 years ago