2017-06-26 23:46:34 +02:00
|
|
|
// Copyright 2016-2017, Pulumi Corporation. All rights reserved.
|
2017-02-20 20:18:47 +01:00
|
|
|
|
|
|
|
package resource
|
|
|
|
|
|
|
|
import (
|
|
|
|
"fmt"
|
|
|
|
"reflect"
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
"sort"
|
2017-02-20 20:18:47 +01:00
|
|
|
|
2017-04-19 23:46:50 +02:00
|
|
|
"github.com/pkg/errors"
|
|
|
|
|
2017-05-18 20:38:28 +02:00
|
|
|
"github.com/pulumi/lumi/pkg/tokens"
|
|
|
|
"github.com/pulumi/lumi/pkg/util/contract"
|
|
|
|
"github.com/pulumi/lumi/pkg/util/mapper"
|
2017-02-20 20:18:47 +01:00
|
|
|
)
|
|
|
|
|
|
|
|
// PropertyKey is the name of a property.
|
|
|
|
type PropertyKey tokens.Name
|
|
|
|
|
Initial support for output properties (1 of 3)
This change includes approximately 1/3rd of the change necessary
to support output properties, as per pulumi/lumi#90.
In short, the runtime now has a new hidden type, Latent<T>, which
represents a "speculative" value, whose eventual type will be T,
that we can use during evaluation in various ways. Namely,
operations against Latent<T>s generally produce new Latent<U>s.
During planning, any Latent<T>s that end up in resource properties
are transformed into "unknown" property values. An unknown property
value is legal only during planning-time activities, such as Check,
Name, and InspectChange. As a result, those RPC interfaces have
been updated to include lookaside maps indicating which properties
have unknown values. My intent is to add some helper functions to
make dealing with this circumstance more correct-by-construction.
For now, using an unresolved Latent<T> in a conditional will lead
to an error. See pulumi/lumi#67. Speculating beyond these -- by
supporting iterative planning and application -- is something we
want to support eventually, but it makes sense to do that as an
additive change beyond this initial support. That is a missing 1/3.
Finally, the other missing 1/3rd which will happen much sooner
than the rest is restructuing plan application so that it will
correctly observe resolution of Latent<T> values. Right now, the
evaluation happens in one single pass, prior to the application, and
so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
|
|
|
// PropertySet is a simple set keyed by property name.
|
|
|
|
type PropertySet map[PropertyKey]bool
|
|
|
|
|
2017-02-20 20:18:47 +01:00
|
|
|
// PropertyMap is a simple map keyed by property name with "JSON-like" values.
|
|
|
|
type PropertyMap map[PropertyKey]PropertyValue
|
|
|
|
|
2017-04-22 00:27:32 +02:00
|
|
|
// NewPropertyMap turns a struct into a property map, using any JSON tags inside to determine naming.
|
|
|
|
func NewPropertyMap(s interface{}) PropertyMap {
|
Implement mapper.Encode "for real"
This change implements `mapper.Encode` "for real" (that is, in a way
that isn't a complete embarrassment). It uses the obvious reflection
trickery to encode a tagged struct and its values as a JSON-like
in-memory map and collection of keyed values.
During this, I took the opportunity to also clean up a few other things
that had been bugging me. Namely, the presence of `mapper.Object` was
always error prone, since it isn't a true "typedef" in the sence that
it carries extra RTTI. Instead of doing that, let's just use the real
`map[string]interface{}` "JSON-map-like" object type. Even better, we
no longer require resource providers to deal with the mapper
infrastructure. Instead, the `Check` function can simply return an
array of errors. It's still best practice to return field-specific errors
to facilitate better diagnostics, but it's no longer required; and I've
added `resource.NewFieldError` to eliminate the need to import mapper.
As of this change, we can also consistently emit RPC structs with `lumi`
tags, rather than `lumi` tags on the way in and `json` on the way out.
This completes pulumi/lumi#183.
2017-06-06 02:43:52 +02:00
|
|
|
m, err := mapper.Unmap(s)
|
|
|
|
contract.Assertf(err == nil, "Struct of properties failed to map correctly: %v", err)
|
2017-05-30 19:55:53 +02:00
|
|
|
return NewPropertyMapFromMap(m)
|
|
|
|
}
|
|
|
|
|
|
|
|
func NewPropertyMapFromMap(m map[string]interface{}) PropertyMap {
|
2017-04-22 00:27:32 +02:00
|
|
|
result := make(PropertyMap)
|
|
|
|
for k, v := range m {
|
|
|
|
result[PropertyKey(k)] = NewPropertyValue(v)
|
|
|
|
}
|
|
|
|
return result
|
|
|
|
}
|
|
|
|
|
2017-02-20 20:18:47 +01:00
|
|
|
// PropertyValue is the value of a property, limited to a select few types (see below).
|
|
|
|
type PropertyValue struct {
|
|
|
|
V interface{}
|
|
|
|
}
|
|
|
|
|
2017-05-25 22:19:20 +02:00
|
|
|
// Computed represents the absence of a property value, because it will be computed at some point in the future. It
|
|
|
|
// contains a property value which represents the underlying expected type of the eventual property value.
|
2017-06-08 15:44:21 +02:00
|
|
|
type Computed struct {
|
2017-06-08 15:48:23 +02:00
|
|
|
Element PropertyValue // the eventual value (type) of the computed property.
|
2017-05-25 22:19:20 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// Output is a property value that will eventually be computed by the resource provider. If an output property is
|
|
|
|
// encountered, it means the resource has not yet been created, and so the output value is unavailable. Note that an
|
|
|
|
// output property is a special case of computed, but carries additional semantic meaning.
|
2017-06-08 15:44:21 +02:00
|
|
|
type Output struct {
|
2017-06-08 15:48:23 +02:00
|
|
|
Element PropertyValue // the eventual value (type) of the output property.
|
Initial support for output properties (1 of 3)
This change includes approximately 1/3rd of the change necessary
to support output properties, as per pulumi/lumi#90.
In short, the runtime now has a new hidden type, Latent<T>, which
represents a "speculative" value, whose eventual type will be T,
that we can use during evaluation in various ways. Namely,
operations against Latent<T>s generally produce new Latent<U>s.
During planning, any Latent<T>s that end up in resource properties
are transformed into "unknown" property values. An unknown property
value is legal only during planning-time activities, such as Check,
Name, and InspectChange. As a result, those RPC interfaces have
been updated to include lookaside maps indicating which properties
have unknown values. My intent is to add some helper functions to
make dealing with this circumstance more correct-by-construction.
For now, using an unresolved Latent<T> in a conditional will lead
to an error. See pulumi/lumi#67. Speculating beyond these -- by
supporting iterative planning and application -- is something we
want to support eventually, but it makes sense to do that as an
additive change beyond this initial support. That is a missing 1/3.
Finally, the other missing 1/3rd which will happen much sooner
than the rest is restructuing plan application so that it will
correctly observe resolution of Latent<T> values. Right now, the
evaluation happens in one single pass, prior to the application, and
so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
|
|
|
}
|
|
|
|
|
2017-02-20 20:18:47 +01:00
|
|
|
type ReqError struct {
|
|
|
|
K PropertyKey
|
|
|
|
}
|
|
|
|
|
|
|
|
func IsReqError(err error) bool {
|
|
|
|
_, isreq := err.(*ReqError)
|
|
|
|
return isreq
|
|
|
|
}
|
|
|
|
|
|
|
|
func (err *ReqError) Error() string {
|
|
|
|
return fmt.Sprintf("required property '%v' is missing", err.K)
|
|
|
|
}
|
|
|
|
|
|
|
|
// BoolOrErr checks that the given property has the type bool, issuing an error if not; req indicates if required.
|
|
|
|
func (m PropertyMap) BoolOrErr(k PropertyKey, req bool) (*bool, error) {
|
2017-02-20 22:27:31 +01:00
|
|
|
if v, has := m[k]; has && !v.IsNull() {
|
2017-02-20 20:18:47 +01:00
|
|
|
if !v.IsBool() {
|
2017-04-19 23:46:50 +02:00
|
|
|
return nil, errors.Errorf("property '%v' is not a bool (%v)", k, reflect.TypeOf(v.V))
|
2017-02-20 20:18:47 +01:00
|
|
|
}
|
|
|
|
b := v.BoolValue()
|
|
|
|
return &b, nil
|
|
|
|
} else if req {
|
|
|
|
return nil, &ReqError{k}
|
|
|
|
}
|
|
|
|
return nil, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// NumberOrErr checks that the given property has the type float64, issuing an error if not; req indicates if required.
|
|
|
|
func (m PropertyMap) NumberOrErr(k PropertyKey, req bool) (*float64, error) {
|
2017-02-20 22:27:31 +01:00
|
|
|
if v, has := m[k]; has && !v.IsNull() {
|
2017-02-20 20:18:47 +01:00
|
|
|
if !v.IsNumber() {
|
2017-04-19 23:46:50 +02:00
|
|
|
return nil, errors.Errorf("property '%v' is not a number (%v)", k, reflect.TypeOf(v.V))
|
2017-02-20 20:18:47 +01:00
|
|
|
}
|
|
|
|
n := v.NumberValue()
|
|
|
|
return &n, nil
|
|
|
|
} else if req {
|
|
|
|
return nil, &ReqError{k}
|
|
|
|
}
|
|
|
|
return nil, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// StringOrErr checks that the given property has the type string, issuing an error if not; req indicates if required.
|
|
|
|
func (m PropertyMap) StringOrErr(k PropertyKey, req bool) (*string, error) {
|
2017-02-20 22:27:31 +01:00
|
|
|
if v, has := m[k]; has && !v.IsNull() {
|
2017-02-20 20:18:47 +01:00
|
|
|
if !v.IsString() {
|
2017-04-19 23:46:50 +02:00
|
|
|
return nil, errors.Errorf("property '%v' is not a string (%v)", k, reflect.TypeOf(v.V))
|
2017-02-20 20:18:47 +01:00
|
|
|
}
|
|
|
|
s := v.StringValue()
|
|
|
|
return &s, nil
|
|
|
|
} else if req {
|
|
|
|
return nil, &ReqError{k}
|
|
|
|
}
|
|
|
|
return nil, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// ArrayOrErr checks that the given property has the type array, issuing an error if not; req indicates if required.
|
|
|
|
func (m PropertyMap) ArrayOrErr(k PropertyKey, req bool) (*[]PropertyValue, error) {
|
2017-02-20 22:27:31 +01:00
|
|
|
if v, has := m[k]; has && !v.IsNull() {
|
2017-02-20 20:18:47 +01:00
|
|
|
if !v.IsArray() {
|
2017-04-19 23:46:50 +02:00
|
|
|
return nil, errors.Errorf("property '%v' is not an array (%v)", k, reflect.TypeOf(v.V))
|
2017-02-20 20:18:47 +01:00
|
|
|
}
|
|
|
|
a := v.ArrayValue()
|
|
|
|
return &a, nil
|
|
|
|
} else if req {
|
|
|
|
return nil, &ReqError{k}
|
|
|
|
}
|
|
|
|
return nil, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// ObjectArrayOrErr ensures a property is an array of objects, issuing an error if not; req indicates if required.
|
|
|
|
func (m PropertyMap) ObjectArrayOrErr(k PropertyKey, req bool) (*[]PropertyMap, error) {
|
2017-02-20 22:27:31 +01:00
|
|
|
if v, has := m[k]; has && !v.IsNull() {
|
2017-02-20 20:18:47 +01:00
|
|
|
if !v.IsArray() {
|
2017-04-19 23:46:50 +02:00
|
|
|
return nil, errors.Errorf("property '%v' is not an array (%v)", k, reflect.TypeOf(v.V))
|
2017-02-20 20:18:47 +01:00
|
|
|
}
|
|
|
|
a := v.ArrayValue()
|
|
|
|
var objs []PropertyMap
|
|
|
|
for i, e := range a {
|
|
|
|
if e.IsObject() {
|
|
|
|
objs = append(objs, e.ObjectValue())
|
|
|
|
} else {
|
2017-04-19 23:46:50 +02:00
|
|
|
return nil, errors.Errorf(
|
2017-02-20 20:18:47 +01:00
|
|
|
"property '%v' array element %v is not an object (%v)", k, i, reflect.TypeOf(e))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return &objs, nil
|
|
|
|
} else if req {
|
|
|
|
return nil, &ReqError{k}
|
|
|
|
}
|
|
|
|
return nil, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// StringArrayOrErr ensures a property is an array of strings, issuing an error if not; req indicates if required.
|
|
|
|
func (m PropertyMap) StringArrayOrErr(k PropertyKey, req bool) (*[]string, error) {
|
2017-02-20 22:27:31 +01:00
|
|
|
if v, has := m[k]; has && !v.IsNull() {
|
2017-02-20 20:18:47 +01:00
|
|
|
if !v.IsArray() {
|
2017-04-19 23:46:50 +02:00
|
|
|
return nil, errors.Errorf("property '%v' is not an array (%v)", k, reflect.TypeOf(v.V))
|
2017-02-20 20:18:47 +01:00
|
|
|
}
|
|
|
|
a := v.ArrayValue()
|
|
|
|
var strs []string
|
|
|
|
for i, e := range a {
|
|
|
|
if e.IsString() {
|
|
|
|
strs = append(strs, e.StringValue())
|
|
|
|
} else {
|
2017-04-19 23:46:50 +02:00
|
|
|
return nil, errors.Errorf(
|
2017-02-20 20:18:47 +01:00
|
|
|
"property '%v' array element %v is not a string (%v)", k, i, reflect.TypeOf(e))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return &strs, nil
|
|
|
|
} else if req {
|
|
|
|
return nil, &ReqError{k}
|
|
|
|
}
|
|
|
|
return nil, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// ObjectOrErr checks that the given property is an object, issuing an error if not; req indicates if required.
|
|
|
|
func (m PropertyMap) ObjectOrErr(k PropertyKey, req bool) (*PropertyMap, error) {
|
2017-02-20 22:27:31 +01:00
|
|
|
if v, has := m[k]; has && !v.IsNull() {
|
2017-02-20 20:18:47 +01:00
|
|
|
if !v.IsObject() {
|
2017-04-19 23:46:50 +02:00
|
|
|
return nil, errors.Errorf("property '%v' is not an object (%v)", k, reflect.TypeOf(v.V))
|
2017-02-20 20:18:47 +01:00
|
|
|
}
|
|
|
|
o := v.ObjectValue()
|
|
|
|
return &o, nil
|
|
|
|
} else if req {
|
|
|
|
return nil, &ReqError{k}
|
|
|
|
}
|
|
|
|
return nil, nil
|
|
|
|
}
|
|
|
|
|
2017-05-25 22:19:20 +02:00
|
|
|
// ComputedOrErr checks that the given property is computed, issuing an error if not; req indicates if required.
|
|
|
|
func (m PropertyMap) ComputedOrErr(k PropertyKey, req bool) (*Computed, error) {
|
|
|
|
if v, has := m[k]; has && !v.IsNull() {
|
|
|
|
if !v.IsComputed() {
|
|
|
|
return nil, errors.Errorf("property '%v' is not an object (%v)", k, reflect.TypeOf(v.V))
|
|
|
|
}
|
|
|
|
m := v.ComputedValue()
|
|
|
|
return &m, nil
|
|
|
|
} else if req {
|
|
|
|
return nil, &ReqError{k}
|
|
|
|
}
|
|
|
|
return nil, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// OutputOrErr checks that the given property is an output, issuing an error if not; req indicates if required.
|
|
|
|
func (m PropertyMap) OutputOrErr(k PropertyKey, req bool) (*Output, error) {
|
Initial support for output properties (1 of 3)
This change includes approximately 1/3rd of the change necessary
to support output properties, as per pulumi/lumi#90.
In short, the runtime now has a new hidden type, Latent<T>, which
represents a "speculative" value, whose eventual type will be T,
that we can use during evaluation in various ways. Namely,
operations against Latent<T>s generally produce new Latent<U>s.
During planning, any Latent<T>s that end up in resource properties
are transformed into "unknown" property values. An unknown property
value is legal only during planning-time activities, such as Check,
Name, and InspectChange. As a result, those RPC interfaces have
been updated to include lookaside maps indicating which properties
have unknown values. My intent is to add some helper functions to
make dealing with this circumstance more correct-by-construction.
For now, using an unresolved Latent<T> in a conditional will lead
to an error. See pulumi/lumi#67. Speculating beyond these -- by
supporting iterative planning and application -- is something we
want to support eventually, but it makes sense to do that as an
additive change beyond this initial support. That is a missing 1/3.
Finally, the other missing 1/3rd which will happen much sooner
than the rest is restructuing plan application so that it will
correctly observe resolution of Latent<T> values. Right now, the
evaluation happens in one single pass, prior to the application, and
so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
|
|
|
if v, has := m[k]; has && !v.IsNull() {
|
2017-05-25 22:19:20 +02:00
|
|
|
if !v.IsOutput() {
|
Initial support for output properties (1 of 3)
This change includes approximately 1/3rd of the change necessary
to support output properties, as per pulumi/lumi#90.
In short, the runtime now has a new hidden type, Latent<T>, which
represents a "speculative" value, whose eventual type will be T,
that we can use during evaluation in various ways. Namely,
operations against Latent<T>s generally produce new Latent<U>s.
During planning, any Latent<T>s that end up in resource properties
are transformed into "unknown" property values. An unknown property
value is legal only during planning-time activities, such as Check,
Name, and InspectChange. As a result, those RPC interfaces have
been updated to include lookaside maps indicating which properties
have unknown values. My intent is to add some helper functions to
make dealing with this circumstance more correct-by-construction.
For now, using an unresolved Latent<T> in a conditional will lead
to an error. See pulumi/lumi#67. Speculating beyond these -- by
supporting iterative planning and application -- is something we
want to support eventually, but it makes sense to do that as an
additive change beyond this initial support. That is a missing 1/3.
Finally, the other missing 1/3rd which will happen much sooner
than the rest is restructuing plan application so that it will
correctly observe resolution of Latent<T> values. Right now, the
evaluation happens in one single pass, prior to the application, and
so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
|
|
|
return nil, errors.Errorf("property '%v' is not an object (%v)", k, reflect.TypeOf(v.V))
|
|
|
|
}
|
2017-05-25 22:19:20 +02:00
|
|
|
m := v.OutputValue()
|
Initial support for output properties (1 of 3)
This change includes approximately 1/3rd of the change necessary
to support output properties, as per pulumi/lumi#90.
In short, the runtime now has a new hidden type, Latent<T>, which
represents a "speculative" value, whose eventual type will be T,
that we can use during evaluation in various ways. Namely,
operations against Latent<T>s generally produce new Latent<U>s.
During planning, any Latent<T>s that end up in resource properties
are transformed into "unknown" property values. An unknown property
value is legal only during planning-time activities, such as Check,
Name, and InspectChange. As a result, those RPC interfaces have
been updated to include lookaside maps indicating which properties
have unknown values. My intent is to add some helper functions to
make dealing with this circumstance more correct-by-construction.
For now, using an unresolved Latent<T> in a conditional will lead
to an error. See pulumi/lumi#67. Speculating beyond these -- by
supporting iterative planning and application -- is something we
want to support eventually, but it makes sense to do that as an
additive change beyond this initial support. That is a missing 1/3.
Finally, the other missing 1/3rd which will happen much sooner
than the rest is restructuing plan application so that it will
correctly observe resolution of Latent<T> values. Right now, the
evaluation happens in one single pass, prior to the application, and
so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
|
|
|
return &m, nil
|
|
|
|
} else if req {
|
|
|
|
return nil, &ReqError{k}
|
|
|
|
}
|
|
|
|
return nil, nil
|
|
|
|
}
|
|
|
|
|
2017-02-20 20:18:47 +01:00
|
|
|
// ReqBoolOrErr checks that the given property exists and has the type bool.
|
|
|
|
func (m PropertyMap) ReqBoolOrErr(k PropertyKey) (bool, error) {
|
|
|
|
b, err := m.BoolOrErr(k, true)
|
|
|
|
if err != nil {
|
|
|
|
return false, err
|
|
|
|
}
|
|
|
|
return *b, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// ReqNumberOrErr checks that the given property exists and has the type float64.
|
|
|
|
func (m PropertyMap) ReqNumberOrErr(k PropertyKey) (float64, error) {
|
|
|
|
n, err := m.NumberOrErr(k, true)
|
|
|
|
if err != nil {
|
|
|
|
return 0, err
|
|
|
|
}
|
|
|
|
return *n, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// ReqStringOrErr checks that the given property exists and has the type string.
|
|
|
|
func (m PropertyMap) ReqStringOrErr(k PropertyKey) (string, error) {
|
|
|
|
s, err := m.StringOrErr(k, true)
|
|
|
|
if err != nil {
|
|
|
|
return "", err
|
|
|
|
}
|
|
|
|
return *s, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// ReqArrayOrErr checks that the given property exists and has the type array.
|
|
|
|
func (m PropertyMap) ReqArrayOrErr(k PropertyKey) ([]PropertyValue, error) {
|
|
|
|
a, err := m.ArrayOrErr(k, true)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
return *a, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// ReqObjectArrayOrErr checks that the given property exists and has the type array of objects.
|
|
|
|
func (m PropertyMap) ReqObjectArrayOrErr(k PropertyKey) ([]PropertyMap, error) {
|
|
|
|
a, err := m.ObjectArrayOrErr(k, true)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
return *a, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// ReqStringArrayOrErr checks that the given property exists and has the type array of objects.
|
|
|
|
func (m PropertyMap) ReqStringArrayOrErr(k PropertyKey) ([]string, error) {
|
|
|
|
a, err := m.StringArrayOrErr(k, true)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
return *a, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// ReqObjectOrErr checks that the given property exists and has the type object.
|
|
|
|
func (m PropertyMap) ReqObjectOrErr(k PropertyKey) (PropertyMap, error) {
|
|
|
|
o, err := m.ObjectOrErr(k, true)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
return *o, nil
|
|
|
|
}
|
|
|
|
|
2017-05-25 22:19:20 +02:00
|
|
|
// ReqComputedOrErr checks that the given property exists and is computed.
|
|
|
|
func (m PropertyMap) ReqComputedOrErr(k PropertyKey) (Computed, error) {
|
|
|
|
v, err := m.ComputedOrErr(k, true)
|
|
|
|
if err != nil {
|
|
|
|
return Computed{}, err
|
|
|
|
}
|
|
|
|
return *v, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// ReqOutputOrErr checks that the given property exists and is an output property.
|
|
|
|
func (m PropertyMap) ReqOutputOrErr(k PropertyKey) (Output, error) {
|
|
|
|
v, err := m.OutputOrErr(k, true)
|
Initial support for output properties (1 of 3)
This change includes approximately 1/3rd of the change necessary
to support output properties, as per pulumi/lumi#90.
In short, the runtime now has a new hidden type, Latent<T>, which
represents a "speculative" value, whose eventual type will be T,
that we can use during evaluation in various ways. Namely,
operations against Latent<T>s generally produce new Latent<U>s.
During planning, any Latent<T>s that end up in resource properties
are transformed into "unknown" property values. An unknown property
value is legal only during planning-time activities, such as Check,
Name, and InspectChange. As a result, those RPC interfaces have
been updated to include lookaside maps indicating which properties
have unknown values. My intent is to add some helper functions to
make dealing with this circumstance more correct-by-construction.
For now, using an unresolved Latent<T> in a conditional will lead
to an error. See pulumi/lumi#67. Speculating beyond these -- by
supporting iterative planning and application -- is something we
want to support eventually, but it makes sense to do that as an
additive change beyond this initial support. That is a missing 1/3.
Finally, the other missing 1/3rd which will happen much sooner
than the rest is restructuing plan application so that it will
correctly observe resolution of Latent<T> values. Right now, the
evaluation happens in one single pass, prior to the application, and
so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
|
|
|
if err != nil {
|
2017-05-25 22:19:20 +02:00
|
|
|
return Output{}, err
|
Initial support for output properties (1 of 3)
This change includes approximately 1/3rd of the change necessary
to support output properties, as per pulumi/lumi#90.
In short, the runtime now has a new hidden type, Latent<T>, which
represents a "speculative" value, whose eventual type will be T,
that we can use during evaluation in various ways. Namely,
operations against Latent<T>s generally produce new Latent<U>s.
During planning, any Latent<T>s that end up in resource properties
are transformed into "unknown" property values. An unknown property
value is legal only during planning-time activities, such as Check,
Name, and InspectChange. As a result, those RPC interfaces have
been updated to include lookaside maps indicating which properties
have unknown values. My intent is to add some helper functions to
make dealing with this circumstance more correct-by-construction.
For now, using an unresolved Latent<T> in a conditional will lead
to an error. See pulumi/lumi#67. Speculating beyond these -- by
supporting iterative planning and application -- is something we
want to support eventually, but it makes sense to do that as an
additive change beyond this initial support. That is a missing 1/3.
Finally, the other missing 1/3rd which will happen much sooner
than the rest is restructuing plan application so that it will
correctly observe resolution of Latent<T> values. Right now, the
evaluation happens in one single pass, prior to the application, and
so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
|
|
|
}
|
2017-05-25 22:19:20 +02:00
|
|
|
return *v, nil
|
Initial support for output properties (1 of 3)
This change includes approximately 1/3rd of the change necessary
to support output properties, as per pulumi/lumi#90.
In short, the runtime now has a new hidden type, Latent<T>, which
represents a "speculative" value, whose eventual type will be T,
that we can use during evaluation in various ways. Namely,
operations against Latent<T>s generally produce new Latent<U>s.
During planning, any Latent<T>s that end up in resource properties
are transformed into "unknown" property values. An unknown property
value is legal only during planning-time activities, such as Check,
Name, and InspectChange. As a result, those RPC interfaces have
been updated to include lookaside maps indicating which properties
have unknown values. My intent is to add some helper functions to
make dealing with this circumstance more correct-by-construction.
For now, using an unresolved Latent<T> in a conditional will lead
to an error. See pulumi/lumi#67. Speculating beyond these -- by
supporting iterative planning and application -- is something we
want to support eventually, but it makes sense to do that as an
additive change beyond this initial support. That is a missing 1/3.
Finally, the other missing 1/3rd which will happen much sooner
than the rest is restructuing plan application so that it will
correctly observe resolution of Latent<T> values. Right now, the
evaluation happens in one single pass, prior to the application, and
so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
|
|
|
}
|
|
|
|
|
2017-02-20 20:18:47 +01:00
|
|
|
// OptBoolOrErr checks that the given property has the type bool, if it exists.
|
|
|
|
func (m PropertyMap) OptBoolOrErr(k PropertyKey) (*bool, error) {
|
|
|
|
return m.BoolOrErr(k, false)
|
|
|
|
}
|
|
|
|
|
|
|
|
// OptNumberOrErr checks that the given property has the type float64, if it exists.
|
|
|
|
func (m PropertyMap) OptNumberOrErr(k PropertyKey) (*float64, error) {
|
|
|
|
return m.NumberOrErr(k, false)
|
|
|
|
}
|
|
|
|
|
|
|
|
// OptStringOrErr checks that the given property has the type string, if it exists.
|
|
|
|
func (m PropertyMap) OptStringOrErr(k PropertyKey) (*string, error) {
|
|
|
|
return m.StringOrErr(k, false)
|
|
|
|
}
|
|
|
|
|
|
|
|
// OptArrayOrErr checks that the given property has the type array, if it exists.
|
|
|
|
func (m PropertyMap) OptArrayOrErr(k PropertyKey) (*[]PropertyValue, error) {
|
|
|
|
return m.ArrayOrErr(k, false)
|
|
|
|
}
|
|
|
|
|
|
|
|
// OptObjectArrayOrErr checks that the given property has the type array of objects, if it exists.
|
|
|
|
func (m PropertyMap) OptObjectArrayOrErr(k PropertyKey) (*[]PropertyMap, error) {
|
|
|
|
return m.ObjectArrayOrErr(k, false)
|
|
|
|
}
|
|
|
|
|
|
|
|
// OptStringArrayOrErr checks that the given property has the type array of objects, if it exists.
|
|
|
|
func (m PropertyMap) OptStringArrayOrErr(k PropertyKey) (*[]string, error) {
|
|
|
|
return m.StringArrayOrErr(k, false)
|
|
|
|
}
|
|
|
|
|
|
|
|
// OptObjectOrErr checks that the given property has the type object, if it exists.
|
|
|
|
func (m PropertyMap) OptObjectOrErr(k PropertyKey) (*PropertyMap, error) {
|
|
|
|
return m.ObjectOrErr(k, false)
|
|
|
|
}
|
|
|
|
|
2017-05-25 22:19:20 +02:00
|
|
|
// OptComputedOrErr checks that the given property is computed, if it exists.
|
|
|
|
func (m PropertyMap) OptComputedOrErr(k PropertyKey) (*Computed, error) {
|
|
|
|
return m.ComputedOrErr(k, false)
|
|
|
|
}
|
|
|
|
|
|
|
|
// OptOutputOrErr checks that the given property is an output property, if it exists.
|
|
|
|
func (m PropertyMap) OptOutputOrErr(k PropertyKey) (*Output, error) {
|
|
|
|
return m.OutputOrErr(k, false)
|
Initial support for output properties (1 of 3)
This change includes approximately 1/3rd of the change necessary
to support output properties, as per pulumi/lumi#90.
In short, the runtime now has a new hidden type, Latent<T>, which
represents a "speculative" value, whose eventual type will be T,
that we can use during evaluation in various ways. Namely,
operations against Latent<T>s generally produce new Latent<U>s.
During planning, any Latent<T>s that end up in resource properties
are transformed into "unknown" property values. An unknown property
value is legal only during planning-time activities, such as Check,
Name, and InspectChange. As a result, those RPC interfaces have
been updated to include lookaside maps indicating which properties
have unknown values. My intent is to add some helper functions to
make dealing with this circumstance more correct-by-construction.
For now, using an unresolved Latent<T> in a conditional will lead
to an error. See pulumi/lumi#67. Speculating beyond these -- by
supporting iterative planning and application -- is something we
want to support eventually, but it makes sense to do that as an
additive change beyond this initial support. That is a missing 1/3.
Finally, the other missing 1/3rd which will happen much sooner
than the rest is restructuing plan application so that it will
correctly observe resolution of Latent<T> values. Right now, the
evaluation happens in one single pass, prior to the application, and
so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
|
|
|
}
|
|
|
|
|
2017-06-05 04:24:48 +02:00
|
|
|
// HasValue returns true if the slot associated with the given property key contains a real value. It returns false
|
|
|
|
// if a value is null or an output property that is awaiting a value to be assigned. That is to say, HasValue indicates
|
|
|
|
// a semantically meaningful value is present (even if it's a computed one whose concrete value isn't yet evaluated).
|
|
|
|
func (m PropertyMap) HasValue(k PropertyKey) bool {
|
2017-06-01 19:09:52 +02:00
|
|
|
v, has := m[k]
|
2017-06-05 04:24:48 +02:00
|
|
|
return has && v.HasValue()
|
2017-06-01 19:09:52 +02:00
|
|
|
}
|
|
|
|
|
2017-03-12 22:13:44 +01:00
|
|
|
// Mappable returns a mapper-compatible object map, suitable for deserialization into structures.
|
Implement mapper.Encode "for real"
This change implements `mapper.Encode` "for real" (that is, in a way
that isn't a complete embarrassment). It uses the obvious reflection
trickery to encode a tagged struct and its values as a JSON-like
in-memory map and collection of keyed values.
During this, I took the opportunity to also clean up a few other things
that had been bugging me. Namely, the presence of `mapper.Object` was
always error prone, since it isn't a true "typedef" in the sence that
it carries extra RTTI. Instead of doing that, let's just use the real
`map[string]interface{}` "JSON-map-like" object type. Even better, we
no longer require resource providers to deal with the mapper
infrastructure. Instead, the `Check` function can simply return an
array of errors. It's still best practice to return field-specific errors
to facilitate better diagnostics, but it's no longer required; and I've
added `resource.NewFieldError` to eliminate the need to import mapper.
As of this change, we can also consistently emit RPC structs with `lumi`
tags, rather than `lumi` tags on the way in and `json` on the way out.
This completes pulumi/lumi#183.
2017-06-06 02:43:52 +02:00
|
|
|
func (m PropertyMap) Mappable() map[string]interface{} {
|
2017-07-01 21:08:55 +02:00
|
|
|
return m.MapReplace(nil)
|
|
|
|
}
|
|
|
|
|
|
|
|
// MapReplace returns a mapper-compatible object map, suitable for deserialization into structures. A replace function
|
|
|
|
// repl may be passed that will replace elements using custom logic if appropriate.
|
|
|
|
func (m PropertyMap) MapReplace(repl func(PropertyValue) (interface{}, bool)) map[string]interface{} {
|
Implement mapper.Encode "for real"
This change implements `mapper.Encode` "for real" (that is, in a way
that isn't a complete embarrassment). It uses the obvious reflection
trickery to encode a tagged struct and its values as a JSON-like
in-memory map and collection of keyed values.
During this, I took the opportunity to also clean up a few other things
that had been bugging me. Namely, the presence of `mapper.Object` was
always error prone, since it isn't a true "typedef" in the sence that
it carries extra RTTI. Instead of doing that, let's just use the real
`map[string]interface{}` "JSON-map-like" object type. Even better, we
no longer require resource providers to deal with the mapper
infrastructure. Instead, the `Check` function can simply return an
array of errors. It's still best practice to return field-specific errors
to facilitate better diagnostics, but it's no longer required; and I've
added `resource.NewFieldError` to eliminate the need to import mapper.
As of this change, we can also consistently emit RPC structs with `lumi`
tags, rather than `lumi` tags on the way in and `json` on the way out.
This completes pulumi/lumi#183.
2017-06-06 02:43:52 +02:00
|
|
|
obj := make(map[string]interface{})
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
for _, k := range m.StableKeys() {
|
2017-07-01 21:08:55 +02:00
|
|
|
obj[string(k)] = m[k].MapReplace(repl)
|
2017-03-12 22:13:44 +01:00
|
|
|
}
|
|
|
|
return obj
|
|
|
|
}
|
|
|
|
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
// StableKeys returns all of the map's keys in a stable order.
|
|
|
|
func (m PropertyMap) StableKeys() []PropertyKey {
|
|
|
|
sorted := make([]PropertyKey, 0, len(m))
|
|
|
|
for k := range m {
|
|
|
|
sorted = append(sorted, k)
|
|
|
|
}
|
|
|
|
sort.Slice(sorted, func(i, j int) bool { return sorted[i] < sorted[j] })
|
|
|
|
return sorted
|
|
|
|
}
|
|
|
|
|
2017-06-01 17:23:59 +02:00
|
|
|
func (m PropertyMap) ShallowClone() PropertyMap {
|
|
|
|
copy := make(PropertyMap)
|
2017-06-05 04:24:48 +02:00
|
|
|
m.ShallowCloneInto(copy)
|
|
|
|
return copy
|
|
|
|
}
|
|
|
|
|
|
|
|
func (m PropertyMap) ShallowCloneInto(other PropertyMap) {
|
2017-06-01 17:23:59 +02:00
|
|
|
for k, v := range m {
|
2017-06-05 04:24:48 +02:00
|
|
|
other[k] = v
|
2017-06-01 17:23:59 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func (s PropertySet) ShallowClone() PropertySet {
|
|
|
|
copy := make(PropertySet)
|
|
|
|
for k, v := range s {
|
|
|
|
copy[k] = v
|
|
|
|
}
|
|
|
|
return copy
|
|
|
|
}
|
|
|
|
|
2017-05-25 22:19:20 +02:00
|
|
|
func NewNullProperty() PropertyValue { return PropertyValue{nil} }
|
|
|
|
func NewBoolProperty(v bool) PropertyValue { return PropertyValue{v} }
|
|
|
|
func NewNumberProperty(v float64) PropertyValue { return PropertyValue{v} }
|
|
|
|
func NewStringProperty(v string) PropertyValue { return PropertyValue{v} }
|
|
|
|
func NewArrayProperty(v []PropertyValue) PropertyValue { return PropertyValue{v} }
|
|
|
|
func NewObjectProperty(v PropertyMap) PropertyValue { return PropertyValue{v} }
|
|
|
|
func NewComputedProperty(v Computed) PropertyValue { return PropertyValue{v} }
|
|
|
|
func NewOutputProperty(v Output) PropertyValue { return PropertyValue{v} }
|
|
|
|
|
2017-06-10 03:34:37 +02:00
|
|
|
func MakeComputed(v PropertyValue) PropertyValue {
|
|
|
|
return NewComputedProperty(Computed{Element: v})
|
2017-06-08 15:44:21 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
func MakeOutput(v PropertyValue) PropertyValue {
|
2017-06-08 15:48:23 +02:00
|
|
|
return NewOutputProperty(Output{Element: v})
|
2017-06-08 15:44:21 +02:00
|
|
|
}
|
2017-02-20 20:18:47 +01:00
|
|
|
|
2017-04-22 00:27:32 +02:00
|
|
|
// NewPropertyValue turns a value into a property value, provided it is of a legal "JSON-like" kind.
|
|
|
|
func NewPropertyValue(v interface{}) PropertyValue {
|
|
|
|
// If nil, easy peasy, just return a null.
|
|
|
|
if v == nil {
|
2017-05-25 22:19:20 +02:00
|
|
|
return NewNullProperty()
|
2017-04-22 00:27:32 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// Else, check for some known primitive types.
|
|
|
|
switch t := v.(type) {
|
|
|
|
case bool:
|
2017-05-25 22:19:20 +02:00
|
|
|
return NewBoolProperty(t)
|
2017-04-22 00:27:32 +02:00
|
|
|
case float64:
|
2017-05-25 22:19:20 +02:00
|
|
|
return NewNumberProperty(t)
|
2017-04-22 00:27:32 +02:00
|
|
|
case string:
|
2017-05-25 22:19:20 +02:00
|
|
|
return NewStringProperty(t)
|
|
|
|
case Computed:
|
|
|
|
return NewComputedProperty(t)
|
2017-04-22 00:27:32 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// Next, see if it's an array, slice, pointer or struct, and handle each accordingly.
|
|
|
|
rv := reflect.ValueOf(v)
|
|
|
|
switch rk := rv.Type().Kind(); rk {
|
|
|
|
case reflect.Array, reflect.Slice:
|
|
|
|
// If an array or slice, just create an array out of it.
|
|
|
|
var arr []PropertyValue
|
|
|
|
for i := 0; i < rv.Len(); i++ {
|
|
|
|
elem := rv.Index(i)
|
|
|
|
arr = append(arr, NewPropertyValue(elem.Interface()))
|
|
|
|
}
|
2017-05-25 22:19:20 +02:00
|
|
|
return NewArrayProperty(arr)
|
2017-04-22 00:27:32 +02:00
|
|
|
case reflect.Ptr:
|
|
|
|
// If a pointer, recurse and return the underlying value.
|
2017-04-25 23:04:22 +02:00
|
|
|
if rv.IsNil() {
|
2017-05-25 22:19:20 +02:00
|
|
|
return NewNullProperty()
|
2017-04-25 23:04:22 +02:00
|
|
|
}
|
2017-05-14 02:04:35 +02:00
|
|
|
return NewPropertyValue(rv.Elem().Interface())
|
2017-05-30 19:55:53 +02:00
|
|
|
case reflect.Map:
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
// If a map, create a new property map, provided the keys and values are okay.
|
|
|
|
obj := PropertyMap{}
|
|
|
|
for _, key := range rv.MapKeys() {
|
|
|
|
var pk PropertyKey
|
|
|
|
switch k := key.Interface().(type) {
|
|
|
|
case string:
|
|
|
|
pk = PropertyKey(k)
|
|
|
|
case PropertyKey:
|
|
|
|
pk = k
|
|
|
|
default:
|
|
|
|
contract.Failf("Unrecognized PropertyMap key type: %v", reflect.TypeOf(key))
|
|
|
|
}
|
|
|
|
val := rv.MapIndex(key)
|
|
|
|
pv := NewPropertyValue(val.Interface())
|
|
|
|
obj[pk] = pv
|
2017-05-30 19:55:53 +02:00
|
|
|
}
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
return NewObjectProperty(obj)
|
2017-05-25 22:19:20 +02:00
|
|
|
case reflect.Struct:
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
obj := NewPropertyMap(v)
|
2017-06-01 17:51:33 +02:00
|
|
|
return NewObjectProperty(obj)
|
2017-04-22 00:27:32 +02:00
|
|
|
default:
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
contract.Failf("Unrecognized value type: type=%v kind=%v", rv.Type(), rk)
|
2017-04-22 00:27:32 +02:00
|
|
|
}
|
|
|
|
|
2017-05-25 22:19:20 +02:00
|
|
|
return NewNullProperty()
|
2017-04-22 00:27:32 +02:00
|
|
|
}
|
|
|
|
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
// BoolValue fetches the underlying bool value (panicking if it isn't a bool).
|
|
|
|
func (v PropertyValue) BoolValue() bool { return v.V.(bool) }
|
|
|
|
|
|
|
|
// NumberValue fetches the underlying number value (panicking if it isn't a number).
|
|
|
|
func (v PropertyValue) NumberValue() float64 { return v.V.(float64) }
|
|
|
|
|
|
|
|
// StringValue fetches the underlying string value (panicking if it isn't a string).
|
|
|
|
func (v PropertyValue) StringValue() string { return v.V.(string) }
|
|
|
|
|
|
|
|
// ArrayValue fetches the underlying array value (panicking if it isn't a array).
|
2017-02-20 20:18:47 +01:00
|
|
|
func (v PropertyValue) ArrayValue() []PropertyValue { return v.V.([]PropertyValue) }
|
|
|
|
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
// ObjectValue fetches the underlying object value (panicking if it isn't a object).
|
|
|
|
func (v PropertyValue) ObjectValue() PropertyMap { return v.V.(PropertyMap) }
|
|
|
|
|
|
|
|
// ComputedValue fetches the underlying computed value (panicking if it isn't a computed).
|
|
|
|
func (v PropertyValue) ComputedValue() Computed { return v.V.(Computed) }
|
|
|
|
|
|
|
|
// OutputValue fetches the underlying output value (panicking if it isn't a output).
|
|
|
|
func (v PropertyValue) OutputValue() Output { return v.V.(Output) }
|
|
|
|
|
|
|
|
// IsNull returns true if the underlying value is a null.
|
2017-04-08 16:44:02 +02:00
|
|
|
func (v PropertyValue) IsNull() bool {
|
|
|
|
return v.V == nil
|
2017-02-20 20:18:47 +01:00
|
|
|
}
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
|
|
|
|
// IsBool returns true if the underlying value is a bool.
|
2017-04-08 16:44:02 +02:00
|
|
|
func (v PropertyValue) IsBool() bool {
|
|
|
|
_, is := v.V.(bool)
|
2017-02-20 20:18:47 +01:00
|
|
|
return is
|
|
|
|
}
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
|
|
|
|
// IsNumber returns true if the underlying value is a number.
|
2017-04-08 16:44:02 +02:00
|
|
|
func (v PropertyValue) IsNumber() bool {
|
|
|
|
_, is := v.V.(float64)
|
2017-02-20 20:18:47 +01:00
|
|
|
return is
|
|
|
|
}
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
|
|
|
|
// IsString returns true if the underlying value is a string.
|
2017-04-08 16:44:02 +02:00
|
|
|
func (v PropertyValue) IsString() bool {
|
|
|
|
_, is := v.V.(string)
|
2017-02-20 20:18:47 +01:00
|
|
|
return is
|
|
|
|
}
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
|
|
|
|
// IsArray returns true if the underlying value is an array.
|
2017-04-08 16:44:02 +02:00
|
|
|
func (v PropertyValue) IsArray() bool {
|
|
|
|
_, is := v.V.([]PropertyValue)
|
2017-02-20 20:18:47 +01:00
|
|
|
return is
|
|
|
|
}
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
|
|
|
|
// IsObject returns true if the underlying value is an object.
|
2017-04-08 16:44:02 +02:00
|
|
|
func (v PropertyValue) IsObject() bool {
|
|
|
|
_, is := v.V.(PropertyMap)
|
2017-02-20 20:18:47 +01:00
|
|
|
return is
|
|
|
|
}
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
|
|
|
|
// IsComputed returns true if the underlying value is a computed value.
|
2017-05-25 22:19:20 +02:00
|
|
|
func (v PropertyValue) IsComputed() bool {
|
|
|
|
_, is := v.V.(Computed)
|
|
|
|
return is
|
|
|
|
}
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
|
|
|
|
// IsOutput returns true if the underlying value is an output value.
|
2017-05-25 22:19:20 +02:00
|
|
|
func (v PropertyValue) IsOutput() bool {
|
|
|
|
_, is := v.V.(Output)
|
Initial support for output properties (1 of 3)
This change includes approximately 1/3rd of the change necessary
to support output properties, as per pulumi/lumi#90.
In short, the runtime now has a new hidden type, Latent<T>, which
represents a "speculative" value, whose eventual type will be T,
that we can use during evaluation in various ways. Namely,
operations against Latent<T>s generally produce new Latent<U>s.
During planning, any Latent<T>s that end up in resource properties
are transformed into "unknown" property values. An unknown property
value is legal only during planning-time activities, such as Check,
Name, and InspectChange. As a result, those RPC interfaces have
been updated to include lookaside maps indicating which properties
have unknown values. My intent is to add some helper functions to
make dealing with this circumstance more correct-by-construction.
For now, using an unresolved Latent<T> in a conditional will lead
to an error. See pulumi/lumi#67. Speculating beyond these -- by
supporting iterative planning and application -- is something we
want to support eventually, but it makes sense to do that as an
additive change beyond this initial support. That is a missing 1/3.
Finally, the other missing 1/3rd which will happen much sooner
than the rest is restructuing plan application so that it will
correctly observe resolution of Latent<T> values. Right now, the
evaluation happens in one single pass, prior to the application, and
so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
|
|
|
return is
|
|
|
|
}
|
|
|
|
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
// CanNull returns true if the target property is capable of holding a null value.
|
|
|
|
func (v PropertyValue) CanNull() bool {
|
|
|
|
return true // all properties can be null
|
|
|
|
}
|
|
|
|
|
|
|
|
// CanBool returns true if the target property is capable of holding a bool value.
|
|
|
|
func (v PropertyValue) CanBool() bool {
|
|
|
|
if v.IsNull() || v.IsBool() {
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
if v.IsComputed() {
|
2017-06-08 15:48:23 +02:00
|
|
|
return v.ComputedValue().Element.CanBool()
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
}
|
|
|
|
if v.IsOutput() {
|
2017-06-08 15:48:23 +02:00
|
|
|
return v.OutputValue().Element.CanBool()
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
}
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
|
|
|
// CanNumber returns true if the target property is capable of holding a number value.
|
|
|
|
func (v PropertyValue) CanNumber() bool {
|
|
|
|
if v.IsNull() || v.IsNumber() {
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
if v.IsComputed() {
|
2017-06-08 15:48:23 +02:00
|
|
|
return v.ComputedValue().Element.CanNumber()
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
}
|
|
|
|
if v.IsOutput() {
|
2017-06-08 15:48:23 +02:00
|
|
|
return v.OutputValue().Element.CanNumber()
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
}
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
|
|
|
// CanString returns true if the target property is capable of holding a string value.
|
|
|
|
func (v PropertyValue) CanString() bool {
|
|
|
|
if v.IsNull() || v.IsString() {
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
if v.IsComputed() {
|
2017-06-08 15:48:23 +02:00
|
|
|
return v.ComputedValue().Element.CanString()
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
}
|
|
|
|
if v.IsOutput() {
|
2017-06-08 15:48:23 +02:00
|
|
|
return v.OutputValue().Element.CanString()
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
}
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
|
|
|
// CanArray returns true if the target property is capable of holding an array value.
|
|
|
|
func (v PropertyValue) CanArray() bool {
|
|
|
|
if v.IsNull() || v.IsArray() {
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
if v.IsComputed() {
|
2017-06-08 15:48:23 +02:00
|
|
|
return v.ComputedValue().Element.CanArray()
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
}
|
|
|
|
if v.IsOutput() {
|
2017-06-08 15:48:23 +02:00
|
|
|
return v.OutputValue().Element.CanArray()
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
}
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
|
|
|
// CanObject returns true if the target property is capable of holding an object value.
|
|
|
|
func (v PropertyValue) CanObject() bool {
|
|
|
|
if v.IsNull() || v.IsObject() {
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
if v.IsComputed() {
|
2017-06-08 15:48:23 +02:00
|
|
|
return v.ComputedValue().Element.CanObject()
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
}
|
|
|
|
if v.IsOutput() {
|
2017-06-08 15:48:23 +02:00
|
|
|
return v.OutputValue().Element.CanObject()
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
}
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
2017-06-05 04:24:48 +02:00
|
|
|
// HasValue returns true if a value is semantically meaningful.
|
|
|
|
func (v PropertyValue) HasValue() bool {
|
|
|
|
return !v.IsNull() && !v.IsOutput()
|
|
|
|
}
|
|
|
|
|
Unmap properties on the receive side
This change makes progress on a few things with respect to properly
receiving properties on the engine side, coming from the provider side,
of the RPC boundary. The issues here are twofold:
1. Properties need to get unmapped using a JSON-tag-sensitive
marshaler, so that they are cased properly, etc. For that, we
have a new mapper.Unmap function (which is ultra lame -- see
pulumi/lumi#138).
2. We have the reverse problem with respect to resource IDs: on
the send side, we must translate from URNs (which the engine
knows about) and provider IDs (which the provider knows about);
similarly, then, on the receive side, we must translate from
provider IDs back into URNs.
As a result of these getting fixed, we can now properly marshal the
resulting properties back into the resource object during the plan
execution, alongside propagating and memoizing its ID.
2017-05-31 20:51:46 +02:00
|
|
|
// TypeString returns a type representation of the property value's holder type.
|
Initial support for output properties (1 of 3)
This change includes approximately 1/3rd of the change necessary
to support output properties, as per pulumi/lumi#90.
In short, the runtime now has a new hidden type, Latent<T>, which
represents a "speculative" value, whose eventual type will be T,
that we can use during evaluation in various ways. Namely,
operations against Latent<T>s generally produce new Latent<U>s.
During planning, any Latent<T>s that end up in resource properties
are transformed into "unknown" property values. An unknown property
value is legal only during planning-time activities, such as Check,
Name, and InspectChange. As a result, those RPC interfaces have
been updated to include lookaside maps indicating which properties
have unknown values. My intent is to add some helper functions to
make dealing with this circumstance more correct-by-construction.
For now, using an unresolved Latent<T> in a conditional will lead
to an error. See pulumi/lumi#67. Speculating beyond these -- by
supporting iterative planning and application -- is something we
want to support eventually, but it makes sense to do that as an
additive change beyond this initial support. That is a missing 1/3.
Finally, the other missing 1/3rd which will happen much sooner
than the rest is restructuing plan application so that it will
correctly observe resolution of Latent<T> values. Right now, the
evaluation happens in one single pass, prior to the application, and
so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
|
|
|
func (v PropertyValue) TypeString() string {
|
|
|
|
if v.IsNull() {
|
|
|
|
return "null"
|
|
|
|
} else if v.IsBool() {
|
|
|
|
return "bool"
|
|
|
|
} else if v.IsNumber() {
|
|
|
|
return "number"
|
|
|
|
} else if v.IsString() {
|
|
|
|
return "string"
|
|
|
|
} else if v.IsArray() {
|
|
|
|
return "[]"
|
|
|
|
} else if v.IsObject() {
|
|
|
|
return "object"
|
2017-05-25 22:19:20 +02:00
|
|
|
} else if v.IsComputed() {
|
2017-06-08 15:48:23 +02:00
|
|
|
return "computed<" + v.ComputedValue().Element.TypeString() + ">"
|
2017-05-25 22:19:20 +02:00
|
|
|
} else if v.IsOutput() {
|
2017-06-08 15:48:23 +02:00
|
|
|
return "output<" + v.OutputValue().Element.TypeString() + ">"
|
Initial support for output properties (1 of 3)
This change includes approximately 1/3rd of the change necessary
to support output properties, as per pulumi/lumi#90.
In short, the runtime now has a new hidden type, Latent<T>, which
represents a "speculative" value, whose eventual type will be T,
that we can use during evaluation in various ways. Namely,
operations against Latent<T>s generally produce new Latent<U>s.
During planning, any Latent<T>s that end up in resource properties
are transformed into "unknown" property values. An unknown property
value is legal only during planning-time activities, such as Check,
Name, and InspectChange. As a result, those RPC interfaces have
been updated to include lookaside maps indicating which properties
have unknown values. My intent is to add some helper functions to
make dealing with this circumstance more correct-by-construction.
For now, using an unresolved Latent<T> in a conditional will lead
to an error. See pulumi/lumi#67. Speculating beyond these -- by
supporting iterative planning and application -- is something we
want to support eventually, but it makes sense to do that as an
additive change beyond this initial support. That is a missing 1/3.
Finally, the other missing 1/3rd which will happen much sooner
than the rest is restructuing plan application so that it will
correctly observe resolution of Latent<T> values. Right now, the
evaluation happens in one single pass, prior to the application, and
so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
|
|
|
}
|
|
|
|
contract.Failf("Unrecognized PropertyValue type")
|
|
|
|
return ""
|
|
|
|
}
|
Implement updates
This change is a first whack at implementing updates.
Creation and deletion plans are pretty straightforward; we just take
a single graph, topologically sort it, and perform the operations in
the right order. For creation, this is in dependency order (things
that are depended upon must be created before dependents); for deletion,
this is in reverse-dependency order (things that depend on others must
be deleted before dependencies). These are just special cases of the more
general idea of performing DAG operations in dependency order.
Updates must work in terms of this more general notion. For example:
* It is an error to delete a resource while another refers to it; thus,
resources are deleted after deleting dependents, or after updating
dependent properties that reference the resource to new values.
* It is an error to depend on a create a resource before it is created;
thus, resources must be created before dependents are created, and/or
before updates to existing resource properties that would cause them
to refer to the new resource.
Of course, all of this is tangled up in a graph of dependencies. As a
result, we must create a DAG of the dependencies between creates, updates,
and deletes, and then topologically sort this DAG, in order to determine
the proper order of update operations.
To do this, we slightly generalize the existing graph infrastructure,
while also specializing two kinds of graphs; the existing one becomes a
heapstate.ObjectGraph, while this new one is resource.planGraph (internal).
2017-02-23 23:56:23 +01:00
|
|
|
|
2017-03-12 22:13:44 +01:00
|
|
|
// Mappable returns a mapper-compatible value, suitable for deserialization into structures.
|
Implement mapper.Encode "for real"
This change implements `mapper.Encode` "for real" (that is, in a way
that isn't a complete embarrassment). It uses the obvious reflection
trickery to encode a tagged struct and its values as a JSON-like
in-memory map and collection of keyed values.
During this, I took the opportunity to also clean up a few other things
that had been bugging me. Namely, the presence of `mapper.Object` was
always error prone, since it isn't a true "typedef" in the sence that
it carries extra RTTI. Instead of doing that, let's just use the real
`map[string]interface{}` "JSON-map-like" object type. Even better, we
no longer require resource providers to deal with the mapper
infrastructure. Instead, the `Check` function can simply return an
array of errors. It's still best practice to return field-specific errors
to facilitate better diagnostics, but it's no longer required; and I've
added `resource.NewFieldError` to eliminate the need to import mapper.
As of this change, we can also consistently emit RPC structs with `lumi`
tags, rather than `lumi` tags on the way in and `json` on the way out.
This completes pulumi/lumi#183.
2017-06-06 02:43:52 +02:00
|
|
|
func (v PropertyValue) Mappable() interface{} {
|
2017-07-01 21:08:55 +02:00
|
|
|
return v.MapReplace(nil)
|
|
|
|
}
|
|
|
|
|
|
|
|
// MapReplace returns a mapper-compatible object map, suitable for deserialization into structures. A replace function
|
|
|
|
// repl may be passed that will replace elements using custom logic if appropriate.
|
|
|
|
func (v PropertyValue) MapReplace(repl func(PropertyValue) (interface{}, bool)) interface{} {
|
|
|
|
if repl != nil {
|
|
|
|
if vret, vrep := repl(v); vrep {
|
|
|
|
return vret
|
|
|
|
}
|
|
|
|
}
|
2017-03-12 22:13:44 +01:00
|
|
|
if v.IsNull() {
|
|
|
|
return nil
|
|
|
|
} else if v.IsBool() {
|
|
|
|
return v.BoolValue()
|
|
|
|
} else if v.IsNumber() {
|
|
|
|
return v.NumberValue()
|
|
|
|
} else if v.IsString() {
|
|
|
|
return v.StringValue()
|
|
|
|
} else if v.IsArray() {
|
Implement mapper.Encode "for real"
This change implements `mapper.Encode` "for real" (that is, in a way
that isn't a complete embarrassment). It uses the obvious reflection
trickery to encode a tagged struct and its values as a JSON-like
in-memory map and collection of keyed values.
During this, I took the opportunity to also clean up a few other things
that had been bugging me. Namely, the presence of `mapper.Object` was
always error prone, since it isn't a true "typedef" in the sence that
it carries extra RTTI. Instead of doing that, let's just use the real
`map[string]interface{}` "JSON-map-like" object type. Even better, we
no longer require resource providers to deal with the mapper
infrastructure. Instead, the `Check` function can simply return an
array of errors. It's still best practice to return field-specific errors
to facilitate better diagnostics, but it's no longer required; and I've
added `resource.NewFieldError` to eliminate the need to import mapper.
As of this change, we can also consistently emit RPC structs with `lumi`
tags, rather than `lumi` tags on the way in and `json` on the way out.
This completes pulumi/lumi#183.
2017-06-06 02:43:52 +02:00
|
|
|
var arr []interface{}
|
2017-03-12 22:13:44 +01:00
|
|
|
for _, e := range v.ArrayValue() {
|
2017-07-01 21:08:55 +02:00
|
|
|
arr = append(arr, e.MapReplace(repl))
|
2017-03-12 22:13:44 +01:00
|
|
|
}
|
|
|
|
return arr
|
|
|
|
}
|
2017-04-08 16:44:02 +02:00
|
|
|
contract.Assert(v.IsObject())
|
2017-07-01 21:08:55 +02:00
|
|
|
return v.ObjectValue().MapReplace(repl)
|
2017-03-12 22:13:44 +01:00
|
|
|
}
|
|
|
|
|
2017-06-01 17:23:59 +02:00
|
|
|
// String implements the fmt.Stringer interface to add slightly more information to the output.
|
|
|
|
func (v PropertyValue) String() string {
|
|
|
|
if v.IsComputed() || v.IsOutput() {
|
|
|
|
// For computed and output properties, show their type followed by an empty object string.
|
|
|
|
return fmt.Sprintf("%v{}", v.TypeString())
|
|
|
|
}
|
|
|
|
// For all others, just display the underlying property value.
|
|
|
|
return fmt.Sprintf("{%v}", v.V)
|
|
|
|
}
|