website: Add beta callout on all pages (#500)

website/docs/plugin/framework/accessing-values.mdx

@@ -7,6 +7,8 @@ description: |-
 
 # Accessing State, Config, and Plan
 
+-> Note: The Plugin Framework is in beta.
+
 There are various points at which the provider needs access to the data from
 the practitioner's configuration, Terraform's state, or generated plan.
 The same patterns are used for accessing this data, regardless of

website/docs/plugin/framework/acctests.mdx

@@ -7,6 +7,8 @@ description: >-
 
 # Acceptance Tests
 
+-> Note: The Plugin Framework is in beta.
+
 You can implement testing with the [acceptance test framework](/plugin/sdkv2/testing/acceptance-tests) shipped with SDKv2.
 
 Writing and running tests is similar to SDKv2 providers, with the following exceptions:

website/docs/plugin/framework/data-sources/configure.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # Configure Data Sources
 
+-> Note: The Plugin Framework is in beta.
+
 [Data sources](/plugin/framework/data-sources) may require provider-level data or remote system clients to operate correctly. The framework supports the ability to configure this data and/or clients once within the provider, then pass that information to data sources by adding the `Configure` method.
 
 ## Prepare Provider Configure Method

website/docs/plugin/framework/data-sources/index.mdx

@@ -7,6 +7,8 @@ description: >-
 
 # Data Sources
 
+-> Note: The Plugin Framework is in beta.
+
 [Data sources](/language/data-sources) are an abstraction that allow Terraform to reference external data. Unlike [managed resources](/language/resources), Terraform does not manage the lifecycle of the resource or data. Data sources are intended to have no side-effects.
 
 This page describes the basic implementation details required for supporting a data source within the provider. Further documentation is available for deeper data source concepts:

website/docs/plugin/framework/data-sources/timeouts.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # Timeouts
 
+-> Note: The Plugin Framework is in beta.
+
 The reality of cloud infrastructure is that it typically takes time to perform operations such as booting operating systems, discovering services, and replicating state across network edges. As the provider developer you should take known delays in data source APIs into account in the `Read` function of the data source. Terraform supports configurable timeouts to assist in these situations.
 
 The Framework can be used in conjunction with the [terraform-plugin-framework-timeouts](https://github.com/hashicorp/terraform-plugin-framework-timeouts) module in order to allow defining timeouts in configuration and have them be available in the `Read` function.

website/docs/plugin/framework/debugging.mdx

@@ -5,6 +5,8 @@ description: How to implement debugger support in Framework Terraform providers.
 
 # Debugging Framework Providers
 
+-> Note: The Plugin Framework is in beta.
+
 This page contains implementation details for inspecting runtime information of a Terraform provider developed with Framework via a debugger tool by adjusting the [provider server](/plugin/framework/provider-servers) implementation. Review the top level [Debugging](/plugin/debugging) page for information pertaining to the overall Terraform provider debugging process and other inspection options, such as log-based debugging.
 
 ## Code Implementation

website/docs/plugin/framework/diagnostics.mdx

@@ -7,6 +7,8 @@ description: |-
 
 # Returning Errors and Warnings
 
+-> Note: The Plugin Framework is in beta.
+
 Providers use `Diagnostics` to surface errors and warnings to practitioners,
 such as contextual messages returned from Terraform CLI at the end of
 command output:

website/docs/plugin/framework/index.mdx

@@ -6,6 +6,8 @@ description: |-
 
 # Terraform Plugin Framework
 
+-> Note: The Plugin Framework is in beta.
+
 The plugin framework is a new way to develop Terraform Plugins on [protocol version 6](/plugin/how-terraform-works#protocol-version-6) or [protocol version 5](/plugin/how-terraform-works#protocol-version-5). It offers improvements and new features from [Teraform Plugin SDKv2](/plugin/sdkv2).
 
 ~> **Important**: [Which SDK Should I Use?](/plugin/which-sdk) explains the differences between [Teraform Plugin SDKv2](/plugin/sdkv2) and Terraform Plugin Framework to help you decide which option is right for your provider.

website/docs/plugin/framework/migrating/attributes-blocks/attribute-schema.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # Attribute Schema
 
+-> Note: The Plugin Framework is in beta.
+
 Attributes define how users can configure values for your Terraform provider, resources, and data sources. Refer to
 [Schemas - Attributes](/plugin/framework/schemas#attributes) in the Framework documentation for details.
 

website/docs/plugin/framework/migrating/attributes-blocks/blocks-computed.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # Blocks with Computed Fields
 
+-> Note: The Plugin Framework is in beta.
+
 Some providers, resources, and data sources include repeatable nested blocks in their attributes. Some blocks contain
 fields  with `Computed: true`, which means that the provider code can define the value or that it could come from the
 output of terraform apply (e.g., the ID of an EC2 instance).

website/docs/plugin/framework/migrating/attributes-blocks/blocks.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # Blocks
 
+-> Note: The Plugin Framework is in beta.
+
 Some providers, resources, and data sources include repeatable nested blocks in their attributes. These nested blocks
 typically represent separate objects that are related to (or embedded within) the containing object.
 

website/docs/plugin/framework/migrating/attributes-blocks/default-values.mdx

@@ -7,6 +7,8 @@ description: >-
 
 # Default Values
 
+-> Note: The Plugin Framework is in beta.
+
 Default values set a value for an attribute when the Terraform configuration does not provide one. In SDKv2, default
 values are set via fields on an attribute's schema. In the Framework, you set default values via plan modification.
 Refer to

website/docs/plugin/framework/migrating/attributes-blocks/fields.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # Attribute Fields
 
+-> Note: The Plugin Framework is in beta.
+
 A subset of attribute fields, such as required, optional, computed, or sensitive, define attribute behavior as boolean flags. Refer to
 [Schemas - Attributes](/plugin/framework/schemas#required) in the Framework documentation for details.
 

website/docs/plugin/framework/migrating/attributes-blocks/force-new.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # ForceNew
 
+-> Note: The Plugin Framework is in beta.
+
 In Terraform, sometimes a resource must be replaced when the value of an attribute changes. In SDKv2, this is
 accomplished via the `ForceNew` field. In the Framework, you implement the same behavior via a `RequiresReplace` plan
 modifier. Refer to

website/docs/plugin/framework/migrating/attributes-blocks/types.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # Attribute Types
 
+-> Note: The Plugin Framework is in beta.
+
 An attribute either contains a primitive type, such as an integer or a string, or contains other attributes. Attributes
 that contain other attributes are referred to as nested attributes, and are implemented by populating the
 `NestedAttributes` field on the `tfsdk.Attribute` struct. Refer to

website/docs/plugin/framework/migrating/attributes-blocks/validators-custom.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # Custom Validators
 
+-> Note: The Plugin Framework is in beta.
+
 You can write custom validations that give users feedback about required syntax, types, and acceptable values in your
 provider. The Framework has a collection of
 [predefined validators](https://github.com/hashicorp/terraform-plugin-framework-validators). Refer to

website/docs/plugin/framework/migrating/attributes-blocks/validators-predefined.mdx

@@ -7,6 +7,8 @@ description: >-
 
 # Validators - Predefined
 
+-> Note: The Plugin Framework is in beta.
+
 Attribute validators ensure that attributes do or do not contain specific values. You can use predefined validators for
 many use cases, or implement custom validators. Refer to [Schemas - Validators](/plugin/framework/schemas#validators) in
 the Framework documentation for details. Refer to the

website/docs/plugin/framework/migrating/data-sources/index.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # Data Sources
 
+-> Note: The Plugin Framework is in beta.
+
 Data sources let Terraform reference external data. Unlike resources, Terraform does not create, update, or delete
 data sources, and makes no attempt to modify the underlying API. Data Sources are a read-only resource type, so they
 only implement a subset of the operations that resources do. Refer to [Data Sources](/plugin/framework/data-sources)

website/docs/plugin/framework/migrating/data-sources/timeouts.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # Timeouts
 
+-> Note: The Plugin Framework is in beta.
+
 The Framework can be used in conjunction with the [terraform-plugin-framework-timeouts](https://github.com/hashicorp/terraform-plugin-framework-timeouts) module in order to allow defining timeouts in configuration and have them be available in CRUD functions.
 
 ## Specifying Timeouts in Configuration

website/docs/plugin/framework/migrating/index.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # Overview
 
+-> Note: The Plugin Framework is in beta.
+
 This guide helps you migrate a Terraform provider from SDKv2 to the plugin Framework. We recommend migrating because the Framework has abstractions that make it easier to use, and it represents the future of Terraform plugin development. Refer to [Which SDK should I Use?](/plugin/which-sdk) for more details.
 
 This guide provides information and examples for most common use cases, but it does not discuss every nuance of migration. You can ask additional migration questions in the [HashiCorp Discuss forum](https://discuss.hashicorp.com/c/terraform-providers/tf-plugin-sdk/43). To request additions or updates to this guide, submit issues or pull requests to the [`terraform-plugin-framework` repository](https://github.com/hashicorp/terraform-plugin-framework).

website/docs/plugin/framework/migrating/providers/index.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # Provider
 
+-> Note: The Plugin Framework is in beta.
+
 Providers are Terraform plugins that define resources and data sources for practitioners to use. You serve your
 providers with a provider server so they can interact with Terraform.
 

website/docs/plugin/framework/migrating/resources/crud.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # CRUD functions
 
+-> Note: The Plugin Framework is in beta.
+
 In Terraform, a resource represents a single instance of a given resource type. They modify a specific resource in the
 API and in Terraform's state through a set of Create, Read, Update, and Delete (CRUD) functions. A resource's CRUD
 functions implement the logic required to manage your resources with Terraform. Refer to

website/docs/plugin/framework/migrating/resources/import.mdx

@@ -7,6 +7,8 @@ description: >-
 
 # Import
 
+-> Note: The Plugin Framework is in beta.
+
 Practitioners can use the [`terraform import` command](https://www.terraform.io/cli/commands/import) to let Terraform
 begin managing existing infrastructure by importing an existing resource into their Terraform project's state. A
 resource's importer function implements the logic to add a resource to Terraform's state. Refer to

website/docs/plugin/framework/migrating/resources/index.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # Resources
 
+-> Note: The Plugin Framework is in beta.
+
 Resources are an abstraction that allow Terraform to manage infrastructure objects by defining create, read, update,
 and delete functionality that maps onto API operations. Resource schemas define what fields a resource has, give
 Terraform metadata about those fields, and define how the resource behaves. Refer to

website/docs/plugin/framework/migrating/resources/plan-modification.mdx

@@ -5,6 +5,9 @@ description: >-
 ---
 
 # Plan Modification
+
+-> Note: The Plugin Framework is in beta.
+
 Your provider can modify the Terraform plan to match the expected end state. This can include replacing unknown values
 with expected known values or marking a resource that must be replaced. Refer to
 [Plan Modification](/plugin/framework/resources/plan-modification) in the Framework documentation for details.

website/docs/plugin/framework/migrating/resources/state-upgrade.mdx

@@ -7,6 +7,8 @@ description: >-
 
 # State Upgraders
 
+-> Note: The Plugin Framework is in beta.
+
 When you update a resource's implementation in your provider, some changes may not be compatible with old versions. You
 can create state upgraders to automatically migrate resources provisioned with old schema configurations. Refer to
 [State Upgrade](/plugin/framework/resources/state-upgrade) in the Framework documentation for details.

website/docs/plugin/framework/migrating/resources/timeouts.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # Timeouts
 
+-> Note: The Plugin Framework is in beta.
+
 The Framework can be used in conjunction with the [terraform-plugin-framework-timeouts](https://github.com/hashicorp/terraform-plugin-framework-timeouts) module in order to allow defining timeouts in configuration and have them be available in CRUD functions.
 
 ## Specifying Timeouts in Configuration

website/docs/plugin/framework/migrating/schema/index.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # Schema
 
+-> Note: The Plugin Framework is in beta.
+
 Providers, resources, and data sources all use schema to define their attributes and behavior. Schemas specify the
 constraints of Terraform configuration blocks and how the provider, resource, or data source behaves. Refer to
 [Schemas](/plugin/framework/schemas) in the Framework documentation for details.

website/docs/plugin/framework/migrating/testing.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # Testing
 
+-> Note: The Plugin Framework is in beta.
+
 During migration, you should [write tests](#testing-migration) to verify that the behaviour of your provider has not
 been altered by the migration itself. You will also need to [update](#provider-factories) your tests too.
 

website/docs/plugin/framework/path-expressions.mdx

@@ -8,6 +8,8 @@ description: >-
 
 # Path Expressions
 
+-> Note: The Plugin Framework is in beta.
+
 Path expressions are logic built on top of [paths](/plugin/framework/paths), which may represent one or more actual paths within a schema or schema-based data. Expressions enable providers to work outside the restrictions of absolute paths and steps.
 
 ## Usage

website/docs/plugin/framework/paths.mdx

@@ -7,6 +7,8 @@ description: >-
 
 # Paths
 
+-> Note: The Plugin Framework is in beta.
+
 An exact location within a [schema](/plugin/framework/schemas) or schema-based data such as [`tfsdk.Config`](https://pkg.go.dev/github.com/hashicorp/terraform-plugin-framework/tfsdk#Config), [`tfsdk.Plan`](https://pkg.go.dev/github.com/hashicorp/terraform-plugin-framework/tfsdk#Plan), or [`tfsdk.State`](https://pkg.go.dev/github.com/hashicorp/terraform-plugin-framework/tfsdk#State), is referred to as a path.
 
 ## Usage

website/docs/plugin/framework/provider-servers.mdx

@@ -7,6 +7,8 @@ description: >-
 
 # Provider Servers
 
+-> Note: The Plugin Framework is in beta.
+
 Before a [provider](/plugin/framework/providers) can be used with Terraform, it must implement a [gRPC server](https://grpc.io) that supports Terraform-specific connection and handshake handling on startup. The server must then implement the [Terraform Plugin Protocol](/plugin/how-terraform-works#terraform-plugin-protocol).
 
 The framework handles the majority of the server implementation details, however it is useful from a provider developer perspective to understand the provider server details at least at a high level.

website/docs/plugin/framework/providers.mdx

@@ -8,6 +8,8 @@ description: >-
 
 # Providers
 
+-> Note: The Plugin Framework is in beta.
+
 Providers are Terraform plugins that define [resources](/plugin/framework/resources) and [data sources](/plugin/framework/data-sources) for practitioners to use. Providers are wrapped by a [provider server](/plugin/framework/provider-servers) for interacting with Terraform.
 
 This page describes the basic implementation details required for defining a provider. Further documentation is available for deeper provider concepts:

website/docs/plugin/framework/resources/configure.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # Configure Resources
 
+-> Note: The Plugin Framework is in beta.
+
 [Resources](/plugin/framework/resources) may require provider-level data or remote system clients to operate correctly. The framework supports the ability to configure this data and/or clients once within the provider, then pass that information to resources by adding the `Configure` method.
 
 ## Prepare Provider Configure Method

website/docs/plugin/framework/resources/import.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # Resource Import
 
+-> Note: The Plugin Framework is in beta.
+
 Practitioners can use the  [`terraform import` command](/cli/commands/import) to let Terraform begin managing existing infrastructure resources. Resources can implement the `ImportState` method, which must either specify enough Terraform state for the `Read` method to refresh [`resource.Resource`](https://pkg.go.dev/github.com/hashicorp/terraform-plugin-framework/resource#Resource) or return an error.
 
 ## Define Resource ImportState Method

website/docs/plugin/framework/resources/index.mdx

@@ -7,6 +7,8 @@ description: >-
 
 # Resources
 
+-> Note: The Plugin Framework is in beta.
+
 [Resources](/language/resources) are an abstraction that allow Terraform to manage infrastructure objects, such as a compute instance, an access policy, or disk. Terraform assumes that every resource:
 
 - operates as a pure key/value store, with values getting returned exactly as they were written.

website/docs/plugin/framework/resources/plan-modification.mdx

@@ -7,6 +7,8 @@ description: >-
 
 # Plan Modification
 
+-> Note: The Plugin Framework is in beta.
+
 After [validation](/plugin/framework/validation) and before applying configuration changes, Terraform generates a plan that describes the expected values and behaviors of those changes. Providers can then tailor the plan to match the expected end state. For example, they may replace unknown values with expected known values or mark a resource that must be replaced. Users can perform this plan modification for an attribute or an entire resource.
 
 ## Plan Modification Process

website/docs/plugin/framework/resources/private-state.mdx

@@ -7,6 +7,8 @@ description: >-
 
 # Private State Management
 
+-> Note: The Plugin Framework is in beta.
+
 Resource private state is provider maintained data that is stored in Terraform state alongside the schema-defined data. Private state is never accessed or exposed by Terraform plans, however providers can use this data storage for advanced use cases.
 
 ## Usage

website/docs/plugin/framework/resources/state-upgrade.mdx

@@ -7,6 +7,8 @@ description: >-
 
 # State Upgrade
 
+-> Note: The Plugin Framework is in beta.
+
 A resource schema captures the structure and types of the resource [state](/language/state). Any state data that does not conform to the resource schema will generate errors or may not be persisted properly. Over time, it may be necessary for resources to make breaking changes to their schemas, such as changing an attribute type. Terraform supports versioning of these resource schemas and the current version is saved into the Terraform state. When the provider advertises a newer schema version, Terraform will call back to the provider to attempt to upgrade from the saved schema version to the one advertised. This operation is performed prior to planning, but with a configured provider.
 
 -> Some versions of Terraform CLI will also request state upgrades even when the current schema version matches the state version. The framework will automatically handle this request.

website/docs/plugin/framework/resources/timeouts.mdx

@@ -6,6 +6,8 @@ description: >-
 
 # Timeouts
 
+-> Note: The Plugin Framework is in beta.
+
 The reality of cloud infrastructure is that it typically takes time to perform operations such as booting operating systems, discovering services, and replicating state across network edges. As the provider developer you should take known delays in resource APIs into account in the CRUD functions of the resource. Terraform supports configurable timeouts to assist in these situations.
 
 The Framework can be used in conjunction with the [terraform-plugin-framework-timeouts](https://github.com/hashicorp/terraform-plugin-framework-timeouts) module in order to allow defining timeouts in configuration and have them be available in CRUD functions.

website/docs/plugin/framework/schemas.mdx

@@ -7,6 +7,8 @@ description: >-
 
 # Schemas
 
+-> Note: The Plugin Framework is in beta.
+
 Schemas specify the constraints of Terraform configuration blocks. They define what fields a provider,
 resource, or data source configuration block has, and give Terraform metadata
 about those fields. You can think of the schema as the "type information" or

website/docs/plugin/framework/types.mdx

@@ -7,6 +7,8 @@ description: >-
 
 # Attribute Types
 
+-> Note: The Plugin Framework is in beta.
+
 Attributes are the fields in a resource, data source, or provider. They hold
 the values that end up in state. Every attribute has an attribute type, which
 describes the constraints on the data the attribute can hold. When you access an

website/docs/plugin/framework/validation.mdx

@@ -5,6 +5,8 @@ description: How to validate configuration values using the provider development
 
 # Validation
 
+-> Note: The Plugin Framework is in beta.
+
 The framework can return [diagnostics](/plugin/framework/diagnostics) feedback for values in provider, resource, and data source configurations. This allows you to write validations that give users feedback about required syntax, types, and acceptable values.
 
 -> **Note:** When implementing validation logic, configuration values may be [unknown](/plugin/framework/types#unknown) based on the source of the value. Implementations must account for this case, typically by returning early without returning new diagnostics.

website/docs/plugin/framework/writing-state.mdx

@@ -7,6 +7,8 @@ description: >-
 
 # Writing State
 
+-> Note: The Plugin Framework is in beta.
+
 One of the primary jobs of a Terraform provider is to manage the provider's
 resources and data sources in the [Terraform statefile](/language/state). Writing values to state
 is something that provider developers will do frequently.