terraform/internal/tfplugin5/tfplugin5.pb.go

3456 lines
137 KiB
Go
Raw Normal View History

// Code generated by protoc-gen-go. DO NOT EDIT.
// source: tfplugin5.proto
package tfplugin5
import proto "github.com/golang/protobuf/proto"
import fmt "fmt"
import math "math"
import (
context "golang.org/x/net/context"
grpc "google.golang.org/grpc"
)
// Reference imports to suppress errors if they are not otherwise used.
var _ = proto.Marshal
var _ = fmt.Errorf
var _ = math.Inf
// This is a compile-time assertion to ensure that this generated file
// is compatible with the proto package it is being compiled against.
// A compilation error at this line likely means your copy of the
// proto package needs to be updated.
const _ = proto.ProtoPackageIsVersion2 // please upgrade the proto package
type Diagnostic_Severity int32
const (
Diagnostic_INVALID Diagnostic_Severity = 0
Diagnostic_ERROR Diagnostic_Severity = 1
Diagnostic_WARNING Diagnostic_Severity = 2
)
var Diagnostic_Severity_name = map[int32]string{
0: "INVALID",
1: "ERROR",
2: "WARNING",
}
var Diagnostic_Severity_value = map[string]int32{
"INVALID": 0,
"ERROR": 1,
"WARNING": 2,
}
func (x Diagnostic_Severity) String() string {
return proto.EnumName(Diagnostic_Severity_name, int32(x))
}
func (Diagnostic_Severity) EnumDescriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{1, 0}
}
type Schema_NestedBlock_NestingMode int32
const (
Schema_NestedBlock_INVALID Schema_NestedBlock_NestingMode = 0
Schema_NestedBlock_SINGLE Schema_NestedBlock_NestingMode = 1
Schema_NestedBlock_LIST Schema_NestedBlock_NestingMode = 2
Schema_NestedBlock_SET Schema_NestedBlock_NestingMode = 3
Schema_NestedBlock_MAP Schema_NestedBlock_NestingMode = 4
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
Schema_NestedBlock_GROUP Schema_NestedBlock_NestingMode = 5
)
var Schema_NestedBlock_NestingMode_name = map[int32]string{
0: "INVALID",
1: "SINGLE",
2: "LIST",
3: "SET",
4: "MAP",
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
5: "GROUP",
}
var Schema_NestedBlock_NestingMode_value = map[string]int32{
"INVALID": 0,
"SINGLE": 1,
"LIST": 2,
"SET": 3,
"MAP": 4,
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
"GROUP": 5,
}
func (x Schema_NestedBlock_NestingMode) String() string {
return proto.EnumName(Schema_NestedBlock_NestingMode_name, int32(x))
}
func (Schema_NestedBlock_NestingMode) EnumDescriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{5, 2, 0}
}
// DynamicValue is an opaque encoding of terraform data, with the field name
// indicating the encoding scheme used.
type DynamicValue struct {
Msgpack []byte `protobuf:"bytes,1,opt,name=msgpack,proto3" json:"msgpack,omitempty"`
Json []byte `protobuf:"bytes,2,opt,name=json,proto3" json:"json,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *DynamicValue) Reset() { *m = DynamicValue{} }
func (m *DynamicValue) String() string { return proto.CompactTextString(m) }
func (*DynamicValue) ProtoMessage() {}
func (*DynamicValue) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{0}
}
func (m *DynamicValue) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_DynamicValue.Unmarshal(m, b)
}
func (m *DynamicValue) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_DynamicValue.Marshal(b, m, deterministic)
}
func (dst *DynamicValue) XXX_Merge(src proto.Message) {
xxx_messageInfo_DynamicValue.Merge(dst, src)
}
func (m *DynamicValue) XXX_Size() int {
return xxx_messageInfo_DynamicValue.Size(m)
}
func (m *DynamicValue) XXX_DiscardUnknown() {
xxx_messageInfo_DynamicValue.DiscardUnknown(m)
}
var xxx_messageInfo_DynamicValue proto.InternalMessageInfo
func (m *DynamicValue) GetMsgpack() []byte {
if m != nil {
return m.Msgpack
}
return nil
}
func (m *DynamicValue) GetJson() []byte {
if m != nil {
return m.Json
}
return nil
}
type Diagnostic struct {
Severity Diagnostic_Severity `protobuf:"varint,1,opt,name=severity,proto3,enum=tfplugin5.Diagnostic_Severity" json:"severity,omitempty"`
Summary string `protobuf:"bytes,2,opt,name=summary,proto3" json:"summary,omitempty"`
Detail string `protobuf:"bytes,3,opt,name=detail,proto3" json:"detail,omitempty"`
Attribute *AttributePath `protobuf:"bytes,4,opt,name=attribute,proto3" json:"attribute,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *Diagnostic) Reset() { *m = Diagnostic{} }
func (m *Diagnostic) String() string { return proto.CompactTextString(m) }
func (*Diagnostic) ProtoMessage() {}
func (*Diagnostic) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{1}
}
func (m *Diagnostic) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_Diagnostic.Unmarshal(m, b)
}
func (m *Diagnostic) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_Diagnostic.Marshal(b, m, deterministic)
}
func (dst *Diagnostic) XXX_Merge(src proto.Message) {
xxx_messageInfo_Diagnostic.Merge(dst, src)
}
func (m *Diagnostic) XXX_Size() int {
return xxx_messageInfo_Diagnostic.Size(m)
}
func (m *Diagnostic) XXX_DiscardUnknown() {
xxx_messageInfo_Diagnostic.DiscardUnknown(m)
}
var xxx_messageInfo_Diagnostic proto.InternalMessageInfo
func (m *Diagnostic) GetSeverity() Diagnostic_Severity {
if m != nil {
return m.Severity
}
return Diagnostic_INVALID
}
func (m *Diagnostic) GetSummary() string {
if m != nil {
return m.Summary
}
return ""
}
func (m *Diagnostic) GetDetail() string {
if m != nil {
return m.Detail
}
return ""
}
func (m *Diagnostic) GetAttribute() *AttributePath {
if m != nil {
return m.Attribute
}
return nil
}
type AttributePath struct {
Steps []*AttributePath_Step `protobuf:"bytes,1,rep,name=steps,proto3" json:"steps,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *AttributePath) Reset() { *m = AttributePath{} }
func (m *AttributePath) String() string { return proto.CompactTextString(m) }
func (*AttributePath) ProtoMessage() {}
func (*AttributePath) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{2}
}
func (m *AttributePath) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_AttributePath.Unmarshal(m, b)
}
func (m *AttributePath) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_AttributePath.Marshal(b, m, deterministic)
}
func (dst *AttributePath) XXX_Merge(src proto.Message) {
xxx_messageInfo_AttributePath.Merge(dst, src)
}
func (m *AttributePath) XXX_Size() int {
return xxx_messageInfo_AttributePath.Size(m)
}
func (m *AttributePath) XXX_DiscardUnknown() {
xxx_messageInfo_AttributePath.DiscardUnknown(m)
}
var xxx_messageInfo_AttributePath proto.InternalMessageInfo
func (m *AttributePath) GetSteps() []*AttributePath_Step {
if m != nil {
return m.Steps
}
return nil
}
type AttributePath_Step struct {
// Types that are valid to be assigned to Selector:
// *AttributePath_Step_AttributeName
// *AttributePath_Step_ElementKeyString
// *AttributePath_Step_ElementKeyInt
Selector isAttributePath_Step_Selector `protobuf_oneof:"selector"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *AttributePath_Step) Reset() { *m = AttributePath_Step{} }
func (m *AttributePath_Step) String() string { return proto.CompactTextString(m) }
func (*AttributePath_Step) ProtoMessage() {}
func (*AttributePath_Step) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{2, 0}
}
func (m *AttributePath_Step) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_AttributePath_Step.Unmarshal(m, b)
}
func (m *AttributePath_Step) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_AttributePath_Step.Marshal(b, m, deterministic)
}
func (dst *AttributePath_Step) XXX_Merge(src proto.Message) {
xxx_messageInfo_AttributePath_Step.Merge(dst, src)
}
func (m *AttributePath_Step) XXX_Size() int {
return xxx_messageInfo_AttributePath_Step.Size(m)
}
func (m *AttributePath_Step) XXX_DiscardUnknown() {
xxx_messageInfo_AttributePath_Step.DiscardUnknown(m)
}
var xxx_messageInfo_AttributePath_Step proto.InternalMessageInfo
type isAttributePath_Step_Selector interface {
isAttributePath_Step_Selector()
}
type AttributePath_Step_AttributeName struct {
AttributeName string `protobuf:"bytes,1,opt,name=attribute_name,json=attributeName,proto3,oneof"`
}
type AttributePath_Step_ElementKeyString struct {
ElementKeyString string `protobuf:"bytes,2,opt,name=element_key_string,json=elementKeyString,proto3,oneof"`
}
type AttributePath_Step_ElementKeyInt struct {
ElementKeyInt int64 `protobuf:"varint,3,opt,name=element_key_int,json=elementKeyInt,proto3,oneof"`
}
func (*AttributePath_Step_AttributeName) isAttributePath_Step_Selector() {}
func (*AttributePath_Step_ElementKeyString) isAttributePath_Step_Selector() {}
func (*AttributePath_Step_ElementKeyInt) isAttributePath_Step_Selector() {}
func (m *AttributePath_Step) GetSelector() isAttributePath_Step_Selector {
if m != nil {
return m.Selector
}
return nil
}
func (m *AttributePath_Step) GetAttributeName() string {
if x, ok := m.GetSelector().(*AttributePath_Step_AttributeName); ok {
return x.AttributeName
}
return ""
}
func (m *AttributePath_Step) GetElementKeyString() string {
if x, ok := m.GetSelector().(*AttributePath_Step_ElementKeyString); ok {
return x.ElementKeyString
}
return ""
}
func (m *AttributePath_Step) GetElementKeyInt() int64 {
if x, ok := m.GetSelector().(*AttributePath_Step_ElementKeyInt); ok {
return x.ElementKeyInt
}
return 0
}
// XXX_OneofFuncs is for the internal use of the proto package.
func (*AttributePath_Step) XXX_OneofFuncs() (func(msg proto.Message, b *proto.Buffer) error, func(msg proto.Message, tag, wire int, b *proto.Buffer) (bool, error), func(msg proto.Message) (n int), []interface{}) {
return _AttributePath_Step_OneofMarshaler, _AttributePath_Step_OneofUnmarshaler, _AttributePath_Step_OneofSizer, []interface{}{
(*AttributePath_Step_AttributeName)(nil),
(*AttributePath_Step_ElementKeyString)(nil),
(*AttributePath_Step_ElementKeyInt)(nil),
}
}
func _AttributePath_Step_OneofMarshaler(msg proto.Message, b *proto.Buffer) error {
m := msg.(*AttributePath_Step)
// selector
switch x := m.Selector.(type) {
case *AttributePath_Step_AttributeName:
b.EncodeVarint(1<<3 | proto.WireBytes)
b.EncodeStringBytes(x.AttributeName)
case *AttributePath_Step_ElementKeyString:
b.EncodeVarint(2<<3 | proto.WireBytes)
b.EncodeStringBytes(x.ElementKeyString)
case *AttributePath_Step_ElementKeyInt:
b.EncodeVarint(3<<3 | proto.WireVarint)
b.EncodeVarint(uint64(x.ElementKeyInt))
case nil:
default:
return fmt.Errorf("AttributePath_Step.Selector has unexpected type %T", x)
}
return nil
}
func _AttributePath_Step_OneofUnmarshaler(msg proto.Message, tag, wire int, b *proto.Buffer) (bool, error) {
m := msg.(*AttributePath_Step)
switch tag {
case 1: // selector.attribute_name
if wire != proto.WireBytes {
return true, proto.ErrInternalBadWireType
}
x, err := b.DecodeStringBytes()
m.Selector = &AttributePath_Step_AttributeName{x}
return true, err
case 2: // selector.element_key_string
if wire != proto.WireBytes {
return true, proto.ErrInternalBadWireType
}
x, err := b.DecodeStringBytes()
m.Selector = &AttributePath_Step_ElementKeyString{x}
return true, err
case 3: // selector.element_key_int
if wire != proto.WireVarint {
return true, proto.ErrInternalBadWireType
}
x, err := b.DecodeVarint()
m.Selector = &AttributePath_Step_ElementKeyInt{int64(x)}
return true, err
default:
return false, nil
}
}
func _AttributePath_Step_OneofSizer(msg proto.Message) (n int) {
m := msg.(*AttributePath_Step)
// selector
switch x := m.Selector.(type) {
case *AttributePath_Step_AttributeName:
n += 1 // tag and wire
n += proto.SizeVarint(uint64(len(x.AttributeName)))
n += len(x.AttributeName)
case *AttributePath_Step_ElementKeyString:
n += 1 // tag and wire
n += proto.SizeVarint(uint64(len(x.ElementKeyString)))
n += len(x.ElementKeyString)
case *AttributePath_Step_ElementKeyInt:
n += 1 // tag and wire
n += proto.SizeVarint(uint64(x.ElementKeyInt))
case nil:
default:
panic(fmt.Sprintf("proto: unexpected type %T in oneof", x))
}
return n
}
type Stop struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *Stop) Reset() { *m = Stop{} }
func (m *Stop) String() string { return proto.CompactTextString(m) }
func (*Stop) ProtoMessage() {}
func (*Stop) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{3}
}
func (m *Stop) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_Stop.Unmarshal(m, b)
}
func (m *Stop) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_Stop.Marshal(b, m, deterministic)
}
func (dst *Stop) XXX_Merge(src proto.Message) {
xxx_messageInfo_Stop.Merge(dst, src)
}
func (m *Stop) XXX_Size() int {
return xxx_messageInfo_Stop.Size(m)
}
func (m *Stop) XXX_DiscardUnknown() {
xxx_messageInfo_Stop.DiscardUnknown(m)
}
var xxx_messageInfo_Stop proto.InternalMessageInfo
type Stop_Request struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *Stop_Request) Reset() { *m = Stop_Request{} }
func (m *Stop_Request) String() string { return proto.CompactTextString(m) }
func (*Stop_Request) ProtoMessage() {}
func (*Stop_Request) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{3, 0}
}
func (m *Stop_Request) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_Stop_Request.Unmarshal(m, b)
}
func (m *Stop_Request) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_Stop_Request.Marshal(b, m, deterministic)
}
func (dst *Stop_Request) XXX_Merge(src proto.Message) {
xxx_messageInfo_Stop_Request.Merge(dst, src)
}
func (m *Stop_Request) XXX_Size() int {
return xxx_messageInfo_Stop_Request.Size(m)
}
func (m *Stop_Request) XXX_DiscardUnknown() {
xxx_messageInfo_Stop_Request.DiscardUnknown(m)
}
var xxx_messageInfo_Stop_Request proto.InternalMessageInfo
type Stop_Response struct {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
Error string `protobuf:"bytes,1,opt,name=Error,proto3" json:"Error,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *Stop_Response) Reset() { *m = Stop_Response{} }
func (m *Stop_Response) String() string { return proto.CompactTextString(m) }
func (*Stop_Response) ProtoMessage() {}
func (*Stop_Response) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{3, 1}
}
func (m *Stop_Response) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_Stop_Response.Unmarshal(m, b)
}
func (m *Stop_Response) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_Stop_Response.Marshal(b, m, deterministic)
}
func (dst *Stop_Response) XXX_Merge(src proto.Message) {
xxx_messageInfo_Stop_Response.Merge(dst, src)
}
func (m *Stop_Response) XXX_Size() int {
return xxx_messageInfo_Stop_Response.Size(m)
}
func (m *Stop_Response) XXX_DiscardUnknown() {
xxx_messageInfo_Stop_Response.DiscardUnknown(m)
}
var xxx_messageInfo_Stop_Response proto.InternalMessageInfo
func (m *Stop_Response) GetError() string {
if m != nil {
return m.Error
}
return ""
}
// RawState holds the stored state for a resource to be upgraded by the
// provider. It can be in one of two formats, the current json encoded format
// in bytes, or the legacy flatmap format as a map of strings.
type RawState struct {
Json []byte `protobuf:"bytes,1,opt,name=json,proto3" json:"json,omitempty"`
Flatmap map[string]string `protobuf:"bytes,2,rep,name=flatmap,proto3" json:"flatmap,omitempty" protobuf_key:"bytes,1,opt,name=key,proto3" protobuf_val:"bytes,2,opt,name=value,proto3"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *RawState) Reset() { *m = RawState{} }
func (m *RawState) String() string { return proto.CompactTextString(m) }
func (*RawState) ProtoMessage() {}
func (*RawState) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{4}
}
func (m *RawState) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_RawState.Unmarshal(m, b)
}
func (m *RawState) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_RawState.Marshal(b, m, deterministic)
}
func (dst *RawState) XXX_Merge(src proto.Message) {
xxx_messageInfo_RawState.Merge(dst, src)
}
func (m *RawState) XXX_Size() int {
return xxx_messageInfo_RawState.Size(m)
}
func (m *RawState) XXX_DiscardUnknown() {
xxx_messageInfo_RawState.DiscardUnknown(m)
}
var xxx_messageInfo_RawState proto.InternalMessageInfo
func (m *RawState) GetJson() []byte {
if m != nil {
return m.Json
}
return nil
}
func (m *RawState) GetFlatmap() map[string]string {
if m != nil {
return m.Flatmap
}
return nil
}
// Schema is the configuration schema for a Resource, Provider, or Provisioner.
type Schema struct {
// The version of the schema.
// Schemas are versioned, so that providers can upgrade a saved resource
// state when the schema is changed.
Version int64 `protobuf:"varint,1,opt,name=version,proto3" json:"version,omitempty"`
// Block is the top level configuration block for this schema.
Block *Schema_Block `protobuf:"bytes,2,opt,name=block,proto3" json:"block,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *Schema) Reset() { *m = Schema{} }
func (m *Schema) String() string { return proto.CompactTextString(m) }
func (*Schema) ProtoMessage() {}
func (*Schema) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{5}
}
func (m *Schema) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_Schema.Unmarshal(m, b)
}
func (m *Schema) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_Schema.Marshal(b, m, deterministic)
}
func (dst *Schema) XXX_Merge(src proto.Message) {
xxx_messageInfo_Schema.Merge(dst, src)
}
func (m *Schema) XXX_Size() int {
return xxx_messageInfo_Schema.Size(m)
}
func (m *Schema) XXX_DiscardUnknown() {
xxx_messageInfo_Schema.DiscardUnknown(m)
}
var xxx_messageInfo_Schema proto.InternalMessageInfo
func (m *Schema) GetVersion() int64 {
if m != nil {
return m.Version
}
return 0
}
func (m *Schema) GetBlock() *Schema_Block {
if m != nil {
return m.Block
}
return nil
}
type Schema_Block struct {
Version int64 `protobuf:"varint,1,opt,name=version,proto3" json:"version,omitempty"`
Attributes []*Schema_Attribute `protobuf:"bytes,2,rep,name=attributes,proto3" json:"attributes,omitempty"`
BlockTypes []*Schema_NestedBlock `protobuf:"bytes,3,rep,name=block_types,json=blockTypes,proto3" json:"block_types,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *Schema_Block) Reset() { *m = Schema_Block{} }
func (m *Schema_Block) String() string { return proto.CompactTextString(m) }
func (*Schema_Block) ProtoMessage() {}
func (*Schema_Block) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{5, 0}
}
func (m *Schema_Block) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_Schema_Block.Unmarshal(m, b)
}
func (m *Schema_Block) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_Schema_Block.Marshal(b, m, deterministic)
}
func (dst *Schema_Block) XXX_Merge(src proto.Message) {
xxx_messageInfo_Schema_Block.Merge(dst, src)
}
func (m *Schema_Block) XXX_Size() int {
return xxx_messageInfo_Schema_Block.Size(m)
}
func (m *Schema_Block) XXX_DiscardUnknown() {
xxx_messageInfo_Schema_Block.DiscardUnknown(m)
}
var xxx_messageInfo_Schema_Block proto.InternalMessageInfo
func (m *Schema_Block) GetVersion() int64 {
if m != nil {
return m.Version
}
return 0
}
func (m *Schema_Block) GetAttributes() []*Schema_Attribute {
if m != nil {
return m.Attributes
}
return nil
}
func (m *Schema_Block) GetBlockTypes() []*Schema_NestedBlock {
if m != nil {
return m.BlockTypes
}
return nil
}
type Schema_Attribute struct {
Name string `protobuf:"bytes,1,opt,name=name,proto3" json:"name,omitempty"`
Type []byte `protobuf:"bytes,2,opt,name=type,proto3" json:"type,omitempty"`
Description string `protobuf:"bytes,3,opt,name=description,proto3" json:"description,omitempty"`
Required bool `protobuf:"varint,4,opt,name=required,proto3" json:"required,omitempty"`
Optional bool `protobuf:"varint,5,opt,name=optional,proto3" json:"optional,omitempty"`
Computed bool `protobuf:"varint,6,opt,name=computed,proto3" json:"computed,omitempty"`
Sensitive bool `protobuf:"varint,7,opt,name=sensitive,proto3" json:"sensitive,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *Schema_Attribute) Reset() { *m = Schema_Attribute{} }
func (m *Schema_Attribute) String() string { return proto.CompactTextString(m) }
func (*Schema_Attribute) ProtoMessage() {}
func (*Schema_Attribute) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{5, 1}
}
func (m *Schema_Attribute) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_Schema_Attribute.Unmarshal(m, b)
}
func (m *Schema_Attribute) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_Schema_Attribute.Marshal(b, m, deterministic)
}
func (dst *Schema_Attribute) XXX_Merge(src proto.Message) {
xxx_messageInfo_Schema_Attribute.Merge(dst, src)
}
func (m *Schema_Attribute) XXX_Size() int {
return xxx_messageInfo_Schema_Attribute.Size(m)
}
func (m *Schema_Attribute) XXX_DiscardUnknown() {
xxx_messageInfo_Schema_Attribute.DiscardUnknown(m)
}
var xxx_messageInfo_Schema_Attribute proto.InternalMessageInfo
func (m *Schema_Attribute) GetName() string {
if m != nil {
return m.Name
}
return ""
}
func (m *Schema_Attribute) GetType() []byte {
if m != nil {
return m.Type
}
return nil
}
func (m *Schema_Attribute) GetDescription() string {
if m != nil {
return m.Description
}
return ""
}
func (m *Schema_Attribute) GetRequired() bool {
if m != nil {
return m.Required
}
return false
}
func (m *Schema_Attribute) GetOptional() bool {
if m != nil {
return m.Optional
}
return false
}
func (m *Schema_Attribute) GetComputed() bool {
if m != nil {
return m.Computed
}
return false
}
func (m *Schema_Attribute) GetSensitive() bool {
if m != nil {
return m.Sensitive
}
return false
}
type Schema_NestedBlock struct {
TypeName string `protobuf:"bytes,1,opt,name=type_name,json=typeName,proto3" json:"type_name,omitempty"`
Block *Schema_Block `protobuf:"bytes,2,opt,name=block,proto3" json:"block,omitempty"`
Nesting Schema_NestedBlock_NestingMode `protobuf:"varint,3,opt,name=nesting,proto3,enum=tfplugin5.Schema_NestedBlock_NestingMode" json:"nesting,omitempty"`
MinItems int64 `protobuf:"varint,4,opt,name=min_items,json=minItems,proto3" json:"min_items,omitempty"`
MaxItems int64 `protobuf:"varint,5,opt,name=max_items,json=maxItems,proto3" json:"max_items,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *Schema_NestedBlock) Reset() { *m = Schema_NestedBlock{} }
func (m *Schema_NestedBlock) String() string { return proto.CompactTextString(m) }
func (*Schema_NestedBlock) ProtoMessage() {}
func (*Schema_NestedBlock) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{5, 2}
}
func (m *Schema_NestedBlock) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_Schema_NestedBlock.Unmarshal(m, b)
}
func (m *Schema_NestedBlock) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_Schema_NestedBlock.Marshal(b, m, deterministic)
}
func (dst *Schema_NestedBlock) XXX_Merge(src proto.Message) {
xxx_messageInfo_Schema_NestedBlock.Merge(dst, src)
}
func (m *Schema_NestedBlock) XXX_Size() int {
return xxx_messageInfo_Schema_NestedBlock.Size(m)
}
func (m *Schema_NestedBlock) XXX_DiscardUnknown() {
xxx_messageInfo_Schema_NestedBlock.DiscardUnknown(m)
}
var xxx_messageInfo_Schema_NestedBlock proto.InternalMessageInfo
func (m *Schema_NestedBlock) GetTypeName() string {
if m != nil {
return m.TypeName
}
return ""
}
func (m *Schema_NestedBlock) GetBlock() *Schema_Block {
if m != nil {
return m.Block
}
return nil
}
func (m *Schema_NestedBlock) GetNesting() Schema_NestedBlock_NestingMode {
if m != nil {
return m.Nesting
}
return Schema_NestedBlock_INVALID
}
func (m *Schema_NestedBlock) GetMinItems() int64 {
if m != nil {
return m.MinItems
}
return 0
}
func (m *Schema_NestedBlock) GetMaxItems() int64 {
if m != nil {
return m.MaxItems
}
return 0
}
type GetProviderSchema struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *GetProviderSchema) Reset() { *m = GetProviderSchema{} }
func (m *GetProviderSchema) String() string { return proto.CompactTextString(m) }
func (*GetProviderSchema) ProtoMessage() {}
func (*GetProviderSchema) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{6}
}
func (m *GetProviderSchema) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_GetProviderSchema.Unmarshal(m, b)
}
func (m *GetProviderSchema) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_GetProviderSchema.Marshal(b, m, deterministic)
}
func (dst *GetProviderSchema) XXX_Merge(src proto.Message) {
xxx_messageInfo_GetProviderSchema.Merge(dst, src)
}
func (m *GetProviderSchema) XXX_Size() int {
return xxx_messageInfo_GetProviderSchema.Size(m)
}
func (m *GetProviderSchema) XXX_DiscardUnknown() {
xxx_messageInfo_GetProviderSchema.DiscardUnknown(m)
}
var xxx_messageInfo_GetProviderSchema proto.InternalMessageInfo
type GetProviderSchema_Request struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *GetProviderSchema_Request) Reset() { *m = GetProviderSchema_Request{} }
func (m *GetProviderSchema_Request) String() string { return proto.CompactTextString(m) }
func (*GetProviderSchema_Request) ProtoMessage() {}
func (*GetProviderSchema_Request) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{6, 0}
}
func (m *GetProviderSchema_Request) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_GetProviderSchema_Request.Unmarshal(m, b)
}
func (m *GetProviderSchema_Request) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_GetProviderSchema_Request.Marshal(b, m, deterministic)
}
func (dst *GetProviderSchema_Request) XXX_Merge(src proto.Message) {
xxx_messageInfo_GetProviderSchema_Request.Merge(dst, src)
}
func (m *GetProviderSchema_Request) XXX_Size() int {
return xxx_messageInfo_GetProviderSchema_Request.Size(m)
}
func (m *GetProviderSchema_Request) XXX_DiscardUnknown() {
xxx_messageInfo_GetProviderSchema_Request.DiscardUnknown(m)
}
var xxx_messageInfo_GetProviderSchema_Request proto.InternalMessageInfo
type GetProviderSchema_Response struct {
Provider *Schema `protobuf:"bytes,1,opt,name=provider,proto3" json:"provider,omitempty"`
ResourceSchemas map[string]*Schema `protobuf:"bytes,2,rep,name=resource_schemas,json=resourceSchemas,proto3" json:"resource_schemas,omitempty" protobuf_key:"bytes,1,opt,name=key,proto3" protobuf_val:"bytes,2,opt,name=value,proto3"`
DataSourceSchemas map[string]*Schema `protobuf:"bytes,3,rep,name=data_source_schemas,json=dataSourceSchemas,proto3" json:"data_source_schemas,omitempty" protobuf_key:"bytes,1,opt,name=key,proto3" protobuf_val:"bytes,2,opt,name=value,proto3"`
Diagnostics []*Diagnostic `protobuf:"bytes,4,rep,name=diagnostics,proto3" json:"diagnostics,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *GetProviderSchema_Response) Reset() { *m = GetProviderSchema_Response{} }
func (m *GetProviderSchema_Response) String() string { return proto.CompactTextString(m) }
func (*GetProviderSchema_Response) ProtoMessage() {}
func (*GetProviderSchema_Response) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{6, 1}
}
func (m *GetProviderSchema_Response) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_GetProviderSchema_Response.Unmarshal(m, b)
}
func (m *GetProviderSchema_Response) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_GetProviderSchema_Response.Marshal(b, m, deterministic)
}
func (dst *GetProviderSchema_Response) XXX_Merge(src proto.Message) {
xxx_messageInfo_GetProviderSchema_Response.Merge(dst, src)
}
func (m *GetProviderSchema_Response) XXX_Size() int {
return xxx_messageInfo_GetProviderSchema_Response.Size(m)
}
func (m *GetProviderSchema_Response) XXX_DiscardUnknown() {
xxx_messageInfo_GetProviderSchema_Response.DiscardUnknown(m)
}
var xxx_messageInfo_GetProviderSchema_Response proto.InternalMessageInfo
func (m *GetProviderSchema_Response) GetProvider() *Schema {
if m != nil {
return m.Provider
}
return nil
}
func (m *GetProviderSchema_Response) GetResourceSchemas() map[string]*Schema {
if m != nil {
return m.ResourceSchemas
}
return nil
}
func (m *GetProviderSchema_Response) GetDataSourceSchemas() map[string]*Schema {
if m != nil {
return m.DataSourceSchemas
}
return nil
}
func (m *GetProviderSchema_Response) GetDiagnostics() []*Diagnostic {
if m != nil {
return m.Diagnostics
}
return nil
}
type PrepareProviderConfig struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *PrepareProviderConfig) Reset() { *m = PrepareProviderConfig{} }
func (m *PrepareProviderConfig) String() string { return proto.CompactTextString(m) }
func (*PrepareProviderConfig) ProtoMessage() {}
func (*PrepareProviderConfig) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{7}
}
func (m *PrepareProviderConfig) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_PrepareProviderConfig.Unmarshal(m, b)
}
func (m *PrepareProviderConfig) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_PrepareProviderConfig.Marshal(b, m, deterministic)
}
func (dst *PrepareProviderConfig) XXX_Merge(src proto.Message) {
xxx_messageInfo_PrepareProviderConfig.Merge(dst, src)
}
func (m *PrepareProviderConfig) XXX_Size() int {
return xxx_messageInfo_PrepareProviderConfig.Size(m)
}
func (m *PrepareProviderConfig) XXX_DiscardUnknown() {
xxx_messageInfo_PrepareProviderConfig.DiscardUnknown(m)
}
var xxx_messageInfo_PrepareProviderConfig proto.InternalMessageInfo
type PrepareProviderConfig_Request struct {
Config *DynamicValue `protobuf:"bytes,1,opt,name=config,proto3" json:"config,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *PrepareProviderConfig_Request) Reset() { *m = PrepareProviderConfig_Request{} }
func (m *PrepareProviderConfig_Request) String() string { return proto.CompactTextString(m) }
func (*PrepareProviderConfig_Request) ProtoMessage() {}
func (*PrepareProviderConfig_Request) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{7, 0}
}
func (m *PrepareProviderConfig_Request) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_PrepareProviderConfig_Request.Unmarshal(m, b)
}
func (m *PrepareProviderConfig_Request) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_PrepareProviderConfig_Request.Marshal(b, m, deterministic)
}
func (dst *PrepareProviderConfig_Request) XXX_Merge(src proto.Message) {
xxx_messageInfo_PrepareProviderConfig_Request.Merge(dst, src)
}
func (m *PrepareProviderConfig_Request) XXX_Size() int {
return xxx_messageInfo_PrepareProviderConfig_Request.Size(m)
}
func (m *PrepareProviderConfig_Request) XXX_DiscardUnknown() {
xxx_messageInfo_PrepareProviderConfig_Request.DiscardUnknown(m)
}
var xxx_messageInfo_PrepareProviderConfig_Request proto.InternalMessageInfo
func (m *PrepareProviderConfig_Request) GetConfig() *DynamicValue {
if m != nil {
return m.Config
}
return nil
}
type PrepareProviderConfig_Response struct {
PreparedConfig *DynamicValue `protobuf:"bytes,1,opt,name=prepared_config,json=preparedConfig,proto3" json:"prepared_config,omitempty"`
Diagnostics []*Diagnostic `protobuf:"bytes,2,rep,name=diagnostics,proto3" json:"diagnostics,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *PrepareProviderConfig_Response) Reset() { *m = PrepareProviderConfig_Response{} }
func (m *PrepareProviderConfig_Response) String() string { return proto.CompactTextString(m) }
func (*PrepareProviderConfig_Response) ProtoMessage() {}
func (*PrepareProviderConfig_Response) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{7, 1}
}
func (m *PrepareProviderConfig_Response) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_PrepareProviderConfig_Response.Unmarshal(m, b)
}
func (m *PrepareProviderConfig_Response) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_PrepareProviderConfig_Response.Marshal(b, m, deterministic)
}
func (dst *PrepareProviderConfig_Response) XXX_Merge(src proto.Message) {
xxx_messageInfo_PrepareProviderConfig_Response.Merge(dst, src)
}
func (m *PrepareProviderConfig_Response) XXX_Size() int {
return xxx_messageInfo_PrepareProviderConfig_Response.Size(m)
}
func (m *PrepareProviderConfig_Response) XXX_DiscardUnknown() {
xxx_messageInfo_PrepareProviderConfig_Response.DiscardUnknown(m)
}
var xxx_messageInfo_PrepareProviderConfig_Response proto.InternalMessageInfo
func (m *PrepareProviderConfig_Response) GetPreparedConfig() *DynamicValue {
if m != nil {
return m.PreparedConfig
}
return nil
}
func (m *PrepareProviderConfig_Response) GetDiagnostics() []*Diagnostic {
if m != nil {
return m.Diagnostics
}
return nil
}
type UpgradeResourceState struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *UpgradeResourceState) Reset() { *m = UpgradeResourceState{} }
func (m *UpgradeResourceState) String() string { return proto.CompactTextString(m) }
func (*UpgradeResourceState) ProtoMessage() {}
func (*UpgradeResourceState) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{8}
}
func (m *UpgradeResourceState) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_UpgradeResourceState.Unmarshal(m, b)
}
func (m *UpgradeResourceState) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_UpgradeResourceState.Marshal(b, m, deterministic)
}
func (dst *UpgradeResourceState) XXX_Merge(src proto.Message) {
xxx_messageInfo_UpgradeResourceState.Merge(dst, src)
}
func (m *UpgradeResourceState) XXX_Size() int {
return xxx_messageInfo_UpgradeResourceState.Size(m)
}
func (m *UpgradeResourceState) XXX_DiscardUnknown() {
xxx_messageInfo_UpgradeResourceState.DiscardUnknown(m)
}
var xxx_messageInfo_UpgradeResourceState proto.InternalMessageInfo
type UpgradeResourceState_Request struct {
TypeName string `protobuf:"bytes,1,opt,name=type_name,json=typeName,proto3" json:"type_name,omitempty"`
// version is the schema_version number recorded in the state file
Version int64 `protobuf:"varint,2,opt,name=version,proto3" json:"version,omitempty"`
// raw_state is the raw states as stored for the resource. Core does
// not have access to the schema of prior_version, so it's the
// provider's responsibility to interpret this value using the
// appropriate older schema. The raw_state will be the json encoded
// state, or a legacy flat-mapped format.
RawState *RawState `protobuf:"bytes,3,opt,name=raw_state,json=rawState,proto3" json:"raw_state,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *UpgradeResourceState_Request) Reset() { *m = UpgradeResourceState_Request{} }
func (m *UpgradeResourceState_Request) String() string { return proto.CompactTextString(m) }
func (*UpgradeResourceState_Request) ProtoMessage() {}
func (*UpgradeResourceState_Request) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{8, 0}
}
func (m *UpgradeResourceState_Request) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_UpgradeResourceState_Request.Unmarshal(m, b)
}
func (m *UpgradeResourceState_Request) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_UpgradeResourceState_Request.Marshal(b, m, deterministic)
}
func (dst *UpgradeResourceState_Request) XXX_Merge(src proto.Message) {
xxx_messageInfo_UpgradeResourceState_Request.Merge(dst, src)
}
func (m *UpgradeResourceState_Request) XXX_Size() int {
return xxx_messageInfo_UpgradeResourceState_Request.Size(m)
}
func (m *UpgradeResourceState_Request) XXX_DiscardUnknown() {
xxx_messageInfo_UpgradeResourceState_Request.DiscardUnknown(m)
}
var xxx_messageInfo_UpgradeResourceState_Request proto.InternalMessageInfo
func (m *UpgradeResourceState_Request) GetTypeName() string {
if m != nil {
return m.TypeName
}
return ""
}
func (m *UpgradeResourceState_Request) GetVersion() int64 {
if m != nil {
return m.Version
}
return 0
}
func (m *UpgradeResourceState_Request) GetRawState() *RawState {
if m != nil {
return m.RawState
}
return nil
}
type UpgradeResourceState_Response struct {
// new_state is a msgpack-encoded data structure that, when interpreted with
// the _current_ schema for this resource type, is functionally equivalent to
// that which was given in prior_state_raw.
UpgradedState *DynamicValue `protobuf:"bytes,1,opt,name=upgraded_state,json=upgradedState,proto3" json:"upgraded_state,omitempty"`
// diagnostics describes any errors encountered during migration that could not
// be safely resolved, and warnings about any possibly-risky assumptions made
// in the upgrade process.
Diagnostics []*Diagnostic `protobuf:"bytes,2,rep,name=diagnostics,proto3" json:"diagnostics,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *UpgradeResourceState_Response) Reset() { *m = UpgradeResourceState_Response{} }
func (m *UpgradeResourceState_Response) String() string { return proto.CompactTextString(m) }
func (*UpgradeResourceState_Response) ProtoMessage() {}
func (*UpgradeResourceState_Response) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{8, 1}
}
func (m *UpgradeResourceState_Response) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_UpgradeResourceState_Response.Unmarshal(m, b)
}
func (m *UpgradeResourceState_Response) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_UpgradeResourceState_Response.Marshal(b, m, deterministic)
}
func (dst *UpgradeResourceState_Response) XXX_Merge(src proto.Message) {
xxx_messageInfo_UpgradeResourceState_Response.Merge(dst, src)
}
func (m *UpgradeResourceState_Response) XXX_Size() int {
return xxx_messageInfo_UpgradeResourceState_Response.Size(m)
}
func (m *UpgradeResourceState_Response) XXX_DiscardUnknown() {
xxx_messageInfo_UpgradeResourceState_Response.DiscardUnknown(m)
}
var xxx_messageInfo_UpgradeResourceState_Response proto.InternalMessageInfo
func (m *UpgradeResourceState_Response) GetUpgradedState() *DynamicValue {
if m != nil {
return m.UpgradedState
}
return nil
}
func (m *UpgradeResourceState_Response) GetDiagnostics() []*Diagnostic {
if m != nil {
return m.Diagnostics
}
return nil
}
type ValidateResourceTypeConfig struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ValidateResourceTypeConfig) Reset() { *m = ValidateResourceTypeConfig{} }
func (m *ValidateResourceTypeConfig) String() string { return proto.CompactTextString(m) }
func (*ValidateResourceTypeConfig) ProtoMessage() {}
func (*ValidateResourceTypeConfig) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{9}
}
func (m *ValidateResourceTypeConfig) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ValidateResourceTypeConfig.Unmarshal(m, b)
}
func (m *ValidateResourceTypeConfig) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ValidateResourceTypeConfig.Marshal(b, m, deterministic)
}
func (dst *ValidateResourceTypeConfig) XXX_Merge(src proto.Message) {
xxx_messageInfo_ValidateResourceTypeConfig.Merge(dst, src)
}
func (m *ValidateResourceTypeConfig) XXX_Size() int {
return xxx_messageInfo_ValidateResourceTypeConfig.Size(m)
}
func (m *ValidateResourceTypeConfig) XXX_DiscardUnknown() {
xxx_messageInfo_ValidateResourceTypeConfig.DiscardUnknown(m)
}
var xxx_messageInfo_ValidateResourceTypeConfig proto.InternalMessageInfo
type ValidateResourceTypeConfig_Request struct {
TypeName string `protobuf:"bytes,1,opt,name=type_name,json=typeName,proto3" json:"type_name,omitempty"`
Config *DynamicValue `protobuf:"bytes,2,opt,name=config,proto3" json:"config,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ValidateResourceTypeConfig_Request) Reset() { *m = ValidateResourceTypeConfig_Request{} }
func (m *ValidateResourceTypeConfig_Request) String() string { return proto.CompactTextString(m) }
func (*ValidateResourceTypeConfig_Request) ProtoMessage() {}
func (*ValidateResourceTypeConfig_Request) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{9, 0}
}
func (m *ValidateResourceTypeConfig_Request) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ValidateResourceTypeConfig_Request.Unmarshal(m, b)
}
func (m *ValidateResourceTypeConfig_Request) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ValidateResourceTypeConfig_Request.Marshal(b, m, deterministic)
}
func (dst *ValidateResourceTypeConfig_Request) XXX_Merge(src proto.Message) {
xxx_messageInfo_ValidateResourceTypeConfig_Request.Merge(dst, src)
}
func (m *ValidateResourceTypeConfig_Request) XXX_Size() int {
return xxx_messageInfo_ValidateResourceTypeConfig_Request.Size(m)
}
func (m *ValidateResourceTypeConfig_Request) XXX_DiscardUnknown() {
xxx_messageInfo_ValidateResourceTypeConfig_Request.DiscardUnknown(m)
}
var xxx_messageInfo_ValidateResourceTypeConfig_Request proto.InternalMessageInfo
func (m *ValidateResourceTypeConfig_Request) GetTypeName() string {
if m != nil {
return m.TypeName
}
return ""
}
func (m *ValidateResourceTypeConfig_Request) GetConfig() *DynamicValue {
if m != nil {
return m.Config
}
return nil
}
type ValidateResourceTypeConfig_Response struct {
Diagnostics []*Diagnostic `protobuf:"bytes,1,rep,name=diagnostics,proto3" json:"diagnostics,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ValidateResourceTypeConfig_Response) Reset() { *m = ValidateResourceTypeConfig_Response{} }
func (m *ValidateResourceTypeConfig_Response) String() string { return proto.CompactTextString(m) }
func (*ValidateResourceTypeConfig_Response) ProtoMessage() {}
func (*ValidateResourceTypeConfig_Response) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{9, 1}
}
func (m *ValidateResourceTypeConfig_Response) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ValidateResourceTypeConfig_Response.Unmarshal(m, b)
}
func (m *ValidateResourceTypeConfig_Response) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ValidateResourceTypeConfig_Response.Marshal(b, m, deterministic)
}
func (dst *ValidateResourceTypeConfig_Response) XXX_Merge(src proto.Message) {
xxx_messageInfo_ValidateResourceTypeConfig_Response.Merge(dst, src)
}
func (m *ValidateResourceTypeConfig_Response) XXX_Size() int {
return xxx_messageInfo_ValidateResourceTypeConfig_Response.Size(m)
}
func (m *ValidateResourceTypeConfig_Response) XXX_DiscardUnknown() {
xxx_messageInfo_ValidateResourceTypeConfig_Response.DiscardUnknown(m)
}
var xxx_messageInfo_ValidateResourceTypeConfig_Response proto.InternalMessageInfo
func (m *ValidateResourceTypeConfig_Response) GetDiagnostics() []*Diagnostic {
if m != nil {
return m.Diagnostics
}
return nil
}
type ValidateDataSourceConfig struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ValidateDataSourceConfig) Reset() { *m = ValidateDataSourceConfig{} }
func (m *ValidateDataSourceConfig) String() string { return proto.CompactTextString(m) }
func (*ValidateDataSourceConfig) ProtoMessage() {}
func (*ValidateDataSourceConfig) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{10}
}
func (m *ValidateDataSourceConfig) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ValidateDataSourceConfig.Unmarshal(m, b)
}
func (m *ValidateDataSourceConfig) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ValidateDataSourceConfig.Marshal(b, m, deterministic)
}
func (dst *ValidateDataSourceConfig) XXX_Merge(src proto.Message) {
xxx_messageInfo_ValidateDataSourceConfig.Merge(dst, src)
}
func (m *ValidateDataSourceConfig) XXX_Size() int {
return xxx_messageInfo_ValidateDataSourceConfig.Size(m)
}
func (m *ValidateDataSourceConfig) XXX_DiscardUnknown() {
xxx_messageInfo_ValidateDataSourceConfig.DiscardUnknown(m)
}
var xxx_messageInfo_ValidateDataSourceConfig proto.InternalMessageInfo
type ValidateDataSourceConfig_Request struct {
TypeName string `protobuf:"bytes,1,opt,name=type_name,json=typeName,proto3" json:"type_name,omitempty"`
Config *DynamicValue `protobuf:"bytes,2,opt,name=config,proto3" json:"config,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ValidateDataSourceConfig_Request) Reset() { *m = ValidateDataSourceConfig_Request{} }
func (m *ValidateDataSourceConfig_Request) String() string { return proto.CompactTextString(m) }
func (*ValidateDataSourceConfig_Request) ProtoMessage() {}
func (*ValidateDataSourceConfig_Request) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{10, 0}
}
func (m *ValidateDataSourceConfig_Request) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ValidateDataSourceConfig_Request.Unmarshal(m, b)
}
func (m *ValidateDataSourceConfig_Request) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ValidateDataSourceConfig_Request.Marshal(b, m, deterministic)
}
func (dst *ValidateDataSourceConfig_Request) XXX_Merge(src proto.Message) {
xxx_messageInfo_ValidateDataSourceConfig_Request.Merge(dst, src)
}
func (m *ValidateDataSourceConfig_Request) XXX_Size() int {
return xxx_messageInfo_ValidateDataSourceConfig_Request.Size(m)
}
func (m *ValidateDataSourceConfig_Request) XXX_DiscardUnknown() {
xxx_messageInfo_ValidateDataSourceConfig_Request.DiscardUnknown(m)
}
var xxx_messageInfo_ValidateDataSourceConfig_Request proto.InternalMessageInfo
func (m *ValidateDataSourceConfig_Request) GetTypeName() string {
if m != nil {
return m.TypeName
}
return ""
}
func (m *ValidateDataSourceConfig_Request) GetConfig() *DynamicValue {
if m != nil {
return m.Config
}
return nil
}
type ValidateDataSourceConfig_Response struct {
Diagnostics []*Diagnostic `protobuf:"bytes,1,rep,name=diagnostics,proto3" json:"diagnostics,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ValidateDataSourceConfig_Response) Reset() { *m = ValidateDataSourceConfig_Response{} }
func (m *ValidateDataSourceConfig_Response) String() string { return proto.CompactTextString(m) }
func (*ValidateDataSourceConfig_Response) ProtoMessage() {}
func (*ValidateDataSourceConfig_Response) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{10, 1}
}
func (m *ValidateDataSourceConfig_Response) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ValidateDataSourceConfig_Response.Unmarshal(m, b)
}
func (m *ValidateDataSourceConfig_Response) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ValidateDataSourceConfig_Response.Marshal(b, m, deterministic)
}
func (dst *ValidateDataSourceConfig_Response) XXX_Merge(src proto.Message) {
xxx_messageInfo_ValidateDataSourceConfig_Response.Merge(dst, src)
}
func (m *ValidateDataSourceConfig_Response) XXX_Size() int {
return xxx_messageInfo_ValidateDataSourceConfig_Response.Size(m)
}
func (m *ValidateDataSourceConfig_Response) XXX_DiscardUnknown() {
xxx_messageInfo_ValidateDataSourceConfig_Response.DiscardUnknown(m)
}
var xxx_messageInfo_ValidateDataSourceConfig_Response proto.InternalMessageInfo
func (m *ValidateDataSourceConfig_Response) GetDiagnostics() []*Diagnostic {
if m != nil {
return m.Diagnostics
}
return nil
}
type Configure struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *Configure) Reset() { *m = Configure{} }
func (m *Configure) String() string { return proto.CompactTextString(m) }
func (*Configure) ProtoMessage() {}
func (*Configure) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{11}
}
func (m *Configure) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_Configure.Unmarshal(m, b)
}
func (m *Configure) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_Configure.Marshal(b, m, deterministic)
}
func (dst *Configure) XXX_Merge(src proto.Message) {
xxx_messageInfo_Configure.Merge(dst, src)
}
func (m *Configure) XXX_Size() int {
return xxx_messageInfo_Configure.Size(m)
}
func (m *Configure) XXX_DiscardUnknown() {
xxx_messageInfo_Configure.DiscardUnknown(m)
}
var xxx_messageInfo_Configure proto.InternalMessageInfo
type Configure_Request struct {
TerraformVersion string `protobuf:"bytes,1,opt,name=terraform_version,json=terraformVersion,proto3" json:"terraform_version,omitempty"`
Config *DynamicValue `protobuf:"bytes,2,opt,name=config,proto3" json:"config,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *Configure_Request) Reset() { *m = Configure_Request{} }
func (m *Configure_Request) String() string { return proto.CompactTextString(m) }
func (*Configure_Request) ProtoMessage() {}
func (*Configure_Request) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{11, 0}
}
func (m *Configure_Request) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_Configure_Request.Unmarshal(m, b)
}
func (m *Configure_Request) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_Configure_Request.Marshal(b, m, deterministic)
}
func (dst *Configure_Request) XXX_Merge(src proto.Message) {
xxx_messageInfo_Configure_Request.Merge(dst, src)
}
func (m *Configure_Request) XXX_Size() int {
return xxx_messageInfo_Configure_Request.Size(m)
}
func (m *Configure_Request) XXX_DiscardUnknown() {
xxx_messageInfo_Configure_Request.DiscardUnknown(m)
}
var xxx_messageInfo_Configure_Request proto.InternalMessageInfo
func (m *Configure_Request) GetTerraformVersion() string {
if m != nil {
return m.TerraformVersion
}
return ""
}
func (m *Configure_Request) GetConfig() *DynamicValue {
if m != nil {
return m.Config
}
return nil
}
type Configure_Response struct {
Diagnostics []*Diagnostic `protobuf:"bytes,1,rep,name=diagnostics,proto3" json:"diagnostics,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *Configure_Response) Reset() { *m = Configure_Response{} }
func (m *Configure_Response) String() string { return proto.CompactTextString(m) }
func (*Configure_Response) ProtoMessage() {}
func (*Configure_Response) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{11, 1}
}
func (m *Configure_Response) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_Configure_Response.Unmarshal(m, b)
}
func (m *Configure_Response) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_Configure_Response.Marshal(b, m, deterministic)
}
func (dst *Configure_Response) XXX_Merge(src proto.Message) {
xxx_messageInfo_Configure_Response.Merge(dst, src)
}
func (m *Configure_Response) XXX_Size() int {
return xxx_messageInfo_Configure_Response.Size(m)
}
func (m *Configure_Response) XXX_DiscardUnknown() {
xxx_messageInfo_Configure_Response.DiscardUnknown(m)
}
var xxx_messageInfo_Configure_Response proto.InternalMessageInfo
func (m *Configure_Response) GetDiagnostics() []*Diagnostic {
if m != nil {
return m.Diagnostics
}
return nil
}
type ReadResource struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ReadResource) Reset() { *m = ReadResource{} }
func (m *ReadResource) String() string { return proto.CompactTextString(m) }
func (*ReadResource) ProtoMessage() {}
func (*ReadResource) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{12}
}
func (m *ReadResource) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ReadResource.Unmarshal(m, b)
}
func (m *ReadResource) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ReadResource.Marshal(b, m, deterministic)
}
func (dst *ReadResource) XXX_Merge(src proto.Message) {
xxx_messageInfo_ReadResource.Merge(dst, src)
}
func (m *ReadResource) XXX_Size() int {
return xxx_messageInfo_ReadResource.Size(m)
}
func (m *ReadResource) XXX_DiscardUnknown() {
xxx_messageInfo_ReadResource.DiscardUnknown(m)
}
var xxx_messageInfo_ReadResource proto.InternalMessageInfo
type ReadResource_Request struct {
TypeName string `protobuf:"bytes,1,opt,name=type_name,json=typeName,proto3" json:"type_name,omitempty"`
CurrentState *DynamicValue `protobuf:"bytes,2,opt,name=current_state,json=currentState,proto3" json:"current_state,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ReadResource_Request) Reset() { *m = ReadResource_Request{} }
func (m *ReadResource_Request) String() string { return proto.CompactTextString(m) }
func (*ReadResource_Request) ProtoMessage() {}
func (*ReadResource_Request) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{12, 0}
}
func (m *ReadResource_Request) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ReadResource_Request.Unmarshal(m, b)
}
func (m *ReadResource_Request) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ReadResource_Request.Marshal(b, m, deterministic)
}
func (dst *ReadResource_Request) XXX_Merge(src proto.Message) {
xxx_messageInfo_ReadResource_Request.Merge(dst, src)
}
func (m *ReadResource_Request) XXX_Size() int {
return xxx_messageInfo_ReadResource_Request.Size(m)
}
func (m *ReadResource_Request) XXX_DiscardUnknown() {
xxx_messageInfo_ReadResource_Request.DiscardUnknown(m)
}
var xxx_messageInfo_ReadResource_Request proto.InternalMessageInfo
func (m *ReadResource_Request) GetTypeName() string {
if m != nil {
return m.TypeName
}
return ""
}
func (m *ReadResource_Request) GetCurrentState() *DynamicValue {
if m != nil {
return m.CurrentState
}
return nil
}
type ReadResource_Response struct {
NewState *DynamicValue `protobuf:"bytes,1,opt,name=new_state,json=newState,proto3" json:"new_state,omitempty"`
Diagnostics []*Diagnostic `protobuf:"bytes,2,rep,name=diagnostics,proto3" json:"diagnostics,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ReadResource_Response) Reset() { *m = ReadResource_Response{} }
func (m *ReadResource_Response) String() string { return proto.CompactTextString(m) }
func (*ReadResource_Response) ProtoMessage() {}
func (*ReadResource_Response) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{12, 1}
}
func (m *ReadResource_Response) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ReadResource_Response.Unmarshal(m, b)
}
func (m *ReadResource_Response) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ReadResource_Response.Marshal(b, m, deterministic)
}
func (dst *ReadResource_Response) XXX_Merge(src proto.Message) {
xxx_messageInfo_ReadResource_Response.Merge(dst, src)
}
func (m *ReadResource_Response) XXX_Size() int {
return xxx_messageInfo_ReadResource_Response.Size(m)
}
func (m *ReadResource_Response) XXX_DiscardUnknown() {
xxx_messageInfo_ReadResource_Response.DiscardUnknown(m)
}
var xxx_messageInfo_ReadResource_Response proto.InternalMessageInfo
func (m *ReadResource_Response) GetNewState() *DynamicValue {
if m != nil {
return m.NewState
}
return nil
}
func (m *ReadResource_Response) GetDiagnostics() []*Diagnostic {
if m != nil {
return m.Diagnostics
}
return nil
}
type PlanResourceChange struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *PlanResourceChange) Reset() { *m = PlanResourceChange{} }
func (m *PlanResourceChange) String() string { return proto.CompactTextString(m) }
func (*PlanResourceChange) ProtoMessage() {}
func (*PlanResourceChange) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{13}
}
func (m *PlanResourceChange) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_PlanResourceChange.Unmarshal(m, b)
}
func (m *PlanResourceChange) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_PlanResourceChange.Marshal(b, m, deterministic)
}
func (dst *PlanResourceChange) XXX_Merge(src proto.Message) {
xxx_messageInfo_PlanResourceChange.Merge(dst, src)
}
func (m *PlanResourceChange) XXX_Size() int {
return xxx_messageInfo_PlanResourceChange.Size(m)
}
func (m *PlanResourceChange) XXX_DiscardUnknown() {
xxx_messageInfo_PlanResourceChange.DiscardUnknown(m)
}
var xxx_messageInfo_PlanResourceChange proto.InternalMessageInfo
type PlanResourceChange_Request struct {
TypeName string `protobuf:"bytes,1,opt,name=type_name,json=typeName,proto3" json:"type_name,omitempty"`
PriorState *DynamicValue `protobuf:"bytes,2,opt,name=prior_state,json=priorState,proto3" json:"prior_state,omitempty"`
ProposedNewState *DynamicValue `protobuf:"bytes,3,opt,name=proposed_new_state,json=proposedNewState,proto3" json:"proposed_new_state,omitempty"`
Config *DynamicValue `protobuf:"bytes,4,opt,name=config,proto3" json:"config,omitempty"`
PriorPrivate []byte `protobuf:"bytes,5,opt,name=prior_private,json=priorPrivate,proto3" json:"prior_private,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *PlanResourceChange_Request) Reset() { *m = PlanResourceChange_Request{} }
func (m *PlanResourceChange_Request) String() string { return proto.CompactTextString(m) }
func (*PlanResourceChange_Request) ProtoMessage() {}
func (*PlanResourceChange_Request) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{13, 0}
}
func (m *PlanResourceChange_Request) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_PlanResourceChange_Request.Unmarshal(m, b)
}
func (m *PlanResourceChange_Request) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_PlanResourceChange_Request.Marshal(b, m, deterministic)
}
func (dst *PlanResourceChange_Request) XXX_Merge(src proto.Message) {
xxx_messageInfo_PlanResourceChange_Request.Merge(dst, src)
}
func (m *PlanResourceChange_Request) XXX_Size() int {
return xxx_messageInfo_PlanResourceChange_Request.Size(m)
}
func (m *PlanResourceChange_Request) XXX_DiscardUnknown() {
xxx_messageInfo_PlanResourceChange_Request.DiscardUnknown(m)
}
var xxx_messageInfo_PlanResourceChange_Request proto.InternalMessageInfo
func (m *PlanResourceChange_Request) GetTypeName() string {
if m != nil {
return m.TypeName
}
return ""
}
func (m *PlanResourceChange_Request) GetPriorState() *DynamicValue {
if m != nil {
return m.PriorState
}
return nil
}
func (m *PlanResourceChange_Request) GetProposedNewState() *DynamicValue {
if m != nil {
return m.ProposedNewState
}
return nil
}
func (m *PlanResourceChange_Request) GetConfig() *DynamicValue {
if m != nil {
return m.Config
}
return nil
}
func (m *PlanResourceChange_Request) GetPriorPrivate() []byte {
if m != nil {
return m.PriorPrivate
}
return nil
}
type PlanResourceChange_Response struct {
PlannedState *DynamicValue `protobuf:"bytes,1,opt,name=planned_state,json=plannedState,proto3" json:"planned_state,omitempty"`
RequiresReplace []*AttributePath `protobuf:"bytes,2,rep,name=requires_replace,json=requiresReplace,proto3" json:"requires_replace,omitempty"`
PlannedPrivate []byte `protobuf:"bytes,3,opt,name=planned_private,json=plannedPrivate,proto3" json:"planned_private,omitempty"`
Diagnostics []*Diagnostic `protobuf:"bytes,4,rep,name=diagnostics,proto3" json:"diagnostics,omitempty"`
// This may be set only by the helper/schema "SDK" in the main Terraform
// repository, to request that Terraform Core >=0.12 permit additional
// inconsistencies that can result from the legacy SDK type system
// and its imprecise mapping to the >=0.12 type system.
// The change in behavior implied by this flag makes sense only for the
// specific details of the legacy SDK type system, and are not a general
// mechanism to avoid proper type handling in providers.
//
// ==== DO NOT USE THIS ====
// ==== THIS MUST BE LEFT UNSET IN ALL OTHER SDKS ====
// ==== DO NOT USE THIS ====
LegacyTypeSystem bool `protobuf:"varint,5,opt,name=legacy_type_system,json=legacyTypeSystem,proto3" json:"legacy_type_system,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *PlanResourceChange_Response) Reset() { *m = PlanResourceChange_Response{} }
func (m *PlanResourceChange_Response) String() string { return proto.CompactTextString(m) }
func (*PlanResourceChange_Response) ProtoMessage() {}
func (*PlanResourceChange_Response) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{13, 1}
}
func (m *PlanResourceChange_Response) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_PlanResourceChange_Response.Unmarshal(m, b)
}
func (m *PlanResourceChange_Response) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_PlanResourceChange_Response.Marshal(b, m, deterministic)
}
func (dst *PlanResourceChange_Response) XXX_Merge(src proto.Message) {
xxx_messageInfo_PlanResourceChange_Response.Merge(dst, src)
}
func (m *PlanResourceChange_Response) XXX_Size() int {
return xxx_messageInfo_PlanResourceChange_Response.Size(m)
}
func (m *PlanResourceChange_Response) XXX_DiscardUnknown() {
xxx_messageInfo_PlanResourceChange_Response.DiscardUnknown(m)
}
var xxx_messageInfo_PlanResourceChange_Response proto.InternalMessageInfo
func (m *PlanResourceChange_Response) GetPlannedState() *DynamicValue {
if m != nil {
return m.PlannedState
}
return nil
}
func (m *PlanResourceChange_Response) GetRequiresReplace() []*AttributePath {
if m != nil {
return m.RequiresReplace
}
return nil
}
func (m *PlanResourceChange_Response) GetPlannedPrivate() []byte {
if m != nil {
return m.PlannedPrivate
}
return nil
}
func (m *PlanResourceChange_Response) GetDiagnostics() []*Diagnostic {
if m != nil {
return m.Diagnostics
}
return nil
}
func (m *PlanResourceChange_Response) GetLegacyTypeSystem() bool {
if m != nil {
return m.LegacyTypeSystem
}
return false
}
type ApplyResourceChange struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ApplyResourceChange) Reset() { *m = ApplyResourceChange{} }
func (m *ApplyResourceChange) String() string { return proto.CompactTextString(m) }
func (*ApplyResourceChange) ProtoMessage() {}
func (*ApplyResourceChange) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{14}
}
func (m *ApplyResourceChange) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ApplyResourceChange.Unmarshal(m, b)
}
func (m *ApplyResourceChange) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ApplyResourceChange.Marshal(b, m, deterministic)
}
func (dst *ApplyResourceChange) XXX_Merge(src proto.Message) {
xxx_messageInfo_ApplyResourceChange.Merge(dst, src)
}
func (m *ApplyResourceChange) XXX_Size() int {
return xxx_messageInfo_ApplyResourceChange.Size(m)
}
func (m *ApplyResourceChange) XXX_DiscardUnknown() {
xxx_messageInfo_ApplyResourceChange.DiscardUnknown(m)
}
var xxx_messageInfo_ApplyResourceChange proto.InternalMessageInfo
type ApplyResourceChange_Request struct {
TypeName string `protobuf:"bytes,1,opt,name=type_name,json=typeName,proto3" json:"type_name,omitempty"`
PriorState *DynamicValue `protobuf:"bytes,2,opt,name=prior_state,json=priorState,proto3" json:"prior_state,omitempty"`
PlannedState *DynamicValue `protobuf:"bytes,3,opt,name=planned_state,json=plannedState,proto3" json:"planned_state,omitempty"`
Config *DynamicValue `protobuf:"bytes,4,opt,name=config,proto3" json:"config,omitempty"`
PlannedPrivate []byte `protobuf:"bytes,5,opt,name=planned_private,json=plannedPrivate,proto3" json:"planned_private,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ApplyResourceChange_Request) Reset() { *m = ApplyResourceChange_Request{} }
func (m *ApplyResourceChange_Request) String() string { return proto.CompactTextString(m) }
func (*ApplyResourceChange_Request) ProtoMessage() {}
func (*ApplyResourceChange_Request) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{14, 0}
}
func (m *ApplyResourceChange_Request) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ApplyResourceChange_Request.Unmarshal(m, b)
}
func (m *ApplyResourceChange_Request) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ApplyResourceChange_Request.Marshal(b, m, deterministic)
}
func (dst *ApplyResourceChange_Request) XXX_Merge(src proto.Message) {
xxx_messageInfo_ApplyResourceChange_Request.Merge(dst, src)
}
func (m *ApplyResourceChange_Request) XXX_Size() int {
return xxx_messageInfo_ApplyResourceChange_Request.Size(m)
}
func (m *ApplyResourceChange_Request) XXX_DiscardUnknown() {
xxx_messageInfo_ApplyResourceChange_Request.DiscardUnknown(m)
}
var xxx_messageInfo_ApplyResourceChange_Request proto.InternalMessageInfo
func (m *ApplyResourceChange_Request) GetTypeName() string {
if m != nil {
return m.TypeName
}
return ""
}
func (m *ApplyResourceChange_Request) GetPriorState() *DynamicValue {
if m != nil {
return m.PriorState
}
return nil
}
func (m *ApplyResourceChange_Request) GetPlannedState() *DynamicValue {
if m != nil {
return m.PlannedState
}
return nil
}
func (m *ApplyResourceChange_Request) GetConfig() *DynamicValue {
if m != nil {
return m.Config
}
return nil
}
func (m *ApplyResourceChange_Request) GetPlannedPrivate() []byte {
if m != nil {
return m.PlannedPrivate
}
return nil
}
type ApplyResourceChange_Response struct {
NewState *DynamicValue `protobuf:"bytes,1,opt,name=new_state,json=newState,proto3" json:"new_state,omitempty"`
Private []byte `protobuf:"bytes,2,opt,name=private,proto3" json:"private,omitempty"`
Diagnostics []*Diagnostic `protobuf:"bytes,3,rep,name=diagnostics,proto3" json:"diagnostics,omitempty"`
// This may be set only by the helper/schema "SDK" in the main Terraform
// repository, to request that Terraform Core >=0.12 permit additional
// inconsistencies that can result from the legacy SDK type system
// and its imprecise mapping to the >=0.12 type system.
// The change in behavior implied by this flag makes sense only for the
// specific details of the legacy SDK type system, and are not a general
// mechanism to avoid proper type handling in providers.
//
// ==== DO NOT USE THIS ====
// ==== THIS MUST BE LEFT UNSET IN ALL OTHER SDKS ====
// ==== DO NOT USE THIS ====
LegacyTypeSystem bool `protobuf:"varint,4,opt,name=legacy_type_system,json=legacyTypeSystem,proto3" json:"legacy_type_system,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ApplyResourceChange_Response) Reset() { *m = ApplyResourceChange_Response{} }
func (m *ApplyResourceChange_Response) String() string { return proto.CompactTextString(m) }
func (*ApplyResourceChange_Response) ProtoMessage() {}
func (*ApplyResourceChange_Response) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{14, 1}
}
func (m *ApplyResourceChange_Response) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ApplyResourceChange_Response.Unmarshal(m, b)
}
func (m *ApplyResourceChange_Response) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ApplyResourceChange_Response.Marshal(b, m, deterministic)
}
func (dst *ApplyResourceChange_Response) XXX_Merge(src proto.Message) {
xxx_messageInfo_ApplyResourceChange_Response.Merge(dst, src)
}
func (m *ApplyResourceChange_Response) XXX_Size() int {
return xxx_messageInfo_ApplyResourceChange_Response.Size(m)
}
func (m *ApplyResourceChange_Response) XXX_DiscardUnknown() {
xxx_messageInfo_ApplyResourceChange_Response.DiscardUnknown(m)
}
var xxx_messageInfo_ApplyResourceChange_Response proto.InternalMessageInfo
func (m *ApplyResourceChange_Response) GetNewState() *DynamicValue {
if m != nil {
return m.NewState
}
return nil
}
func (m *ApplyResourceChange_Response) GetPrivate() []byte {
if m != nil {
return m.Private
}
return nil
}
func (m *ApplyResourceChange_Response) GetDiagnostics() []*Diagnostic {
if m != nil {
return m.Diagnostics
}
return nil
}
func (m *ApplyResourceChange_Response) GetLegacyTypeSystem() bool {
if m != nil {
return m.LegacyTypeSystem
}
return false
}
type ImportResourceState struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ImportResourceState) Reset() { *m = ImportResourceState{} }
func (m *ImportResourceState) String() string { return proto.CompactTextString(m) }
func (*ImportResourceState) ProtoMessage() {}
func (*ImportResourceState) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{15}
}
func (m *ImportResourceState) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ImportResourceState.Unmarshal(m, b)
}
func (m *ImportResourceState) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ImportResourceState.Marshal(b, m, deterministic)
}
func (dst *ImportResourceState) XXX_Merge(src proto.Message) {
xxx_messageInfo_ImportResourceState.Merge(dst, src)
}
func (m *ImportResourceState) XXX_Size() int {
return xxx_messageInfo_ImportResourceState.Size(m)
}
func (m *ImportResourceState) XXX_DiscardUnknown() {
xxx_messageInfo_ImportResourceState.DiscardUnknown(m)
}
var xxx_messageInfo_ImportResourceState proto.InternalMessageInfo
type ImportResourceState_Request struct {
TypeName string `protobuf:"bytes,1,opt,name=type_name,json=typeName,proto3" json:"type_name,omitempty"`
Id string `protobuf:"bytes,2,opt,name=id,proto3" json:"id,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ImportResourceState_Request) Reset() { *m = ImportResourceState_Request{} }
func (m *ImportResourceState_Request) String() string { return proto.CompactTextString(m) }
func (*ImportResourceState_Request) ProtoMessage() {}
func (*ImportResourceState_Request) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{15, 0}
}
func (m *ImportResourceState_Request) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ImportResourceState_Request.Unmarshal(m, b)
}
func (m *ImportResourceState_Request) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ImportResourceState_Request.Marshal(b, m, deterministic)
}
func (dst *ImportResourceState_Request) XXX_Merge(src proto.Message) {
xxx_messageInfo_ImportResourceState_Request.Merge(dst, src)
}
func (m *ImportResourceState_Request) XXX_Size() int {
return xxx_messageInfo_ImportResourceState_Request.Size(m)
}
func (m *ImportResourceState_Request) XXX_DiscardUnknown() {
xxx_messageInfo_ImportResourceState_Request.DiscardUnknown(m)
}
var xxx_messageInfo_ImportResourceState_Request proto.InternalMessageInfo
func (m *ImportResourceState_Request) GetTypeName() string {
if m != nil {
return m.TypeName
}
return ""
}
func (m *ImportResourceState_Request) GetId() string {
if m != nil {
return m.Id
}
return ""
}
type ImportResourceState_ImportedResource struct {
TypeName string `protobuf:"bytes,1,opt,name=type_name,json=typeName,proto3" json:"type_name,omitempty"`
State *DynamicValue `protobuf:"bytes,2,opt,name=state,proto3" json:"state,omitempty"`
Private []byte `protobuf:"bytes,3,opt,name=private,proto3" json:"private,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ImportResourceState_ImportedResource) Reset() { *m = ImportResourceState_ImportedResource{} }
func (m *ImportResourceState_ImportedResource) String() string { return proto.CompactTextString(m) }
func (*ImportResourceState_ImportedResource) ProtoMessage() {}
func (*ImportResourceState_ImportedResource) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{15, 1}
}
func (m *ImportResourceState_ImportedResource) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ImportResourceState_ImportedResource.Unmarshal(m, b)
}
func (m *ImportResourceState_ImportedResource) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ImportResourceState_ImportedResource.Marshal(b, m, deterministic)
}
func (dst *ImportResourceState_ImportedResource) XXX_Merge(src proto.Message) {
xxx_messageInfo_ImportResourceState_ImportedResource.Merge(dst, src)
}
func (m *ImportResourceState_ImportedResource) XXX_Size() int {
return xxx_messageInfo_ImportResourceState_ImportedResource.Size(m)
}
func (m *ImportResourceState_ImportedResource) XXX_DiscardUnknown() {
xxx_messageInfo_ImportResourceState_ImportedResource.DiscardUnknown(m)
}
var xxx_messageInfo_ImportResourceState_ImportedResource proto.InternalMessageInfo
func (m *ImportResourceState_ImportedResource) GetTypeName() string {
if m != nil {
return m.TypeName
}
return ""
}
func (m *ImportResourceState_ImportedResource) GetState() *DynamicValue {
if m != nil {
return m.State
}
return nil
}
func (m *ImportResourceState_ImportedResource) GetPrivate() []byte {
if m != nil {
return m.Private
}
return nil
}
type ImportResourceState_Response struct {
ImportedResources []*ImportResourceState_ImportedResource `protobuf:"bytes,1,rep,name=imported_resources,json=importedResources,proto3" json:"imported_resources,omitempty"`
Diagnostics []*Diagnostic `protobuf:"bytes,2,rep,name=diagnostics,proto3" json:"diagnostics,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ImportResourceState_Response) Reset() { *m = ImportResourceState_Response{} }
func (m *ImportResourceState_Response) String() string { return proto.CompactTextString(m) }
func (*ImportResourceState_Response) ProtoMessage() {}
func (*ImportResourceState_Response) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{15, 2}
}
func (m *ImportResourceState_Response) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ImportResourceState_Response.Unmarshal(m, b)
}
func (m *ImportResourceState_Response) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ImportResourceState_Response.Marshal(b, m, deterministic)
}
func (dst *ImportResourceState_Response) XXX_Merge(src proto.Message) {
xxx_messageInfo_ImportResourceState_Response.Merge(dst, src)
}
func (m *ImportResourceState_Response) XXX_Size() int {
return xxx_messageInfo_ImportResourceState_Response.Size(m)
}
func (m *ImportResourceState_Response) XXX_DiscardUnknown() {
xxx_messageInfo_ImportResourceState_Response.DiscardUnknown(m)
}
var xxx_messageInfo_ImportResourceState_Response proto.InternalMessageInfo
func (m *ImportResourceState_Response) GetImportedResources() []*ImportResourceState_ImportedResource {
if m != nil {
return m.ImportedResources
}
return nil
}
func (m *ImportResourceState_Response) GetDiagnostics() []*Diagnostic {
if m != nil {
return m.Diagnostics
}
return nil
}
type ReadDataSource struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ReadDataSource) Reset() { *m = ReadDataSource{} }
func (m *ReadDataSource) String() string { return proto.CompactTextString(m) }
func (*ReadDataSource) ProtoMessage() {}
func (*ReadDataSource) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{16}
}
func (m *ReadDataSource) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ReadDataSource.Unmarshal(m, b)
}
func (m *ReadDataSource) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ReadDataSource.Marshal(b, m, deterministic)
}
func (dst *ReadDataSource) XXX_Merge(src proto.Message) {
xxx_messageInfo_ReadDataSource.Merge(dst, src)
}
func (m *ReadDataSource) XXX_Size() int {
return xxx_messageInfo_ReadDataSource.Size(m)
}
func (m *ReadDataSource) XXX_DiscardUnknown() {
xxx_messageInfo_ReadDataSource.DiscardUnknown(m)
}
var xxx_messageInfo_ReadDataSource proto.InternalMessageInfo
type ReadDataSource_Request struct {
TypeName string `protobuf:"bytes,1,opt,name=type_name,json=typeName,proto3" json:"type_name,omitempty"`
Config *DynamicValue `protobuf:"bytes,2,opt,name=config,proto3" json:"config,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ReadDataSource_Request) Reset() { *m = ReadDataSource_Request{} }
func (m *ReadDataSource_Request) String() string { return proto.CompactTextString(m) }
func (*ReadDataSource_Request) ProtoMessage() {}
func (*ReadDataSource_Request) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{16, 0}
}
func (m *ReadDataSource_Request) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ReadDataSource_Request.Unmarshal(m, b)
}
func (m *ReadDataSource_Request) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ReadDataSource_Request.Marshal(b, m, deterministic)
}
func (dst *ReadDataSource_Request) XXX_Merge(src proto.Message) {
xxx_messageInfo_ReadDataSource_Request.Merge(dst, src)
}
func (m *ReadDataSource_Request) XXX_Size() int {
return xxx_messageInfo_ReadDataSource_Request.Size(m)
}
func (m *ReadDataSource_Request) XXX_DiscardUnknown() {
xxx_messageInfo_ReadDataSource_Request.DiscardUnknown(m)
}
var xxx_messageInfo_ReadDataSource_Request proto.InternalMessageInfo
func (m *ReadDataSource_Request) GetTypeName() string {
if m != nil {
return m.TypeName
}
return ""
}
func (m *ReadDataSource_Request) GetConfig() *DynamicValue {
if m != nil {
return m.Config
}
return nil
}
type ReadDataSource_Response struct {
State *DynamicValue `protobuf:"bytes,1,opt,name=state,proto3" json:"state,omitempty"`
Diagnostics []*Diagnostic `protobuf:"bytes,2,rep,name=diagnostics,proto3" json:"diagnostics,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ReadDataSource_Response) Reset() { *m = ReadDataSource_Response{} }
func (m *ReadDataSource_Response) String() string { return proto.CompactTextString(m) }
func (*ReadDataSource_Response) ProtoMessage() {}
func (*ReadDataSource_Response) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{16, 1}
}
func (m *ReadDataSource_Response) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ReadDataSource_Response.Unmarshal(m, b)
}
func (m *ReadDataSource_Response) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ReadDataSource_Response.Marshal(b, m, deterministic)
}
func (dst *ReadDataSource_Response) XXX_Merge(src proto.Message) {
xxx_messageInfo_ReadDataSource_Response.Merge(dst, src)
}
func (m *ReadDataSource_Response) XXX_Size() int {
return xxx_messageInfo_ReadDataSource_Response.Size(m)
}
func (m *ReadDataSource_Response) XXX_DiscardUnknown() {
xxx_messageInfo_ReadDataSource_Response.DiscardUnknown(m)
}
var xxx_messageInfo_ReadDataSource_Response proto.InternalMessageInfo
func (m *ReadDataSource_Response) GetState() *DynamicValue {
if m != nil {
return m.State
}
return nil
}
func (m *ReadDataSource_Response) GetDiagnostics() []*Diagnostic {
if m != nil {
return m.Diagnostics
}
return nil
}
type GetProvisionerSchema struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *GetProvisionerSchema) Reset() { *m = GetProvisionerSchema{} }
func (m *GetProvisionerSchema) String() string { return proto.CompactTextString(m) }
func (*GetProvisionerSchema) ProtoMessage() {}
func (*GetProvisionerSchema) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{17}
}
func (m *GetProvisionerSchema) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_GetProvisionerSchema.Unmarshal(m, b)
}
func (m *GetProvisionerSchema) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_GetProvisionerSchema.Marshal(b, m, deterministic)
}
func (dst *GetProvisionerSchema) XXX_Merge(src proto.Message) {
xxx_messageInfo_GetProvisionerSchema.Merge(dst, src)
}
func (m *GetProvisionerSchema) XXX_Size() int {
return xxx_messageInfo_GetProvisionerSchema.Size(m)
}
func (m *GetProvisionerSchema) XXX_DiscardUnknown() {
xxx_messageInfo_GetProvisionerSchema.DiscardUnknown(m)
}
var xxx_messageInfo_GetProvisionerSchema proto.InternalMessageInfo
type GetProvisionerSchema_Request struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *GetProvisionerSchema_Request) Reset() { *m = GetProvisionerSchema_Request{} }
func (m *GetProvisionerSchema_Request) String() string { return proto.CompactTextString(m) }
func (*GetProvisionerSchema_Request) ProtoMessage() {}
func (*GetProvisionerSchema_Request) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{17, 0}
}
func (m *GetProvisionerSchema_Request) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_GetProvisionerSchema_Request.Unmarshal(m, b)
}
func (m *GetProvisionerSchema_Request) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_GetProvisionerSchema_Request.Marshal(b, m, deterministic)
}
func (dst *GetProvisionerSchema_Request) XXX_Merge(src proto.Message) {
xxx_messageInfo_GetProvisionerSchema_Request.Merge(dst, src)
}
func (m *GetProvisionerSchema_Request) XXX_Size() int {
return xxx_messageInfo_GetProvisionerSchema_Request.Size(m)
}
func (m *GetProvisionerSchema_Request) XXX_DiscardUnknown() {
xxx_messageInfo_GetProvisionerSchema_Request.DiscardUnknown(m)
}
var xxx_messageInfo_GetProvisionerSchema_Request proto.InternalMessageInfo
type GetProvisionerSchema_Response struct {
Provisioner *Schema `protobuf:"bytes,1,opt,name=provisioner,proto3" json:"provisioner,omitempty"`
Diagnostics []*Diagnostic `protobuf:"bytes,2,rep,name=diagnostics,proto3" json:"diagnostics,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *GetProvisionerSchema_Response) Reset() { *m = GetProvisionerSchema_Response{} }
func (m *GetProvisionerSchema_Response) String() string { return proto.CompactTextString(m) }
func (*GetProvisionerSchema_Response) ProtoMessage() {}
func (*GetProvisionerSchema_Response) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{17, 1}
}
func (m *GetProvisionerSchema_Response) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_GetProvisionerSchema_Response.Unmarshal(m, b)
}
func (m *GetProvisionerSchema_Response) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_GetProvisionerSchema_Response.Marshal(b, m, deterministic)
}
func (dst *GetProvisionerSchema_Response) XXX_Merge(src proto.Message) {
xxx_messageInfo_GetProvisionerSchema_Response.Merge(dst, src)
}
func (m *GetProvisionerSchema_Response) XXX_Size() int {
return xxx_messageInfo_GetProvisionerSchema_Response.Size(m)
}
func (m *GetProvisionerSchema_Response) XXX_DiscardUnknown() {
xxx_messageInfo_GetProvisionerSchema_Response.DiscardUnknown(m)
}
var xxx_messageInfo_GetProvisionerSchema_Response proto.InternalMessageInfo
func (m *GetProvisionerSchema_Response) GetProvisioner() *Schema {
if m != nil {
return m.Provisioner
}
return nil
}
func (m *GetProvisionerSchema_Response) GetDiagnostics() []*Diagnostic {
if m != nil {
return m.Diagnostics
}
return nil
}
type ValidateProvisionerConfig struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ValidateProvisionerConfig) Reset() { *m = ValidateProvisionerConfig{} }
func (m *ValidateProvisionerConfig) String() string { return proto.CompactTextString(m) }
func (*ValidateProvisionerConfig) ProtoMessage() {}
func (*ValidateProvisionerConfig) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{18}
}
func (m *ValidateProvisionerConfig) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ValidateProvisionerConfig.Unmarshal(m, b)
}
func (m *ValidateProvisionerConfig) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ValidateProvisionerConfig.Marshal(b, m, deterministic)
}
func (dst *ValidateProvisionerConfig) XXX_Merge(src proto.Message) {
xxx_messageInfo_ValidateProvisionerConfig.Merge(dst, src)
}
func (m *ValidateProvisionerConfig) XXX_Size() int {
return xxx_messageInfo_ValidateProvisionerConfig.Size(m)
}
func (m *ValidateProvisionerConfig) XXX_DiscardUnknown() {
xxx_messageInfo_ValidateProvisionerConfig.DiscardUnknown(m)
}
var xxx_messageInfo_ValidateProvisionerConfig proto.InternalMessageInfo
type ValidateProvisionerConfig_Request struct {
Config *DynamicValue `protobuf:"bytes,1,opt,name=config,proto3" json:"config,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ValidateProvisionerConfig_Request) Reset() { *m = ValidateProvisionerConfig_Request{} }
func (m *ValidateProvisionerConfig_Request) String() string { return proto.CompactTextString(m) }
func (*ValidateProvisionerConfig_Request) ProtoMessage() {}
func (*ValidateProvisionerConfig_Request) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{18, 0}
}
func (m *ValidateProvisionerConfig_Request) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ValidateProvisionerConfig_Request.Unmarshal(m, b)
}
func (m *ValidateProvisionerConfig_Request) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ValidateProvisionerConfig_Request.Marshal(b, m, deterministic)
}
func (dst *ValidateProvisionerConfig_Request) XXX_Merge(src proto.Message) {
xxx_messageInfo_ValidateProvisionerConfig_Request.Merge(dst, src)
}
func (m *ValidateProvisionerConfig_Request) XXX_Size() int {
return xxx_messageInfo_ValidateProvisionerConfig_Request.Size(m)
}
func (m *ValidateProvisionerConfig_Request) XXX_DiscardUnknown() {
xxx_messageInfo_ValidateProvisionerConfig_Request.DiscardUnknown(m)
}
var xxx_messageInfo_ValidateProvisionerConfig_Request proto.InternalMessageInfo
func (m *ValidateProvisionerConfig_Request) GetConfig() *DynamicValue {
if m != nil {
return m.Config
}
return nil
}
type ValidateProvisionerConfig_Response struct {
Diagnostics []*Diagnostic `protobuf:"bytes,1,rep,name=diagnostics,proto3" json:"diagnostics,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ValidateProvisionerConfig_Response) Reset() { *m = ValidateProvisionerConfig_Response{} }
func (m *ValidateProvisionerConfig_Response) String() string { return proto.CompactTextString(m) }
func (*ValidateProvisionerConfig_Response) ProtoMessage() {}
func (*ValidateProvisionerConfig_Response) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{18, 1}
}
func (m *ValidateProvisionerConfig_Response) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ValidateProvisionerConfig_Response.Unmarshal(m, b)
}
func (m *ValidateProvisionerConfig_Response) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ValidateProvisionerConfig_Response.Marshal(b, m, deterministic)
}
func (dst *ValidateProvisionerConfig_Response) XXX_Merge(src proto.Message) {
xxx_messageInfo_ValidateProvisionerConfig_Response.Merge(dst, src)
}
func (m *ValidateProvisionerConfig_Response) XXX_Size() int {
return xxx_messageInfo_ValidateProvisionerConfig_Response.Size(m)
}
func (m *ValidateProvisionerConfig_Response) XXX_DiscardUnknown() {
xxx_messageInfo_ValidateProvisionerConfig_Response.DiscardUnknown(m)
}
var xxx_messageInfo_ValidateProvisionerConfig_Response proto.InternalMessageInfo
func (m *ValidateProvisionerConfig_Response) GetDiagnostics() []*Diagnostic {
if m != nil {
return m.Diagnostics
}
return nil
}
type ProvisionResource struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ProvisionResource) Reset() { *m = ProvisionResource{} }
func (m *ProvisionResource) String() string { return proto.CompactTextString(m) }
func (*ProvisionResource) ProtoMessage() {}
func (*ProvisionResource) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{19}
}
func (m *ProvisionResource) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ProvisionResource.Unmarshal(m, b)
}
func (m *ProvisionResource) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ProvisionResource.Marshal(b, m, deterministic)
}
func (dst *ProvisionResource) XXX_Merge(src proto.Message) {
xxx_messageInfo_ProvisionResource.Merge(dst, src)
}
func (m *ProvisionResource) XXX_Size() int {
return xxx_messageInfo_ProvisionResource.Size(m)
}
func (m *ProvisionResource) XXX_DiscardUnknown() {
xxx_messageInfo_ProvisionResource.DiscardUnknown(m)
}
var xxx_messageInfo_ProvisionResource proto.InternalMessageInfo
type ProvisionResource_Request struct {
Config *DynamicValue `protobuf:"bytes,1,opt,name=config,proto3" json:"config,omitempty"`
Connection *DynamicValue `protobuf:"bytes,2,opt,name=connection,proto3" json:"connection,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ProvisionResource_Request) Reset() { *m = ProvisionResource_Request{} }
func (m *ProvisionResource_Request) String() string { return proto.CompactTextString(m) }
func (*ProvisionResource_Request) ProtoMessage() {}
func (*ProvisionResource_Request) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{19, 0}
}
func (m *ProvisionResource_Request) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ProvisionResource_Request.Unmarshal(m, b)
}
func (m *ProvisionResource_Request) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ProvisionResource_Request.Marshal(b, m, deterministic)
}
func (dst *ProvisionResource_Request) XXX_Merge(src proto.Message) {
xxx_messageInfo_ProvisionResource_Request.Merge(dst, src)
}
func (m *ProvisionResource_Request) XXX_Size() int {
return xxx_messageInfo_ProvisionResource_Request.Size(m)
}
func (m *ProvisionResource_Request) XXX_DiscardUnknown() {
xxx_messageInfo_ProvisionResource_Request.DiscardUnknown(m)
}
var xxx_messageInfo_ProvisionResource_Request proto.InternalMessageInfo
func (m *ProvisionResource_Request) GetConfig() *DynamicValue {
if m != nil {
return m.Config
}
return nil
}
func (m *ProvisionResource_Request) GetConnection() *DynamicValue {
if m != nil {
return m.Connection
}
return nil
}
type ProvisionResource_Response struct {
Output string `protobuf:"bytes,1,opt,name=output,proto3" json:"output,omitempty"`
Diagnostics []*Diagnostic `protobuf:"bytes,2,rep,name=diagnostics,proto3" json:"diagnostics,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *ProvisionResource_Response) Reset() { *m = ProvisionResource_Response{} }
func (m *ProvisionResource_Response) String() string { return proto.CompactTextString(m) }
func (*ProvisionResource_Response) ProtoMessage() {}
func (*ProvisionResource_Response) Descriptor() ([]byte, []int) {
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
return fileDescriptor_tfplugin5_56820f4fb67360c5, []int{19, 1}
}
func (m *ProvisionResource_Response) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_ProvisionResource_Response.Unmarshal(m, b)
}
func (m *ProvisionResource_Response) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_ProvisionResource_Response.Marshal(b, m, deterministic)
}
func (dst *ProvisionResource_Response) XXX_Merge(src proto.Message) {
xxx_messageInfo_ProvisionResource_Response.Merge(dst, src)
}
func (m *ProvisionResource_Response) XXX_Size() int {
return xxx_messageInfo_ProvisionResource_Response.Size(m)
}
func (m *ProvisionResource_Response) XXX_DiscardUnknown() {
xxx_messageInfo_ProvisionResource_Response.DiscardUnknown(m)
}
var xxx_messageInfo_ProvisionResource_Response proto.InternalMessageInfo
func (m *ProvisionResource_Response) GetOutput() string {
if m != nil {
return m.Output
}
return ""
}
func (m *ProvisionResource_Response) GetDiagnostics() []*Diagnostic {
if m != nil {
return m.Diagnostics
}
return nil
}
func init() {
proto.RegisterType((*DynamicValue)(nil), "tfplugin5.DynamicValue")
proto.RegisterType((*Diagnostic)(nil), "tfplugin5.Diagnostic")
proto.RegisterType((*AttributePath)(nil), "tfplugin5.AttributePath")
proto.RegisterType((*AttributePath_Step)(nil), "tfplugin5.AttributePath.Step")
proto.RegisterType((*Stop)(nil), "tfplugin5.Stop")
proto.RegisterType((*Stop_Request)(nil), "tfplugin5.Stop.Request")
proto.RegisterType((*Stop_Response)(nil), "tfplugin5.Stop.Response")
proto.RegisterType((*RawState)(nil), "tfplugin5.RawState")
proto.RegisterMapType((map[string]string)(nil), "tfplugin5.RawState.FlatmapEntry")
proto.RegisterType((*Schema)(nil), "tfplugin5.Schema")
proto.RegisterType((*Schema_Block)(nil), "tfplugin5.Schema.Block")
proto.RegisterType((*Schema_Attribute)(nil), "tfplugin5.Schema.Attribute")
proto.RegisterType((*Schema_NestedBlock)(nil), "tfplugin5.Schema.NestedBlock")
proto.RegisterType((*GetProviderSchema)(nil), "tfplugin5.GetProviderSchema")
proto.RegisterType((*GetProviderSchema_Request)(nil), "tfplugin5.GetProviderSchema.Request")
proto.RegisterType((*GetProviderSchema_Response)(nil), "tfplugin5.GetProviderSchema.Response")
proto.RegisterMapType((map[string]*Schema)(nil), "tfplugin5.GetProviderSchema.Response.DataSourceSchemasEntry")
proto.RegisterMapType((map[string]*Schema)(nil), "tfplugin5.GetProviderSchema.Response.ResourceSchemasEntry")
proto.RegisterType((*PrepareProviderConfig)(nil), "tfplugin5.PrepareProviderConfig")
proto.RegisterType((*PrepareProviderConfig_Request)(nil), "tfplugin5.PrepareProviderConfig.Request")
proto.RegisterType((*PrepareProviderConfig_Response)(nil), "tfplugin5.PrepareProviderConfig.Response")
proto.RegisterType((*UpgradeResourceState)(nil), "tfplugin5.UpgradeResourceState")
proto.RegisterType((*UpgradeResourceState_Request)(nil), "tfplugin5.UpgradeResourceState.Request")
proto.RegisterType((*UpgradeResourceState_Response)(nil), "tfplugin5.UpgradeResourceState.Response")
proto.RegisterType((*ValidateResourceTypeConfig)(nil), "tfplugin5.ValidateResourceTypeConfig")
proto.RegisterType((*ValidateResourceTypeConfig_Request)(nil), "tfplugin5.ValidateResourceTypeConfig.Request")
proto.RegisterType((*ValidateResourceTypeConfig_Response)(nil), "tfplugin5.ValidateResourceTypeConfig.Response")
proto.RegisterType((*ValidateDataSourceConfig)(nil), "tfplugin5.ValidateDataSourceConfig")
proto.RegisterType((*ValidateDataSourceConfig_Request)(nil), "tfplugin5.ValidateDataSourceConfig.Request")
proto.RegisterType((*ValidateDataSourceConfig_Response)(nil), "tfplugin5.ValidateDataSourceConfig.Response")
proto.RegisterType((*Configure)(nil), "tfplugin5.Configure")
proto.RegisterType((*Configure_Request)(nil), "tfplugin5.Configure.Request")
proto.RegisterType((*Configure_Response)(nil), "tfplugin5.Configure.Response")
proto.RegisterType((*ReadResource)(nil), "tfplugin5.ReadResource")
proto.RegisterType((*ReadResource_Request)(nil), "tfplugin5.ReadResource.Request")
proto.RegisterType((*ReadResource_Response)(nil), "tfplugin5.ReadResource.Response")
proto.RegisterType((*PlanResourceChange)(nil), "tfplugin5.PlanResourceChange")
proto.RegisterType((*PlanResourceChange_Request)(nil), "tfplugin5.PlanResourceChange.Request")
proto.RegisterType((*PlanResourceChange_Response)(nil), "tfplugin5.PlanResourceChange.Response")
proto.RegisterType((*ApplyResourceChange)(nil), "tfplugin5.ApplyResourceChange")
proto.RegisterType((*ApplyResourceChange_Request)(nil), "tfplugin5.ApplyResourceChange.Request")
proto.RegisterType((*ApplyResourceChange_Response)(nil), "tfplugin5.ApplyResourceChange.Response")
proto.RegisterType((*ImportResourceState)(nil), "tfplugin5.ImportResourceState")
proto.RegisterType((*ImportResourceState_Request)(nil), "tfplugin5.ImportResourceState.Request")
proto.RegisterType((*ImportResourceState_ImportedResource)(nil), "tfplugin5.ImportResourceState.ImportedResource")
proto.RegisterType((*ImportResourceState_Response)(nil), "tfplugin5.ImportResourceState.Response")
proto.RegisterType((*ReadDataSource)(nil), "tfplugin5.ReadDataSource")
proto.RegisterType((*ReadDataSource_Request)(nil), "tfplugin5.ReadDataSource.Request")
proto.RegisterType((*ReadDataSource_Response)(nil), "tfplugin5.ReadDataSource.Response")
proto.RegisterType((*GetProvisionerSchema)(nil), "tfplugin5.GetProvisionerSchema")
proto.RegisterType((*GetProvisionerSchema_Request)(nil), "tfplugin5.GetProvisionerSchema.Request")
proto.RegisterType((*GetProvisionerSchema_Response)(nil), "tfplugin5.GetProvisionerSchema.Response")
proto.RegisterType((*ValidateProvisionerConfig)(nil), "tfplugin5.ValidateProvisionerConfig")
proto.RegisterType((*ValidateProvisionerConfig_Request)(nil), "tfplugin5.ValidateProvisionerConfig.Request")
proto.RegisterType((*ValidateProvisionerConfig_Response)(nil), "tfplugin5.ValidateProvisionerConfig.Response")
proto.RegisterType((*ProvisionResource)(nil), "tfplugin5.ProvisionResource")
proto.RegisterType((*ProvisionResource_Request)(nil), "tfplugin5.ProvisionResource.Request")
proto.RegisterType((*ProvisionResource_Response)(nil), "tfplugin5.ProvisionResource.Response")
proto.RegisterEnum("tfplugin5.Diagnostic_Severity", Diagnostic_Severity_name, Diagnostic_Severity_value)
proto.RegisterEnum("tfplugin5.Schema_NestedBlock_NestingMode", Schema_NestedBlock_NestingMode_name, Schema_NestedBlock_NestingMode_value)
}
// Reference imports to suppress errors if they are not otherwise used.
var _ context.Context
var _ grpc.ClientConn
// This is a compile-time assertion to ensure that this generated file
// is compatible with the grpc package it is being compiled against.
const _ = grpc.SupportPackageIsVersion4
// ProviderClient is the client API for Provider service.
//
// For semantics around ctx use and closing/ending streaming RPCs, please refer to https://godoc.org/google.golang.org/grpc#ClientConn.NewStream.
type ProviderClient interface {
// ////// Information about what a provider supports/expects
GetSchema(ctx context.Context, in *GetProviderSchema_Request, opts ...grpc.CallOption) (*GetProviderSchema_Response, error)
PrepareProviderConfig(ctx context.Context, in *PrepareProviderConfig_Request, opts ...grpc.CallOption) (*PrepareProviderConfig_Response, error)
ValidateResourceTypeConfig(ctx context.Context, in *ValidateResourceTypeConfig_Request, opts ...grpc.CallOption) (*ValidateResourceTypeConfig_Response, error)
ValidateDataSourceConfig(ctx context.Context, in *ValidateDataSourceConfig_Request, opts ...grpc.CallOption) (*ValidateDataSourceConfig_Response, error)
UpgradeResourceState(ctx context.Context, in *UpgradeResourceState_Request, opts ...grpc.CallOption) (*UpgradeResourceState_Response, error)
// ////// One-time initialization, called before other functions below
Configure(ctx context.Context, in *Configure_Request, opts ...grpc.CallOption) (*Configure_Response, error)
// ////// Managed Resource Lifecycle
ReadResource(ctx context.Context, in *ReadResource_Request, opts ...grpc.CallOption) (*ReadResource_Response, error)
PlanResourceChange(ctx context.Context, in *PlanResourceChange_Request, opts ...grpc.CallOption) (*PlanResourceChange_Response, error)
ApplyResourceChange(ctx context.Context, in *ApplyResourceChange_Request, opts ...grpc.CallOption) (*ApplyResourceChange_Response, error)
ImportResourceState(ctx context.Context, in *ImportResourceState_Request, opts ...grpc.CallOption) (*ImportResourceState_Response, error)
ReadDataSource(ctx context.Context, in *ReadDataSource_Request, opts ...grpc.CallOption) (*ReadDataSource_Response, error)
// ////// Graceful Shutdown
Stop(ctx context.Context, in *Stop_Request, opts ...grpc.CallOption) (*Stop_Response, error)
}
type providerClient struct {
cc *grpc.ClientConn
}
func NewProviderClient(cc *grpc.ClientConn) ProviderClient {
return &providerClient{cc}
}
func (c *providerClient) GetSchema(ctx context.Context, in *GetProviderSchema_Request, opts ...grpc.CallOption) (*GetProviderSchema_Response, error) {
out := new(GetProviderSchema_Response)
err := c.cc.Invoke(ctx, "/tfplugin5.Provider/GetSchema", in, out, opts...)
if err != nil {
return nil, err
}
return out, nil
}
func (c *providerClient) PrepareProviderConfig(ctx context.Context, in *PrepareProviderConfig_Request, opts ...grpc.CallOption) (*PrepareProviderConfig_Response, error) {
out := new(PrepareProviderConfig_Response)
err := c.cc.Invoke(ctx, "/tfplugin5.Provider/PrepareProviderConfig", in, out, opts...)
if err != nil {
return nil, err
}
return out, nil
}
func (c *providerClient) ValidateResourceTypeConfig(ctx context.Context, in *ValidateResourceTypeConfig_Request, opts ...grpc.CallOption) (*ValidateResourceTypeConfig_Response, error) {
out := new(ValidateResourceTypeConfig_Response)
err := c.cc.Invoke(ctx, "/tfplugin5.Provider/ValidateResourceTypeConfig", in, out, opts...)
if err != nil {
return nil, err
}
return out, nil
}
func (c *providerClient) ValidateDataSourceConfig(ctx context.Context, in *ValidateDataSourceConfig_Request, opts ...grpc.CallOption) (*ValidateDataSourceConfig_Response, error) {
out := new(ValidateDataSourceConfig_Response)
err := c.cc.Invoke(ctx, "/tfplugin5.Provider/ValidateDataSourceConfig", in, out, opts...)
if err != nil {
return nil, err
}
return out, nil
}
func (c *providerClient) UpgradeResourceState(ctx context.Context, in *UpgradeResourceState_Request, opts ...grpc.CallOption) (*UpgradeResourceState_Response, error) {
out := new(UpgradeResourceState_Response)
err := c.cc.Invoke(ctx, "/tfplugin5.Provider/UpgradeResourceState", in, out, opts...)
if err != nil {
return nil, err
}
return out, nil
}
func (c *providerClient) Configure(ctx context.Context, in *Configure_Request, opts ...grpc.CallOption) (*Configure_Response, error) {
out := new(Configure_Response)
err := c.cc.Invoke(ctx, "/tfplugin5.Provider/Configure", in, out, opts...)
if err != nil {
return nil, err
}
return out, nil
}
func (c *providerClient) ReadResource(ctx context.Context, in *ReadResource_Request, opts ...grpc.CallOption) (*ReadResource_Response, error) {
out := new(ReadResource_Response)
err := c.cc.Invoke(ctx, "/tfplugin5.Provider/ReadResource", in, out, opts...)
if err != nil {
return nil, err
}
return out, nil
}
func (c *providerClient) PlanResourceChange(ctx context.Context, in *PlanResourceChange_Request, opts ...grpc.CallOption) (*PlanResourceChange_Response, error) {
out := new(PlanResourceChange_Response)
err := c.cc.Invoke(ctx, "/tfplugin5.Provider/PlanResourceChange", in, out, opts...)
if err != nil {
return nil, err
}
return out, nil
}
func (c *providerClient) ApplyResourceChange(ctx context.Context, in *ApplyResourceChange_Request, opts ...grpc.CallOption) (*ApplyResourceChange_Response, error) {
out := new(ApplyResourceChange_Response)
err := c.cc.Invoke(ctx, "/tfplugin5.Provider/ApplyResourceChange", in, out, opts...)
if err != nil {
return nil, err
}
return out, nil
}
func (c *providerClient) ImportResourceState(ctx context.Context, in *ImportResourceState_Request, opts ...grpc.CallOption) (*ImportResourceState_Response, error) {
out := new(ImportResourceState_Response)
err := c.cc.Invoke(ctx, "/tfplugin5.Provider/ImportResourceState", in, out, opts...)
if err != nil {
return nil, err
}
return out, nil
}
func (c *providerClient) ReadDataSource(ctx context.Context, in *ReadDataSource_Request, opts ...grpc.CallOption) (*ReadDataSource_Response, error) {
out := new(ReadDataSource_Response)
err := c.cc.Invoke(ctx, "/tfplugin5.Provider/ReadDataSource", in, out, opts...)
if err != nil {
return nil, err
}
return out, nil
}
func (c *providerClient) Stop(ctx context.Context, in *Stop_Request, opts ...grpc.CallOption) (*Stop_Response, error) {
out := new(Stop_Response)
err := c.cc.Invoke(ctx, "/tfplugin5.Provider/Stop", in, out, opts...)
if err != nil {
return nil, err
}
return out, nil
}
// ProviderServer is the server API for Provider service.
type ProviderServer interface {
// ////// Information about what a provider supports/expects
GetSchema(context.Context, *GetProviderSchema_Request) (*GetProviderSchema_Response, error)
PrepareProviderConfig(context.Context, *PrepareProviderConfig_Request) (*PrepareProviderConfig_Response, error)
ValidateResourceTypeConfig(context.Context, *ValidateResourceTypeConfig_Request) (*ValidateResourceTypeConfig_Response, error)
ValidateDataSourceConfig(context.Context, *ValidateDataSourceConfig_Request) (*ValidateDataSourceConfig_Response, error)
UpgradeResourceState(context.Context, *UpgradeResourceState_Request) (*UpgradeResourceState_Response, error)
// ////// One-time initialization, called before other functions below
Configure(context.Context, *Configure_Request) (*Configure_Response, error)
// ////// Managed Resource Lifecycle
ReadResource(context.Context, *ReadResource_Request) (*ReadResource_Response, error)
PlanResourceChange(context.Context, *PlanResourceChange_Request) (*PlanResourceChange_Response, error)
ApplyResourceChange(context.Context, *ApplyResourceChange_Request) (*ApplyResourceChange_Response, error)
ImportResourceState(context.Context, *ImportResourceState_Request) (*ImportResourceState_Response, error)
ReadDataSource(context.Context, *ReadDataSource_Request) (*ReadDataSource_Response, error)
// ////// Graceful Shutdown
Stop(context.Context, *Stop_Request) (*Stop_Response, error)
}
func RegisterProviderServer(s *grpc.Server, srv ProviderServer) {
s.RegisterService(&_Provider_serviceDesc, srv)
}
func _Provider_GetSchema_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
in := new(GetProviderSchema_Request)
if err := dec(in); err != nil {
return nil, err
}
if interceptor == nil {
return srv.(ProviderServer).GetSchema(ctx, in)
}
info := &grpc.UnaryServerInfo{
Server: srv,
FullMethod: "/tfplugin5.Provider/GetSchema",
}
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
return srv.(ProviderServer).GetSchema(ctx, req.(*GetProviderSchema_Request))
}
return interceptor(ctx, in, info, handler)
}
func _Provider_PrepareProviderConfig_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
in := new(PrepareProviderConfig_Request)
if err := dec(in); err != nil {
return nil, err
}
if interceptor == nil {
return srv.(ProviderServer).PrepareProviderConfig(ctx, in)
}
info := &grpc.UnaryServerInfo{
Server: srv,
FullMethod: "/tfplugin5.Provider/PrepareProviderConfig",
}
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
return srv.(ProviderServer).PrepareProviderConfig(ctx, req.(*PrepareProviderConfig_Request))
}
return interceptor(ctx, in, info, handler)
}
func _Provider_ValidateResourceTypeConfig_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
in := new(ValidateResourceTypeConfig_Request)
if err := dec(in); err != nil {
return nil, err
}
if interceptor == nil {
return srv.(ProviderServer).ValidateResourceTypeConfig(ctx, in)
}
info := &grpc.UnaryServerInfo{
Server: srv,
FullMethod: "/tfplugin5.Provider/ValidateResourceTypeConfig",
}
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
return srv.(ProviderServer).ValidateResourceTypeConfig(ctx, req.(*ValidateResourceTypeConfig_Request))
}
return interceptor(ctx, in, info, handler)
}
func _Provider_ValidateDataSourceConfig_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
in := new(ValidateDataSourceConfig_Request)
if err := dec(in); err != nil {
return nil, err
}
if interceptor == nil {
return srv.(ProviderServer).ValidateDataSourceConfig(ctx, in)
}
info := &grpc.UnaryServerInfo{
Server: srv,
FullMethod: "/tfplugin5.Provider/ValidateDataSourceConfig",
}
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
return srv.(ProviderServer).ValidateDataSourceConfig(ctx, req.(*ValidateDataSourceConfig_Request))
}
return interceptor(ctx, in, info, handler)
}
func _Provider_UpgradeResourceState_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
in := new(UpgradeResourceState_Request)
if err := dec(in); err != nil {
return nil, err
}
if interceptor == nil {
return srv.(ProviderServer).UpgradeResourceState(ctx, in)
}
info := &grpc.UnaryServerInfo{
Server: srv,
FullMethod: "/tfplugin5.Provider/UpgradeResourceState",
}
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
return srv.(ProviderServer).UpgradeResourceState(ctx, req.(*UpgradeResourceState_Request))
}
return interceptor(ctx, in, info, handler)
}
func _Provider_Configure_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
in := new(Configure_Request)
if err := dec(in); err != nil {
return nil, err
}
if interceptor == nil {
return srv.(ProviderServer).Configure(ctx, in)
}
info := &grpc.UnaryServerInfo{
Server: srv,
FullMethod: "/tfplugin5.Provider/Configure",
}
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
return srv.(ProviderServer).Configure(ctx, req.(*Configure_Request))
}
return interceptor(ctx, in, info, handler)
}
func _Provider_ReadResource_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
in := new(ReadResource_Request)
if err := dec(in); err != nil {
return nil, err
}
if interceptor == nil {
return srv.(ProviderServer).ReadResource(ctx, in)
}
info := &grpc.UnaryServerInfo{
Server: srv,
FullMethod: "/tfplugin5.Provider/ReadResource",
}
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
return srv.(ProviderServer).ReadResource(ctx, req.(*ReadResource_Request))
}
return interceptor(ctx, in, info, handler)
}
func _Provider_PlanResourceChange_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
in := new(PlanResourceChange_Request)
if err := dec(in); err != nil {
return nil, err
}
if interceptor == nil {
return srv.(ProviderServer).PlanResourceChange(ctx, in)
}
info := &grpc.UnaryServerInfo{
Server: srv,
FullMethod: "/tfplugin5.Provider/PlanResourceChange",
}
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
return srv.(ProviderServer).PlanResourceChange(ctx, req.(*PlanResourceChange_Request))
}
return interceptor(ctx, in, info, handler)
}
func _Provider_ApplyResourceChange_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
in := new(ApplyResourceChange_Request)
if err := dec(in); err != nil {
return nil, err
}
if interceptor == nil {
return srv.(ProviderServer).ApplyResourceChange(ctx, in)
}
info := &grpc.UnaryServerInfo{
Server: srv,
FullMethod: "/tfplugin5.Provider/ApplyResourceChange",
}
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
return srv.(ProviderServer).ApplyResourceChange(ctx, req.(*ApplyResourceChange_Request))
}
return interceptor(ctx, in, info, handler)
}
func _Provider_ImportResourceState_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
in := new(ImportResourceState_Request)
if err := dec(in); err != nil {
return nil, err
}
if interceptor == nil {
return srv.(ProviderServer).ImportResourceState(ctx, in)
}
info := &grpc.UnaryServerInfo{
Server: srv,
FullMethod: "/tfplugin5.Provider/ImportResourceState",
}
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
return srv.(ProviderServer).ImportResourceState(ctx, req.(*ImportResourceState_Request))
}
return interceptor(ctx, in, info, handler)
}
func _Provider_ReadDataSource_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
in := new(ReadDataSource_Request)
if err := dec(in); err != nil {
return nil, err
}
if interceptor == nil {
return srv.(ProviderServer).ReadDataSource(ctx, in)
}
info := &grpc.UnaryServerInfo{
Server: srv,
FullMethod: "/tfplugin5.Provider/ReadDataSource",
}
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
return srv.(ProviderServer).ReadDataSource(ctx, req.(*ReadDataSource_Request))
}
return interceptor(ctx, in, info, handler)
}
func _Provider_Stop_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
in := new(Stop_Request)
if err := dec(in); err != nil {
return nil, err
}
if interceptor == nil {
return srv.(ProviderServer).Stop(ctx, in)
}
info := &grpc.UnaryServerInfo{
Server: srv,
FullMethod: "/tfplugin5.Provider/Stop",
}
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
return srv.(ProviderServer).Stop(ctx, req.(*Stop_Request))
}
return interceptor(ctx, in, info, handler)
}
var _Provider_serviceDesc = grpc.ServiceDesc{
ServiceName: "tfplugin5.Provider",
HandlerType: (*ProviderServer)(nil),
Methods: []grpc.MethodDesc{
{
MethodName: "GetSchema",
Handler: _Provider_GetSchema_Handler,
},
{
MethodName: "PrepareProviderConfig",
Handler: _Provider_PrepareProviderConfig_Handler,
},
{
MethodName: "ValidateResourceTypeConfig",
Handler: _Provider_ValidateResourceTypeConfig_Handler,
},
{
MethodName: "ValidateDataSourceConfig",
Handler: _Provider_ValidateDataSourceConfig_Handler,
},
{
MethodName: "UpgradeResourceState",
Handler: _Provider_UpgradeResourceState_Handler,
},
{
MethodName: "Configure",
Handler: _Provider_Configure_Handler,
},
{
MethodName: "ReadResource",
Handler: _Provider_ReadResource_Handler,
},
{
MethodName: "PlanResourceChange",
Handler: _Provider_PlanResourceChange_Handler,
},
{
MethodName: "ApplyResourceChange",
Handler: _Provider_ApplyResourceChange_Handler,
},
{
MethodName: "ImportResourceState",
Handler: _Provider_ImportResourceState_Handler,
},
{
MethodName: "ReadDataSource",
Handler: _Provider_ReadDataSource_Handler,
},
{
MethodName: "Stop",
Handler: _Provider_Stop_Handler,
},
},
Streams: []grpc.StreamDesc{},
Metadata: "tfplugin5.proto",
}
// ProvisionerClient is the client API for Provisioner service.
//
// For semantics around ctx use and closing/ending streaming RPCs, please refer to https://godoc.org/google.golang.org/grpc#ClientConn.NewStream.
type ProvisionerClient interface {
GetSchema(ctx context.Context, in *GetProvisionerSchema_Request, opts ...grpc.CallOption) (*GetProvisionerSchema_Response, error)
ValidateProvisionerConfig(ctx context.Context, in *ValidateProvisionerConfig_Request, opts ...grpc.CallOption) (*ValidateProvisionerConfig_Response, error)
ProvisionResource(ctx context.Context, in *ProvisionResource_Request, opts ...grpc.CallOption) (Provisioner_ProvisionResourceClient, error)
Stop(ctx context.Context, in *Stop_Request, opts ...grpc.CallOption) (*Stop_Response, error)
}
type provisionerClient struct {
cc *grpc.ClientConn
}
func NewProvisionerClient(cc *grpc.ClientConn) ProvisionerClient {
return &provisionerClient{cc}
}
func (c *provisionerClient) GetSchema(ctx context.Context, in *GetProvisionerSchema_Request, opts ...grpc.CallOption) (*GetProvisionerSchema_Response, error) {
out := new(GetProvisionerSchema_Response)
err := c.cc.Invoke(ctx, "/tfplugin5.Provisioner/GetSchema", in, out, opts...)
if err != nil {
return nil, err
}
return out, nil
}
func (c *provisionerClient) ValidateProvisionerConfig(ctx context.Context, in *ValidateProvisionerConfig_Request, opts ...grpc.CallOption) (*ValidateProvisionerConfig_Response, error) {
out := new(ValidateProvisionerConfig_Response)
err := c.cc.Invoke(ctx, "/tfplugin5.Provisioner/ValidateProvisionerConfig", in, out, opts...)
if err != nil {
return nil, err
}
return out, nil
}
func (c *provisionerClient) ProvisionResource(ctx context.Context, in *ProvisionResource_Request, opts ...grpc.CallOption) (Provisioner_ProvisionResourceClient, error) {
stream, err := c.cc.NewStream(ctx, &_Provisioner_serviceDesc.Streams[0], "/tfplugin5.Provisioner/ProvisionResource", opts...)
if err != nil {
return nil, err
}
x := &provisionerProvisionResourceClient{stream}
if err := x.ClientStream.SendMsg(in); err != nil {
return nil, err
}
if err := x.ClientStream.CloseSend(); err != nil {
return nil, err
}
return x, nil
}
type Provisioner_ProvisionResourceClient interface {
Recv() (*ProvisionResource_Response, error)
grpc.ClientStream
}
type provisionerProvisionResourceClient struct {
grpc.ClientStream
}
func (x *provisionerProvisionResourceClient) Recv() (*ProvisionResource_Response, error) {
m := new(ProvisionResource_Response)
if err := x.ClientStream.RecvMsg(m); err != nil {
return nil, err
}
return m, nil
}
func (c *provisionerClient) Stop(ctx context.Context, in *Stop_Request, opts ...grpc.CallOption) (*Stop_Response, error) {
out := new(Stop_Response)
err := c.cc.Invoke(ctx, "/tfplugin5.Provisioner/Stop", in, out, opts...)
if err != nil {
return nil, err
}
return out, nil
}
// ProvisionerServer is the server API for Provisioner service.
type ProvisionerServer interface {
GetSchema(context.Context, *GetProvisionerSchema_Request) (*GetProvisionerSchema_Response, error)
ValidateProvisionerConfig(context.Context, *ValidateProvisionerConfig_Request) (*ValidateProvisionerConfig_Response, error)
ProvisionResource(*ProvisionResource_Request, Provisioner_ProvisionResourceServer) error
Stop(context.Context, *Stop_Request) (*Stop_Response, error)
}
func RegisterProvisionerServer(s *grpc.Server, srv ProvisionerServer) {
s.RegisterService(&_Provisioner_serviceDesc, srv)
}
func _Provisioner_GetSchema_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
in := new(GetProvisionerSchema_Request)
if err := dec(in); err != nil {
return nil, err
}
if interceptor == nil {
return srv.(ProvisionerServer).GetSchema(ctx, in)
}
info := &grpc.UnaryServerInfo{
Server: srv,
FullMethod: "/tfplugin5.Provisioner/GetSchema",
}
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
return srv.(ProvisionerServer).GetSchema(ctx, req.(*GetProvisionerSchema_Request))
}
return interceptor(ctx, in, info, handler)
}
func _Provisioner_ValidateProvisionerConfig_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
in := new(ValidateProvisionerConfig_Request)
if err := dec(in); err != nil {
return nil, err
}
if interceptor == nil {
return srv.(ProvisionerServer).ValidateProvisionerConfig(ctx, in)
}
info := &grpc.UnaryServerInfo{
Server: srv,
FullMethod: "/tfplugin5.Provisioner/ValidateProvisionerConfig",
}
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
return srv.(ProvisionerServer).ValidateProvisionerConfig(ctx, req.(*ValidateProvisionerConfig_Request))
}
return interceptor(ctx, in, info, handler)
}
func _Provisioner_ProvisionResource_Handler(srv interface{}, stream grpc.ServerStream) error {
m := new(ProvisionResource_Request)
if err := stream.RecvMsg(m); err != nil {
return err
}
return srv.(ProvisionerServer).ProvisionResource(m, &provisionerProvisionResourceServer{stream})
}
type Provisioner_ProvisionResourceServer interface {
Send(*ProvisionResource_Response) error
grpc.ServerStream
}
type provisionerProvisionResourceServer struct {
grpc.ServerStream
}
func (x *provisionerProvisionResourceServer) Send(m *ProvisionResource_Response) error {
return x.ServerStream.SendMsg(m)
}
func _Provisioner_Stop_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
in := new(Stop_Request)
if err := dec(in); err != nil {
return nil, err
}
if interceptor == nil {
return srv.(ProvisionerServer).Stop(ctx, in)
}
info := &grpc.UnaryServerInfo{
Server: srv,
FullMethod: "/tfplugin5.Provisioner/Stop",
}
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
return srv.(ProvisionerServer).Stop(ctx, req.(*Stop_Request))
}
return interceptor(ctx, in, info, handler)
}
var _Provisioner_serviceDesc = grpc.ServiceDesc{
ServiceName: "tfplugin5.Provisioner",
HandlerType: (*ProvisionerServer)(nil),
Methods: []grpc.MethodDesc{
{
MethodName: "GetSchema",
Handler: _Provisioner_GetSchema_Handler,
},
{
MethodName: "ValidateProvisionerConfig",
Handler: _Provisioner_ValidateProvisionerConfig_Handler,
},
{
MethodName: "Stop",
Handler: _Provisioner_Stop_Handler,
},
},
Streams: []grpc.StreamDesc{
{
StreamName: "ProvisionResource",
Handler: _Provisioner_ProvisionResource_Handler,
ServerStreams: true,
},
},
Metadata: "tfplugin5.proto",
}
configs/configschema: Introduce the NestingGroup mode for blocks In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.
2019-04-09 00:32:53 +02:00
func init() { proto.RegisterFile("tfplugin5.proto", fileDescriptor_tfplugin5_56820f4fb67360c5) }
var fileDescriptor_tfplugin5_56820f4fb67360c5 = []byte{
// 1876 bytes of a gzipped FileDescriptorProto
0x1f, 0x8b, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0xff, 0xd4, 0x59, 0xcd, 0x6f, 0x23, 0x49,
0x15, 0x9f, 0x76, 0xdb, 0x89, 0xfd, 0x9c, 0x0f, 0xa7, 0x66, 0x76, 0x30, 0xbd, 0xbb, 0x10, 0xcc,
0x47, 0xb2, 0xda, 0x1d, 0xcf, 0x2a, 0x03, 0xbb, 0x4b, 0x18, 0xad, 0xc8, 0x66, 0x42, 0x26, 0x62,
0x26, 0x1b, 0xca, 0xf3, 0x81, 0x84, 0xb4, 0x56, 0x8d, 0xbb, 0xe2, 0x69, 0xc6, 0xee, 0xee, 0xad,
0x2e, 0x67, 0x62, 0x71, 0x44, 0x70, 0xe6, 0xc2, 0x87, 0xc4, 0xc7, 0x85, 0x03, 0xff, 0x00, 0x07,
0xe0, 0xc6, 0x89, 0x7f, 0x80, 0x1b, 0x70, 0x42, 0x70, 0x43, 0x1c, 0xe1, 0x82, 0x84, 0xea, 0xab,
0xbb, 0x6c, 0xb7, 0x93, 0x9e, 0x64, 0x57, 0x88, 0x5b, 0x57, 0xbd, 0x5f, 0xbd, 0xf7, 0xab, 0xf7,
0x5e, 0xbd, 0x57, 0x65, 0xc3, 0x2a, 0x3f, 0x8e, 0x07, 0xa3, 0x7e, 0x10, 0x7e, 0xa9, 0x1d, 0xb3,
0x88, 0x47, 0xa8, 0x96, 0x4e, 0xb4, 0x6e, 0xc3, 0xd2, 0x9d, 0x71, 0x48, 0x86, 0x41, 0xef, 0x11,
0x19, 0x8c, 0x28, 0x6a, 0xc2, 0xe2, 0x30, 0xe9, 0xc7, 0xa4, 0xf7, 0xac, 0xe9, 0xac, 0x3b, 0x9b,
0x4b, 0xd8, 0x0c, 0x11, 0x82, 0xf2, 0xb7, 0x93, 0x28, 0x6c, 0x96, 0xe4, 0xb4, 0xfc, 0x6e, 0xfd,
0xd5, 0x01, 0xb8, 0x13, 0x90, 0x7e, 0x18, 0x25, 0x3c, 0xe8, 0xa1, 0x6d, 0xa8, 0x26, 0xf4, 0x84,
0xb2, 0x80, 0x8f, 0xe5, 0xea, 0x95, 0xad, 0x4f, 0xb5, 0x33, 0xdb, 0x19, 0xb0, 0xdd, 0xd1, 0x28,
0x9c, 0xe2, 0x85, 0xe1, 0x64, 0x34, 0x1c, 0x12, 0x36, 0x96, 0x16, 0x6a, 0xd8, 0x0c, 0xd1, 0x75,
0x58, 0xf0, 0x29, 0x27, 0xc1, 0xa0, 0xe9, 0x4a, 0x81, 0x1e, 0xa1, 0xb7, 0xa0, 0x46, 0x38, 0x67,
0xc1, 0x93, 0x11, 0xa7, 0xcd, 0xf2, 0xba, 0xb3, 0x59, 0xdf, 0x6a, 0x5a, 0xe6, 0x76, 0x8c, 0xec,
0x88, 0xf0, 0xa7, 0x38, 0x83, 0xb6, 0x6e, 0x42, 0xd5, 0xd8, 0x47, 0x75, 0x58, 0x3c, 0x38, 0x7c,
0xb4, 0x73, 0xef, 0xe0, 0x4e, 0xe3, 0x0a, 0xaa, 0x41, 0x65, 0x0f, 0xe3, 0xf7, 0x71, 0xc3, 0x11,
0xf3, 0x8f, 0x77, 0xf0, 0xe1, 0xc1, 0xe1, 0x7e, 0xa3, 0xd4, 0xfa, 0xb3, 0x03, 0xcb, 0x13, 0xda,
0xd0, 0x2d, 0xa8, 0x24, 0x9c, 0xc6, 0x49, 0xd3, 0x59, 0x77, 0x37, 0xeb, 0x5b, 0xaf, 0xce, 0x33,
0xdb, 0xee, 0x70, 0x1a, 0x63, 0x85, 0xf5, 0x7e, 0xe8, 0x40, 0x59, 0x8c, 0xd1, 0x06, 0xac, 0xa4,
0x6c, 0xba, 0x21, 0x19, 0x52, 0xe9, 0xac, 0xda, 0xdd, 0x2b, 0x78, 0x39, 0x9d, 0x3f, 0x24, 0x43,
0x8a, 0xda, 0x80, 0xe8, 0x80, 0x0e, 0x69, 0xc8, 0xbb, 0xcf, 0xe8, 0xb8, 0x9b, 0x70, 0x16, 0x84,
0x7d, 0xe5, 0x9e, 0xbb, 0x57, 0x70, 0x43, 0xcb, 0xbe, 0x4e, 0xc7, 0x1d, 0x29, 0x41, 0x9b, 0xb0,
0x6a, 0xe3, 0x83, 0x90, 0x4b, 0x97, 0xb9, 0x42, 0x73, 0x06, 0x3e, 0x08, 0xf9, 0x7b, 0x20, 0x22,
0x35, 0xa0, 0x3d, 0x1e, 0xb1, 0xd6, 0x2d, 0x41, 0x2b, 0x8a, 0xbd, 0x1a, 0x2c, 0x62, 0xfa, 0xe1,
0x88, 0x26, 0xdc, 0x5b, 0x87, 0x2a, 0xa6, 0x49, 0x1c, 0x85, 0x09, 0x45, 0xd7, 0xa0, 0xb2, 0xc7,
0x58, 0xc4, 0x14, 0x49, 0xac, 0x06, 0xad, 0x1f, 0x39, 0x50, 0xc5, 0xe4, 0x79, 0x87, 0x13, 0x4e,
0xd3, 0xd4, 0x70, 0xb2, 0xd4, 0x40, 0xdb, 0xb0, 0x78, 0x3c, 0x20, 0x7c, 0x48, 0xe2, 0x66, 0x49,
0x3a, 0x69, 0xdd, 0x72, 0x92, 0x59, 0xd9, 0xfe, 0x9a, 0x82, 0xec, 0x85, 0x9c, 0x8d, 0xb1, 0x59,
0xe0, 0x6d, 0xc3, 0x92, 0x2d, 0x40, 0x0d, 0x70, 0x9f, 0xd1, 0xb1, 0x26, 0x20, 0x3e, 0x05, 0xa9,
0x13, 0x91, 0xaf, 0x3a, 0x57, 0xd4, 0x60, 0xbb, 0xf4, 0x8e, 0xd3, 0xfa, 0x7b, 0x05, 0x16, 0x3a,
0xbd, 0xa7, 0x74, 0x48, 0x44, 0x4a, 0x9d, 0x50, 0x96, 0x04, 0x9a, 0x99, 0x8b, 0xcd, 0x10, 0xdd,
0x80, 0xca, 0x93, 0x41, 0xd4, 0x7b, 0x26, 0x97, 0xd7, 0xb7, 0x3e, 0x61, 0x51, 0x53, 0x6b, 0xdb,
0xef, 0x09, 0x31, 0x56, 0x28, 0xef, 0x17, 0x0e, 0x54, 0xe4, 0xc4, 0x19, 0x2a, 0xbf, 0x02, 0x90,
0x06, 0x2f, 0xd1, 0x5b, 0x7e, 0x79, 0x56, 0x6f, 0x9a, 0x1e, 0xd8, 0x82, 0xa3, 0x77, 0xa1, 0x2e,
0x2d, 0x75, 0xf9, 0x38, 0xa6, 0x49, 0xd3, 0x9d, 0xc9, 0x2a, 0xbd, 0xfa, 0x90, 0x26, 0x9c, 0xfa,
0x8a, 0x1b, 0xc8, 0x15, 0x0f, 0xc4, 0x02, 0xef, 0x0f, 0x0e, 0xd4, 0x52, 0xcd, 0x22, 0x1c, 0x59,
0x56, 0x61, 0xf9, 0x2d, 0xe6, 0x84, 0x6e, 0x73, 0x7a, 0xc5, 0x37, 0x5a, 0x87, 0xba, 0x4f, 0x93,
0x1e, 0x0b, 0x62, 0x2e, 0x36, 0xa4, 0x4e, 0x97, 0x3d, 0x85, 0x3c, 0xa8, 0x32, 0xfa, 0xe1, 0x28,
0x60, 0xd4, 0x97, 0x27, 0xac, 0x8a, 0xd3, 0xb1, 0x90, 0x45, 0x12, 0x45, 0x06, 0xcd, 0x8a, 0x92,
0x99, 0xb1, 0x90, 0xf5, 0xa2, 0x61, 0x3c, 0xe2, 0xd4, 0x6f, 0x2e, 0x28, 0x99, 0x19, 0xa3, 0x57,
0xa0, 0x96, 0xd0, 0x30, 0x09, 0x78, 0x70, 0x42, 0x9b, 0x8b, 0x52, 0x98, 0x4d, 0x78, 0xbf, 0x2a,
0x41, 0xdd, 0xda, 0x25, 0x7a, 0x19, 0x6a, 0x82, 0xab, 0x75, 0x4c, 0x70, 0x55, 0x4c, 0xc8, 0xf3,
0xf1, 0x62, 0x61, 0x44, 0xbb, 0xb0, 0x18, 0xd2, 0x84, 0x8b, 0x33, 0xe4, 0xca, 0xea, 0xf4, 0xda,
0x99, 0x1e, 0x96, 0xdf, 0x41, 0xd8, 0xbf, 0x1f, 0xf9, 0x14, 0x9b, 0x95, 0x82, 0xd0, 0x30, 0x08,
0xbb, 0x01, 0xa7, 0xc3, 0x44, 0xfa, 0xc4, 0xc5, 0xd5, 0x61, 0x10, 0x1e, 0x88, 0xb1, 0x14, 0x92,
0x53, 0x2d, 0xac, 0x68, 0x21, 0x39, 0x95, 0xc2, 0xd6, 0x7d, 0xb5, 0x33, 0xad, 0x71, 0xb2, 0xf4,
0x00, 0x2c, 0x74, 0x0e, 0x0e, 0xf7, 0xef, 0xed, 0x35, 0x1c, 0x54, 0x85, 0xf2, 0xbd, 0x83, 0xce,
0x83, 0x46, 0x09, 0x2d, 0x82, 0xdb, 0xd9, 0x7b, 0xd0, 0x70, 0xc5, 0xc7, 0xfd, 0x9d, 0xa3, 0x46,
0x59, 0x94, 0xa8, 0x7d, 0xfc, 0xfe, 0xc3, 0xa3, 0x46, 0xa5, 0xf5, 0x93, 0x32, 0xac, 0xed, 0x53,
0x7e, 0xc4, 0xa2, 0x93, 0xc0, 0xa7, 0x4c, 0xf1, 0xb7, 0x0f, 0xf1, 0xbf, 0x5c, 0xeb, 0x14, 0xdf,
0x80, 0x6a, 0xac, 0x91, 0xd2, 0x8d, 0xf5, 0xad, 0xb5, 0x99, 0xcd, 0xe3, 0x14, 0x82, 0x28, 0x34,
0x18, 0x4d, 0xa2, 0x11, 0xeb, 0xd1, 0x6e, 0x22, 0x85, 0x26, 0xa7, 0xb7, 0xad, 0x65, 0x33, 0xe6,
0xdb, 0xc6, 0x9e, 0xf8, 0x90, 0xab, 0xd5, 0x7c, 0xa2, 0x0e, 0xf8, 0x2a, 0x9b, 0x9c, 0x45, 0x03,
0xb8, 0xea, 0x13, 0x4e, 0xba, 0x53, 0x96, 0x54, 0xfe, 0xdf, 0x2e, 0x66, 0xe9, 0x0e, 0xe1, 0xa4,
0x33, 0x6b, 0x6b, 0xcd, 0x9f, 0x9e, 0x47, 0x6f, 0x43, 0xdd, 0x4f, 0x7b, 0x90, 0x08, 0x9e, 0xb0,
0xf2, 0x52, 0x6e, 0x87, 0xc2, 0x36, 0xd2, 0x7b, 0x08, 0xd7, 0xf2, 0xf6, 0x93, 0x53, 0x97, 0x36,
0xec, 0xba, 0x94, 0xeb, 0xe3, 0xac, 0x54, 0x79, 0x8f, 0xe1, 0x7a, 0x3e, 0xf9, 0x4b, 0x2a, 0x6e,
0xfd, 0xc9, 0x81, 0x97, 0x8e, 0x18, 0x8d, 0x09, 0xa3, 0xc6, 0x6b, 0xbb, 0x51, 0x78, 0x1c, 0xf4,
0xbd, 0xed, 0x34, 0x3d, 0xd0, 0x4d, 0x58, 0xe8, 0xc9, 0x49, 0x9d, 0x0f, 0xf6, 0xe9, 0xb1, 0xaf,
0x04, 0x58, 0xc3, 0xbc, 0xef, 0x39, 0x56, 0x3e, 0x7d, 0x15, 0x56, 0x63, 0x65, 0xc1, 0xef, 0x16,
0x53, 0xb3, 0x62, 0xf0, 0x8a, 0xca, 0x74, 0x34, 0x4a, 0x45, 0xa3, 0xd1, 0xfa, 0x41, 0x09, 0xae,
0x3d, 0x8c, 0xfb, 0x8c, 0xf8, 0x34, 0x8d, 0x8a, 0x68, 0x26, 0x1e, 0xcb, 0x36, 0x77, 0x66, 0xd9,
0xb0, 0x8a, 0x78, 0x69, 0xb2, 0x88, 0xbf, 0x09, 0x35, 0x46, 0x9e, 0x77, 0x13, 0xa1, 0x4e, 0xd6,
0x88, 0xfa, 0xd6, 0xd5, 0x9c, 0xb6, 0x85, 0xab, 0x4c, 0x7f, 0x79, 0xdf, 0xb5, 0x9d, 0xf2, 0x2e,
0xac, 0x8c, 0x14, 0x31, 0x5f, 0xeb, 0x38, 0xc7, 0x27, 0xcb, 0x06, 0xae, 0xfa, 0xe8, 0x85, 0x5d,
0xf2, 0x3b, 0x07, 0xbc, 0x47, 0x64, 0x10, 0xf8, 0x82, 0x9c, 0xf6, 0x89, 0xe8, 0x0c, 0x3a, 0xea,
0x8f, 0x0b, 0x3a, 0x26, 0x4b, 0x89, 0x52, 0xb1, 0x94, 0xd8, 0xb5, 0x36, 0x3f, 0x45, 0xde, 0x29,
0x4c, 0xfe, 0x37, 0x0e, 0x34, 0x0d, 0xf9, 0xec, 0x3c, 0xfc, 0x5f, 0x50, 0xff, 0xad, 0x03, 0x35,
0x45, 0x74, 0xc4, 0xa8, 0xd7, 0xcf, 0xb8, 0xbe, 0x0e, 0x6b, 0x9c, 0x32, 0x46, 0x8e, 0x23, 0x36,
0xec, 0xda, 0x37, 0x86, 0x1a, 0x6e, 0xa4, 0x82, 0x47, 0x3a, 0xeb, 0xfe, 0x37, 0xdc, 0xff, 0xe9,
0xc0, 0x12, 0xa6, 0xc4, 0x37, 0xf9, 0xe2, 0xf9, 0x05, 0x5d, 0x7d, 0x1b, 0x96, 0x7b, 0x23, 0xc6,
0xc4, 0x2d, 0x53, 0x25, 0xf9, 0x39, 0xac, 0x97, 0x34, 0x5a, 0x1d, 0x98, 0xb1, 0xc5, 0xfd, 0x8b,
0x50, 0x0b, 0xe9, 0xf3, 0x62, 0x47, 0xa5, 0x1a, 0xd2, 0xe7, 0x97, 0x3c, 0x25, 0xbf, 0x2e, 0x03,
0x3a, 0x1a, 0x90, 0xd0, 0xec, 0x78, 0xf7, 0x29, 0x09, 0xfb, 0xd4, 0xfb, 0x8f, 0x53, 0x70, 0xe3,
0xef, 0x40, 0x3d, 0x66, 0x41, 0xc4, 0x8a, 0x6d, 0x1b, 0x24, 0x56, 0x51, 0xde, 0x03, 0x14, 0xb3,
0x28, 0x8e, 0x12, 0xea, 0x77, 0xb3, 0x1d, 0xbb, 0x67, 0x2b, 0x68, 0x98, 0x25, 0x87, 0x66, 0xe7,
0x59, 0xa2, 0x94, 0x0b, 0x25, 0x0a, 0xfa, 0x2c, 0x2c, 0x2b, 0xc6, 0x31, 0x0b, 0x4e, 0x84, 0xc9,
0x8a, 0xbc, 0xfe, 0x2d, 0xc9, 0xc9, 0x23, 0x35, 0xe7, 0xfd, 0xbc, 0x64, 0x85, 0xe4, 0x36, 0x2c,
0xc7, 0x03, 0x12, 0x86, 0x45, 0x2b, 0xd8, 0x92, 0x46, 0x2b, 0x82, 0xbb, 0xe2, 0xda, 0x20, 0xef,
0x87, 0x49, 0x97, 0xd1, 0x78, 0x40, 0x7a, 0x54, 0xc7, 0x67, 0xfe, 0xcb, 0x6c, 0xd5, 0xac, 0xc0,
0x6a, 0x01, 0xda, 0x80, 0x55, 0x43, 0xc1, 0xd0, 0x76, 0x25, 0xed, 0x15, 0x3d, 0xad, 0x89, 0x5f,
0xb8, 0x9f, 0xa3, 0x37, 0x00, 0x0d, 0x68, 0x9f, 0xf4, 0xc6, 0xf2, 0xbe, 0xdd, 0x4d, 0xc6, 0x09,
0xa7, 0x43, 0x7d, 0x89, 0x6d, 0x28, 0x89, 0xa8, 0x9e, 0x1d, 0x39, 0xdf, 0xfa, 0xa3, 0x0b, 0x57,
0x77, 0xe2, 0x78, 0x30, 0x9e, 0xca, 0x9b, 0x7f, 0x7f, 0xfc, 0x79, 0x33, 0x13, 0x0d, 0xf7, 0x45,
0xa2, 0xf1, 0xc2, 0xe9, 0x92, 0xe3, 0xf9, 0x4a, 0x9e, 0xe7, 0xbd, 0xdf, 0x3b, 0x97, 0x3e, 0xc5,
0x4d, 0x58, 0x34, 0x36, 0xd4, 0x9b, 0xc4, 0x0c, 0xa7, 0xc3, 0xea, 0x5e, 0x32, 0xac, 0xe5, 0x39,
0x61, 0xfd, 0x47, 0x09, 0xae, 0x1e, 0x0c, 0xe3, 0x88, 0xf1, 0xc9, 0x5b, 0xc4, 0x5b, 0x05, 0xa3,
0xba, 0x02, 0xa5, 0xc0, 0xd7, 0xef, 0xcf, 0x52, 0xe0, 0x7b, 0xa7, 0xd0, 0x50, 0xea, 0x68, 0x5a,
0x52, 0xcf, 0x7d, 0xbd, 0x14, 0x4a, 0x08, 0x85, 0xb2, 0x1d, 0xe6, 0x4e, 0x38, 0xcc, 0xfb, 0xa5,
0x1d, 0x8d, 0x0f, 0x00, 0x05, 0x9a, 0x46, 0xd7, 0x5c, 0xb7, 0x4d, 0x5b, 0xb8, 0x69, 0x99, 0xc8,
0xd9, 0x7a, 0x7b, 0x9a, 0x3f, 0x5e, 0x0b, 0xa6, 0x66, 0x92, 0x8b, 0x57, 0xdf, 0xbf, 0x38, 0xb0,
0x22, 0xfa, 0x4d, 0xd6, 0xe2, 0x3f, 0xbe, 0xe6, 0xce, 0x26, 0x5e, 0x3e, 0x95, 0x42, 0xa9, 0xa9,
0xdd, 0x7c, 0xe1, 0xfd, 0xfd, 0xd4, 0x81, 0x6b, 0xe6, 0x99, 0x22, 0xda, 0x7a, 0xde, 0x93, 0xec,
0xd4, 0xe2, 0x75, 0x4b, 0x54, 0x85, 0x14, 0x3b, 0xff, 0x51, 0x66, 0xa3, 0x2e, 0xce, 0xee, 0x67,
0x0e, 0x7c, 0xd2, 0x5c, 0xb2, 0x2c, 0x8a, 0x1f, 0xc1, 0xb3, 0xe0, 0x23, 0xb9, 0x8c, 0xfc, 0xcd,
0x81, 0xb5, 0x94, 0x56, 0x7a, 0x23, 0x49, 0x2e, 0x4e, 0x0b, 0xbd, 0x0d, 0xd0, 0x8b, 0xc2, 0x90,
0xf6, 0xb8, 0xb9, 0xe7, 0x9f, 0x55, 0x73, 0x33, 0xa8, 0xf7, 0x2d, 0x6b, 0x3f, 0xd7, 0x61, 0x21,
0x1a, 0xf1, 0x78, 0xc4, 0x75, 0x4a, 0xea, 0xd1, 0x85, 0xc3, 0xb0, 0xf5, 0xe3, 0x1a, 0x54, 0xcd,
0x93, 0x0c, 0x7d, 0x13, 0x6a, 0xfb, 0x94, 0xeb, 0x1f, 0xab, 0x3e, 0x77, 0xce, 0x6b, 0x57, 0x25,
0xd0, 0xe7, 0x0b, 0xbd, 0x89, 0xd1, 0x60, 0xce, 0xfb, 0x0f, 0x6d, 0x5a, 0xeb, 0x73, 0x11, 0xa9,
0xa5, 0xd7, 0x0a, 0x20, 0xb5, 0xb5, 0xef, 0x9c, 0xf5, 0xf8, 0x40, 0x37, 0x2c, 0x45, 0xf3, 0x61,
0xa9, 0xdd, 0x76, 0x51, 0xb8, 0x36, 0x3e, 0x9a, 0xff, 0x78, 0x40, 0xaf, 0xe7, 0xe8, 0x9a, 0x06,
0xa5, 0x86, 0xdf, 0x28, 0x06, 0xd6, 0x66, 0x83, 0xfc, 0x37, 0x28, 0xda, 0xb0, 0xb4, 0xe4, 0x01,
0x52, 0x73, 0x9b, 0xe7, 0x03, 0xb5, 0xa9, 0xbb, 0xd6, 0x1b, 0x03, 0xbd, 0x62, 0x2d, 0x4b, 0x67,
0x53, 0xa5, 0xaf, 0xce, 0x91, 0x6a, 0x4d, 0xdf, 0x98, 0xbc, 0xf1, 0xa3, 0x4f, 0xdb, 0x6f, 0x5b,
0x4b, 0x90, 0xea, 0x5b, 0x9f, 0x0f, 0xd0, 0x2a, 0x7b, 0x79, 0x57, 0x6a, 0x64, 0xa7, 0xe9, 0xac,
0x38, 0x55, 0xff, 0x85, 0xf3, 0x60, 0xda, 0xc8, 0x71, 0xee, 0x05, 0x0c, 0xd9, 0xcb, 0x73, 0xe4,
0xa9, 0x99, 0x8d, 0x73, 0x71, 0x99, 0x9d, 0x9c, 0xb6, 0x38, 0x61, 0x27, 0xaf, 0x6d, 0xe6, 0xd9,
0xc9, 0xc7, 0x69, 0x3b, 0x8f, 0xa7, 0x3b, 0x21, 0xfa, 0xcc, 0x94, 0xa3, 0x33, 0x51, 0xaa, 0xbd,
0x75, 0x16, 0x44, 0x2b, 0xfe, 0xb2, 0xfa, 0x29, 0x1f, 0x4d, 0xfc, 0x12, 0xca, 0xa3, 0x38, 0x55,
0xd2, 0x9c, 0x15, 0xa8, 0xa5, 0x5b, 0xdf, 0x77, 0xa1, 0x6e, 0x35, 0x06, 0xf4, 0x81, 0x5d, 0x9c,
0x36, 0x72, 0xca, 0x8e, 0xdd, 0xe3, 0x72, 0xb3, 0x7a, 0x0e, 0x50, 0x53, 0x3d, 0x3d, 0xa3, 0x1f,
0xa1, 0xbc, 0xb3, 0x38, 0x83, 0x4a, 0x8d, 0xde, 0x28, 0x88, 0xd6, 0x96, 0x9f, 0xe4, 0xb4, 0x9a,
0x89, 0xf2, 0x3b, 0x23, 0xcd, 0x2d, 0xbf, 0x79, 0x28, 0x65, 0xe1, 0x4d, 0xe7, 0x12, 0x81, 0x78,
0xb2, 0x20, 0xff, 0xa3, 0xbb, 0xf5, 0xdf, 0x00, 0x00, 0x00, 0xff, 0xff, 0xc8, 0x16, 0x0b, 0x32,
0xb6, 0x1b, 0x00, 0x00,
}