2022-07-18 13:36:31 +00:00
|
|
|
// Copyright 2016-2022, Pulumi Corporation.
|
2018-05-22 19:43:36 +00:00
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
// you may not use this file except in compliance with the License.
|
|
|
|
// You may obtain a copy of the License at
|
|
|
|
//
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
//
|
|
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
// See the License for the specific language governing permissions and
|
|
|
|
// limitations under the License.
|
2017-02-22 02:31:43 +00:00
|
|
|
|
2017-10-16 19:04:35 +00:00
|
|
|
package stack
|
2017-02-22 02:31:43 +00:00
|
|
|
|
|
|
|
import (
|
2022-07-18 13:36:31 +00:00
|
|
|
"context"
|
2018-05-25 20:29:59 +00:00
|
|
|
"encoding/json"
|
2021-11-13 02:37:17 +00:00
|
|
|
"errors"
|
2018-05-25 20:29:59 +00:00
|
|
|
"fmt"
|
2021-09-22 04:37:06 +00:00
|
|
|
"io"
|
2017-02-22 22:32:03 +00:00
|
|
|
"reflect"
|
2021-09-22 04:37:06 +00:00
|
|
|
"strings"
|
2017-02-22 22:32:03 +00:00
|
|
|
|
2021-03-17 13:20:05 +00:00
|
|
|
"github.com/pulumi/pulumi/pkg/v3/resource/deploy"
|
|
|
|
"github.com/pulumi/pulumi/pkg/v3/secrets"
|
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/apitype"
|
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/apitype/migrate"
|
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/resource"
|
Move assets and archives to their own package (#15157)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
This PR is motivated by https://github.com/pulumi/pulumi/pull/15145.
`resource.*` should be built on top of `property.Value`,[^1] which means
that `resource`
needs to be able to import `property.Value`, and so `property` cannot
import
`resource`. Since Assets and Archives are both types of properties, they
must be moved out
of `resource`.
[^1]: For example:
https://github.com/pulumi/pulumi/blob/a1d686227cd7e3c70c51bd772450cb0cd57c1479/sdk/go/common/resource/resource_state.go#L35-L36
## Open Question
This PR moves them to their own sub-folders in `resource`. Should
`asset` and `archive`
live somewhere more high level, like `sdk/go/property/{asset,archive}`?
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
## Checklist
- [ ] I have run `make tidy` to update any new dependencies
- [ ] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2024-01-25 20:39:31 +00:00
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/resource/archive"
|
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/resource/asset"
|
2021-03-17 13:20:05 +00:00
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/resource/config"
|
2023-06-28 16:02:04 +00:00
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/slice"
|
2021-03-17 13:20:05 +00:00
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/util/contract"
|
2021-09-22 04:37:06 +00:00
|
|
|
"github.com/santhosh-tekuri/jsonschema/v5"
|
2017-02-22 02:31:43 +00:00
|
|
|
)
|
|
|
|
|
2018-05-25 20:29:59 +00:00
|
|
|
const (
|
|
|
|
// DeploymentSchemaVersionOldestSupported is the oldest deployment schema that we
|
|
|
|
// still support, i.e. we can produce a `deploy.Snapshot` from. This will generally
|
|
|
|
// need to be at least one less than the current schema version so that old deployments can
|
|
|
|
// be migrated to the current schema.
|
|
|
|
DeploymentSchemaVersionOldestSupported = 1
|
2019-11-21 22:58:30 +00:00
|
|
|
|
|
|
|
// computedValue is a magic number we emit for a value of a resource.Property value
|
|
|
|
// whenever we need to serialize a resource.Computed. (Since the real/actual value
|
|
|
|
// is not known.) This allows us to persist engine events and resource states that
|
|
|
|
// indicate a value will changed... but is unknown what it will change to.
|
|
|
|
computedValuePlaceholder = "04da6b54-80e4-46f7-96ec-b56ff0331ba9"
|
2018-05-25 20:29:59 +00:00
|
|
|
)
|
|
|
|
|
|
|
|
var (
|
|
|
|
// ErrDeploymentSchemaVersionTooOld is returned from `DeserializeDeployment` if the
|
|
|
|
// untyped deployment being deserialized is too old to understand.
|
2023-12-12 12:19:42 +00:00
|
|
|
ErrDeploymentSchemaVersionTooOld = errors.New("this stack's deployment is too old")
|
2018-05-25 20:29:59 +00:00
|
|
|
|
|
|
|
// ErrDeploymentSchemaVersionTooNew is returned from `DeserializeDeployment` if the
|
|
|
|
// untyped deployment being deserialized is too new to understand.
|
2023-12-12 12:19:42 +00:00
|
|
|
ErrDeploymentSchemaVersionTooNew = errors.New("this stack's deployment version is too new")
|
2018-05-25 20:29:59 +00:00
|
|
|
)
|
|
|
|
|
2023-03-03 16:36:39 +00:00
|
|
|
var (
|
|
|
|
deploymentSchema *jsonschema.Schema
|
|
|
|
propertyValueSchema *jsonschema.Schema
|
|
|
|
)
|
2021-09-22 04:37:06 +00:00
|
|
|
|
|
|
|
func init() {
|
|
|
|
compiler := jsonschema.NewCompiler()
|
|
|
|
compiler.LoadURL = func(s string) (io.ReadCloser, error) {
|
|
|
|
var schema string
|
|
|
|
switch s {
|
|
|
|
case apitype.DeploymentSchemaID:
|
|
|
|
schema = apitype.DeploymentSchema()
|
|
|
|
case apitype.ResourceSchemaID:
|
|
|
|
schema = apitype.ResourceSchema()
|
|
|
|
case apitype.PropertyValueSchemaID:
|
|
|
|
schema = apitype.PropertyValueSchema()
|
|
|
|
default:
|
|
|
|
return jsonschema.LoadURL(s)
|
|
|
|
}
|
2023-01-06 22:39:16 +00:00
|
|
|
return io.NopCloser(strings.NewReader(schema)), nil
|
2021-09-22 04:37:06 +00:00
|
|
|
}
|
|
|
|
deploymentSchema = compiler.MustCompile(apitype.DeploymentSchemaID)
|
|
|
|
propertyValueSchema = compiler.MustCompile(apitype.PropertyValueSchemaID)
|
|
|
|
}
|
|
|
|
|
|
|
|
// ValidateUntypedDeployment validates a deployment against the Deployment JSON schema.
|
|
|
|
func ValidateUntypedDeployment(deployment *apitype.UntypedDeployment) error {
|
|
|
|
bytes, err := json.Marshal(deployment)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
var raw interface{}
|
|
|
|
if err := json.Unmarshal(bytes, &raw); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
return deploymentSchema.Validate(raw)
|
|
|
|
}
|
|
|
|
|
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 18:50:47 +00:00
|
|
|
// SerializeDeployment serializes an entire snapshot as a deploy record.
|
Lift context parameter to SerializeDeployment/Resource/Operations/Properties (#15929)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
SerializePropertyValue needed a `context.Context` object to pass to the
`config.Encrypter`. It was using `context.TODO()`, this change instead
accepts a context on the parameters and lifts that up to
SerializeProperties, SerializeResource, SerializeOperation, and
SerializeDeployment.
There were a few call sites for those methods that already had a context
on hand, and they now pass that context. The other calls sites now use
`context.TODO()`, we should continue to iterate in this area to ensure
everywhere that needs a context has one passed in.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2024-04-15 07:45:46 +00:00
|
|
|
func SerializeDeployment(ctx context.Context, snap *deploy.Snapshot, showSecrets bool) (*apitype.DeploymentV3, error) {
|
2023-02-17 18:46:23 +00:00
|
|
|
contract.Requiref(snap != nil, "snap", "must not be nil")
|
2018-05-25 20:29:59 +00:00
|
|
|
|
2017-12-01 21:50:32 +00:00
|
|
|
// Capture the version information into a manifest.
|
2022-01-10 12:25:24 +00:00
|
|
|
manifest := snap.Manifest.Serialize()
|
2017-12-01 21:50:32 +00:00
|
|
|
|
2024-03-25 10:30:14 +00:00
|
|
|
sm := snap.SecretsManager
|
2019-04-19 19:13:30 +00:00
|
|
|
var enc config.Encrypter
|
|
|
|
if sm != nil {
|
|
|
|
e, err := sm.Encrypter()
|
|
|
|
if err != nil {
|
2021-11-13 02:37:17 +00:00
|
|
|
return nil, fmt.Errorf("getting encrypter for deployment: %w", err)
|
2019-04-19 19:13:30 +00:00
|
|
|
}
|
|
|
|
enc = e
|
|
|
|
} else {
|
|
|
|
enc = config.NewPanicCrypter()
|
2019-04-17 20:48:38 +00:00
|
|
|
}
|
|
|
|
|
2017-02-22 02:31:43 +00:00
|
|
|
// Serialize all vertices and only include a vertex section if non-empty.
|
2023-06-28 16:02:04 +00:00
|
|
|
resources := slice.Prealloc[apitype.ResourceV3](len(snap.Resources))
|
2017-10-05 21:08:35 +00:00
|
|
|
for _, res := range snap.Resources {
|
Lift context parameter to SerializeDeployment/Resource/Operations/Properties (#15929)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
SerializePropertyValue needed a `context.Context` object to pass to the
`config.Encrypter`. It was using `context.TODO()`, this change instead
accepts a context on the parameters and lifts that up to
SerializeProperties, SerializeResource, SerializeOperation, and
SerializeDeployment.
There were a few call sites for those methods that already had a context
on hand, and they now pass that context. The other calls sites now use
`context.TODO()`, we should continue to iterate in this area to ensure
everywhere that needs a context has one passed in.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2024-04-15 07:45:46 +00:00
|
|
|
sres, err := SerializeResource(ctx, res, enc, showSecrets)
|
2019-04-17 20:48:38 +00:00
|
|
|
if err != nil {
|
2021-11-13 02:37:17 +00:00
|
|
|
return nil, fmt.Errorf("serializing resources: %w", err)
|
2019-04-17 20:48:38 +00:00
|
|
|
}
|
|
|
|
resources = append(resources, sres)
|
2017-02-22 02:31:43 +00:00
|
|
|
}
|
|
|
|
|
2023-06-28 16:02:04 +00:00
|
|
|
operations := slice.Prealloc[apitype.OperationV2](len(snap.PendingOperations))
|
Add a list of in-flight operations to the deployment (#1759)
* Add a list of in-flight operations to the deployment
This commit augments 'DeploymentV2' with a list of operations that are
currently in flight. This information is used by the engine to keep
track of whether or not a particular deployment is in a valid state.
The SnapshotManager is responsible for inserting and removing operations
from the in-flight operation list. When the engine registers an intent
to perform an operation, SnapshotManager inserts an Operation into this
list and saves it to the snapshot. When an operation completes, the
SnapshotManager removes it from the snapshot. From this, the engine can
infer that if it ever sees a deployment with pending operations, the
Pulumi CLI must have crashed or otherwise abnormally terminated before
seeing whether or not an operation completed successfully.
To remedy this state, this commit also adds code to 'pulumi stack
import' that clears all pending operations from a deployment, as well as
code to plan generation that will reject any deployments that have
pending operations present.
At the CLI level, if we see that we are in a state where pending
operations were in-flight when the engine died, we'll issue a
human-friendly error message that indicates which resources are in a bad
state and how to recover their stack.
* CR: Multi-line string literals, renaming in-flight -> pending
* CR: Add enum to apitype for operation type, also name status -> type for clarity
* Fix the yaml type
* Fix missed renames
* Add implementation for lifecycle_test.go
* Rebase against master
2018-08-11 04:39:59 +00:00
|
|
|
for _, op := range snap.PendingOperations {
|
Lift context parameter to SerializeDeployment/Resource/Operations/Properties (#15929)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
SerializePropertyValue needed a `context.Context` object to pass to the
`config.Encrypter`. It was using `context.TODO()`, this change instead
accepts a context on the parameters and lifts that up to
SerializeProperties, SerializeResource, SerializeOperation, and
SerializeDeployment.
There were a few call sites for those methods that already had a context
on hand, and they now pass that context. The other calls sites now use
`context.TODO()`, we should continue to iterate in this area to ensure
everywhere that needs a context has one passed in.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2024-04-15 07:45:46 +00:00
|
|
|
sop, err := SerializeOperation(ctx, op, enc, showSecrets)
|
2019-04-17 20:48:38 +00:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
operations = append(operations, sop)
|
|
|
|
}
|
|
|
|
|
2019-05-21 18:50:02 +00:00
|
|
|
var secretsProvider *apitype.SecretsProvidersV1
|
2019-04-19 19:13:30 +00:00
|
|
|
if sm != nil {
|
2019-05-21 18:50:02 +00:00
|
|
|
secretsProvider = &apitype.SecretsProvidersV1{
|
2023-05-09 08:21:14 +00:00
|
|
|
Type: sm.Type(),
|
|
|
|
State: sm.State(),
|
2019-04-17 20:48:38 +00:00
|
|
|
}
|
Add a list of in-flight operations to the deployment (#1759)
* Add a list of in-flight operations to the deployment
This commit augments 'DeploymentV2' with a list of operations that are
currently in flight. This information is used by the engine to keep
track of whether or not a particular deployment is in a valid state.
The SnapshotManager is responsible for inserting and removing operations
from the in-flight operation list. When the engine registers an intent
to perform an operation, SnapshotManager inserts an Operation into this
list and saves it to the snapshot. When an operation completes, the
SnapshotManager removes it from the snapshot. From this, the engine can
infer that if it ever sees a deployment with pending operations, the
Pulumi CLI must have crashed or otherwise abnormally terminated before
seeing whether or not an operation completed successfully.
To remedy this state, this commit also adds code to 'pulumi stack
import' that clears all pending operations from a deployment, as well as
code to plan generation that will reject any deployments that have
pending operations present.
At the CLI level, if we see that we are in a state where pending
operations were in-flight when the engine died, we'll issue a
human-friendly error message that indicates which resources are in a bad
state and how to recover their stack.
* CR: Multi-line string literals, renaming in-flight -> pending
* CR: Add enum to apitype for operation type, also name status -> type for clarity
* Fix the yaml type
* Fix missed renames
* Add implementation for lifecycle_test.go
* Rebase against master
2018-08-11 04:39:59 +00:00
|
|
|
}
|
|
|
|
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
return &apitype.DeploymentV3{
|
Add a list of in-flight operations to the deployment (#1759)
* Add a list of in-flight operations to the deployment
This commit augments 'DeploymentV2' with a list of operations that are
currently in flight. This information is used by the engine to keep
track of whether or not a particular deployment is in a valid state.
The SnapshotManager is responsible for inserting and removing operations
from the in-flight operation list. When the engine registers an intent
to perform an operation, SnapshotManager inserts an Operation into this
list and saves it to the snapshot. When an operation completes, the
SnapshotManager removes it from the snapshot. From this, the engine can
infer that if it ever sees a deployment with pending operations, the
Pulumi CLI must have crashed or otherwise abnormally terminated before
seeing whether or not an operation completed successfully.
To remedy this state, this commit also adds code to 'pulumi stack
import' that clears all pending operations from a deployment, as well as
code to plan generation that will reject any deployments that have
pending operations present.
At the CLI level, if we see that we are in a state where pending
operations were in-flight when the engine died, we'll issue a
human-friendly error message that indicates which resources are in a bad
state and how to recover their stack.
* CR: Multi-line string literals, renaming in-flight -> pending
* CR: Add enum to apitype for operation type, also name status -> type for clarity
* Fix the yaml type
* Fix missed renames
* Add implementation for lifecycle_test.go
* Rebase against master
2018-08-11 04:39:59 +00:00
|
|
|
Manifest: manifest,
|
|
|
|
Resources: resources,
|
2019-05-21 18:50:02 +00:00
|
|
|
SecretsProviders: secretsProvider,
|
Add a list of in-flight operations to the deployment (#1759)
* Add a list of in-flight operations to the deployment
This commit augments 'DeploymentV2' with a list of operations that are
currently in flight. This information is used by the engine to keep
track of whether or not a particular deployment is in a valid state.
The SnapshotManager is responsible for inserting and removing operations
from the in-flight operation list. When the engine registers an intent
to perform an operation, SnapshotManager inserts an Operation into this
list and saves it to the snapshot. When an operation completes, the
SnapshotManager removes it from the snapshot. From this, the engine can
infer that if it ever sees a deployment with pending operations, the
Pulumi CLI must have crashed or otherwise abnormally terminated before
seeing whether or not an operation completed successfully.
To remedy this state, this commit also adds code to 'pulumi stack
import' that clears all pending operations from a deployment, as well as
code to plan generation that will reject any deployments that have
pending operations present.
At the CLI level, if we see that we are in a state where pending
operations were in-flight when the engine died, we'll issue a
human-friendly error message that indicates which resources are in a bad
state and how to recover their stack.
* CR: Multi-line string literals, renaming in-flight -> pending
* CR: Add enum to apitype for operation type, also name status -> type for clarity
* Fix the yaml type
* Fix missed renames
* Add implementation for lifecycle_test.go
* Rebase against master
2018-08-11 04:39:59 +00:00
|
|
|
PendingOperations: operations,
|
2019-04-17 20:48:38 +00:00
|
|
|
}, nil
|
2017-02-22 02:31:43 +00:00
|
|
|
}
|
|
|
|
|
2023-11-13 12:27:46 +00:00
|
|
|
// UnmarshalUntypedDeployment unmarshals a raw untyped deployment into an up to date deployment object.
|
|
|
|
func UnmarshalUntypedDeployment(
|
2022-07-18 13:36:31 +00:00
|
|
|
ctx context.Context,
|
|
|
|
deployment *apitype.UntypedDeployment,
|
2023-11-13 12:27:46 +00:00
|
|
|
) (*apitype.DeploymentV3, error) {
|
2023-02-17 18:46:23 +00:00
|
|
|
contract.Requiref(deployment != nil, "deployment", "must not be nil")
|
2018-05-25 20:29:59 +00:00
|
|
|
switch {
|
|
|
|
case deployment.Version > apitype.DeploymentSchemaVersionCurrent:
|
|
|
|
return nil, ErrDeploymentSchemaVersionTooNew
|
|
|
|
case deployment.Version < DeploymentSchemaVersionOldestSupported:
|
|
|
|
return nil, ErrDeploymentSchemaVersionTooOld
|
|
|
|
}
|
|
|
|
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
var v3deployment apitype.DeploymentV3
|
2018-07-20 20:31:41 +00:00
|
|
|
switch deployment.Version {
|
|
|
|
case 1:
|
2018-08-03 21:06:00 +00:00
|
|
|
var v1deployment apitype.DeploymentV1
|
|
|
|
if err := json.Unmarshal([]byte(deployment.Deployment), &v1deployment); err != nil {
|
2018-07-20 20:31:41 +00:00
|
|
|
return nil, err
|
|
|
|
}
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
v2deployment := migrate.UpToDeploymentV2(v1deployment)
|
|
|
|
v3deployment = migrate.UpToDeploymentV3(v2deployment)
|
2018-08-03 21:06:00 +00:00
|
|
|
case 2:
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
var v2deployment apitype.DeploymentV2
|
2018-08-03 21:06:00 +00:00
|
|
|
if err := json.Unmarshal([]byte(deployment.Deployment), &v2deployment); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
v3deployment = migrate.UpToDeploymentV3(v2deployment)
|
|
|
|
case 3:
|
|
|
|
if err := json.Unmarshal([]byte(deployment.Deployment), &v3deployment); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2018-08-03 21:06:00 +00:00
|
|
|
default:
|
|
|
|
contract.Failf("unrecognized version: %d", deployment.Version)
|
|
|
|
}
|
|
|
|
|
2023-11-13 12:27:46 +00:00
|
|
|
return &v3deployment, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// DeserializeUntypedDeployment deserializes an untyped deployment and produces a `deploy.Snapshot`
|
|
|
|
// from it. DeserializeDeployment will return an error if the untyped deployment's version is
|
|
|
|
// not within the range `DeploymentSchemaVersionCurrent` and `DeploymentSchemaVersionOldestSupported`.
|
|
|
|
func DeserializeUntypedDeployment(
|
|
|
|
ctx context.Context,
|
|
|
|
deployment *apitype.UntypedDeployment,
|
|
|
|
secretsProv secrets.Provider,
|
|
|
|
) (*deploy.Snapshot, error) {
|
|
|
|
v3deployment, err := UnmarshalUntypedDeployment(ctx, deployment)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
return DeserializeDeploymentV3(ctx, *v3deployment, secretsProv)
|
2018-08-03 21:06:00 +00:00
|
|
|
}
|
|
|
|
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
// DeserializeDeploymentV3 deserializes a typed DeploymentV3 into a `deploy.Snapshot`.
|
2022-07-18 13:36:31 +00:00
|
|
|
func DeserializeDeploymentV3(
|
|
|
|
ctx context.Context,
|
|
|
|
deployment apitype.DeploymentV3,
|
2023-03-03 16:36:39 +00:00
|
|
|
secretsProv secrets.Provider,
|
|
|
|
) (*deploy.Snapshot, error) {
|
2018-08-03 21:06:00 +00:00
|
|
|
// Unpack the versions.
|
2022-01-10 12:25:24 +00:00
|
|
|
manifest, err := deploy.DeserializeManifest(deployment.Manifest)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
2018-08-03 21:06:00 +00:00
|
|
|
}
|
|
|
|
|
2019-04-24 19:13:00 +00:00
|
|
|
var secretsManager secrets.Manager
|
2019-05-21 18:50:02 +00:00
|
|
|
if deployment.SecretsProviders != nil && deployment.SecretsProviders.Type != "" {
|
2019-08-01 17:33:52 +00:00
|
|
|
if secretsProv == nil {
|
|
|
|
return nil, errors.New("deployment uses a SecretsProvider but no SecretsProvider was provided")
|
2019-04-24 19:13:00 +00:00
|
|
|
}
|
2019-04-26 19:00:35 +00:00
|
|
|
|
2019-08-01 17:33:52 +00:00
|
|
|
sm, err := secretsProv.OfType(deployment.SecretsProviders.Type, deployment.SecretsProviders.State)
|
2019-04-26 19:00:35 +00:00
|
|
|
if err != nil {
|
2019-08-01 17:33:52 +00:00
|
|
|
return nil, err
|
2019-04-26 19:00:35 +00:00
|
|
|
}
|
|
|
|
secretsManager = sm
|
2019-04-24 19:13:00 +00:00
|
|
|
}
|
|
|
|
|
2019-04-17 20:48:38 +00:00
|
|
|
var dec config.Decrypter
|
2020-05-11 18:16:30 +00:00
|
|
|
var enc config.Encrypter
|
2019-04-24 19:13:00 +00:00
|
|
|
if secretsManager == nil {
|
2024-03-07 09:31:57 +00:00
|
|
|
var ciphertexts []string
|
|
|
|
for _, res := range deployment.Resources {
|
|
|
|
collectCiphertexts(&ciphertexts, res.Inputs)
|
|
|
|
collectCiphertexts(&ciphertexts, res.Outputs)
|
|
|
|
}
|
|
|
|
if len(ciphertexts) > 0 {
|
|
|
|
// If there are ciphertexts, but we couldn't set up a secrets manager, error out early
|
|
|
|
// to avoid panic'ing later on. This snapshot is broken and needs to be repaired
|
|
|
|
// manually.
|
|
|
|
return nil, errors.New("snapshot contains encrypted secrets but no secrets manager could be found")
|
|
|
|
}
|
2019-04-17 20:48:38 +00:00
|
|
|
dec = config.NewPanicCrypter()
|
2020-05-11 18:16:30 +00:00
|
|
|
enc = config.NewPanicCrypter()
|
2019-04-24 19:13:00 +00:00
|
|
|
} else {
|
|
|
|
d, err := secretsManager.Decrypter()
|
2019-04-17 20:48:38 +00:00
|
|
|
if err != nil {
|
2019-04-24 19:13:00 +00:00
|
|
|
return nil, err
|
2019-04-17 20:48:38 +00:00
|
|
|
}
|
2022-01-24 20:33:40 +00:00
|
|
|
|
|
|
|
// Do a first pass through state and collect all of the secrets that need decrypting.
|
|
|
|
// We will collect all secrets and decrypt them all at once, rather than just-in-time.
|
|
|
|
// We do this to avoid serial calls to the decryption endpoint which can result in long
|
|
|
|
// wait times in stacks with a large number of secrets.
|
|
|
|
var ciphertexts []string
|
|
|
|
for _, res := range deployment.Resources {
|
2022-02-25 16:51:52 +00:00
|
|
|
collectCiphertexts(&ciphertexts, res.Inputs)
|
|
|
|
collectCiphertexts(&ciphertexts, res.Outputs)
|
2022-01-24 20:33:40 +00:00
|
|
|
}
|
|
|
|
|
2022-02-25 16:51:52 +00:00
|
|
|
// Decrypt the collected secrets and create a decrypter that will use the result as a cache.
|
2022-07-18 13:36:31 +00:00
|
|
|
cache, err := d.BulkDecrypt(ctx, ciphertexts)
|
2022-01-24 20:33:40 +00:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2022-02-25 16:51:52 +00:00
|
|
|
dec = newMapDecrypter(d, cache)
|
2020-05-11 18:16:30 +00:00
|
|
|
|
|
|
|
e, err := secretsManager.Encrypter()
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
enc = e
|
2019-04-17 20:48:38 +00:00
|
|
|
}
|
|
|
|
|
2018-08-03 21:06:00 +00:00
|
|
|
// For every serialized resource vertex, create a ResourceDeployment out of it.
|
2023-06-28 16:02:04 +00:00
|
|
|
resources := slice.Prealloc[*resource.State](len(deployment.Resources))
|
2018-08-03 21:06:00 +00:00
|
|
|
for _, res := range deployment.Resources {
|
2020-05-11 18:16:30 +00:00
|
|
|
desres, err := DeserializeResource(res, dec, enc)
|
2018-08-03 21:06:00 +00:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
resources = append(resources, desres)
|
2018-05-25 20:29:59 +00:00
|
|
|
}
|
|
|
|
|
2023-06-28 16:02:04 +00:00
|
|
|
ops := slice.Prealloc[resource.Operation](len(deployment.PendingOperations))
|
Add a list of in-flight operations to the deployment (#1759)
* Add a list of in-flight operations to the deployment
This commit augments 'DeploymentV2' with a list of operations that are
currently in flight. This information is used by the engine to keep
track of whether or not a particular deployment is in a valid state.
The SnapshotManager is responsible for inserting and removing operations
from the in-flight operation list. When the engine registers an intent
to perform an operation, SnapshotManager inserts an Operation into this
list and saves it to the snapshot. When an operation completes, the
SnapshotManager removes it from the snapshot. From this, the engine can
infer that if it ever sees a deployment with pending operations, the
Pulumi CLI must have crashed or otherwise abnormally terminated before
seeing whether or not an operation completed successfully.
To remedy this state, this commit also adds code to 'pulumi stack
import' that clears all pending operations from a deployment, as well as
code to plan generation that will reject any deployments that have
pending operations present.
At the CLI level, if we see that we are in a state where pending
operations were in-flight when the engine died, we'll issue a
human-friendly error message that indicates which resources are in a bad
state and how to recover their stack.
* CR: Multi-line string literals, renaming in-flight -> pending
* CR: Add enum to apitype for operation type, also name status -> type for clarity
* Fix the yaml type
* Fix missed renames
* Add implementation for lifecycle_test.go
* Rebase against master
2018-08-11 04:39:59 +00:00
|
|
|
for _, op := range deployment.PendingOperations {
|
2020-05-11 18:16:30 +00:00
|
|
|
desop, err := DeserializeOperation(op, dec, enc)
|
Add a list of in-flight operations to the deployment (#1759)
* Add a list of in-flight operations to the deployment
This commit augments 'DeploymentV2' with a list of operations that are
currently in flight. This information is used by the engine to keep
track of whether or not a particular deployment is in a valid state.
The SnapshotManager is responsible for inserting and removing operations
from the in-flight operation list. When the engine registers an intent
to perform an operation, SnapshotManager inserts an Operation into this
list and saves it to the snapshot. When an operation completes, the
SnapshotManager removes it from the snapshot. From this, the engine can
infer that if it ever sees a deployment with pending operations, the
Pulumi CLI must have crashed or otherwise abnormally terminated before
seeing whether or not an operation completed successfully.
To remedy this state, this commit also adds code to 'pulumi stack
import' that clears all pending operations from a deployment, as well as
code to plan generation that will reject any deployments that have
pending operations present.
At the CLI level, if we see that we are in a state where pending
operations were in-flight when the engine died, we'll issue a
human-friendly error message that indicates which resources are in a bad
state and how to recover their stack.
* CR: Multi-line string literals, renaming in-flight -> pending
* CR: Add enum to apitype for operation type, also name status -> type for clarity
* Fix the yaml type
* Fix missed renames
* Add implementation for lifecycle_test.go
* Rebase against master
2018-08-11 04:39:59 +00:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
ops = append(ops, desop)
|
|
|
|
}
|
|
|
|
|
2022-01-10 12:25:24 +00:00
|
|
|
return deploy.NewSnapshot(*manifest, secretsManager, resources, ops), nil
|
2018-05-25 20:29:59 +00:00
|
|
|
}
|
|
|
|
|
2017-10-05 21:08:35 +00:00
|
|
|
// SerializeResource turns a resource into a structure suitable for serialization.
|
Lift context parameter to SerializeDeployment/Resource/Operations/Properties (#15929)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
SerializePropertyValue needed a `context.Context` object to pass to the
`config.Encrypter`. It was using `context.TODO()`, this change instead
accepts a context on the parameters and lifts that up to
SerializeProperties, SerializeResource, SerializeOperation, and
SerializeDeployment.
There were a few call sites for those methods that already had a context
on hand, and they now pass that context. The other calls sites now use
`context.TODO()`, we should continue to iterate in this area to ensure
everywhere that needs a context has one passed in.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2024-04-15 07:45:46 +00:00
|
|
|
func SerializeResource(
|
|
|
|
ctx context.Context, res *resource.State, enc config.Encrypter, showSecrets bool,
|
|
|
|
) (apitype.ResourceV3, error) {
|
2023-02-17 18:46:23 +00:00
|
|
|
contract.Requiref(res != nil, "res", "must not be nil")
|
|
|
|
contract.Requiref(res.URN != "", "res", "must have a URN")
|
2017-02-22 02:31:43 +00:00
|
|
|
|
2024-05-09 16:15:41 +00:00
|
|
|
res.Lock.Lock()
|
|
|
|
defer res.Lock.Unlock()
|
|
|
|
|
2017-06-05 02:24:48 +00:00
|
|
|
// Serialize all input and output properties recursively, and add them if non-empty.
|
2017-06-06 23:42:14 +00:00
|
|
|
var inputs map[string]interface{}
|
2017-08-01 01:26:15 +00:00
|
|
|
if inp := res.Inputs; inp != nil {
|
Lift context parameter to SerializeDeployment/Resource/Operations/Properties (#15929)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
SerializePropertyValue needed a `context.Context` object to pass to the
`config.Encrypter`. It was using `context.TODO()`, this change instead
accepts a context on the parameters and lifts that up to
SerializeProperties, SerializeResource, SerializeOperation, and
SerializeDeployment.
There were a few call sites for those methods that already had a context
on hand, and they now pass that context. The other calls sites now use
`context.TODO()`, we should continue to iterate in this area to ensure
everywhere that needs a context has one passed in.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2024-04-15 07:45:46 +00:00
|
|
|
sinp, err := SerializeProperties(ctx, inp, enc, showSecrets)
|
2019-04-17 20:48:38 +00:00
|
|
|
if err != nil {
|
|
|
|
return apitype.ResourceV3{}, err
|
|
|
|
}
|
|
|
|
inputs = sinp
|
2017-06-06 23:42:14 +00:00
|
|
|
}
|
|
|
|
var outputs map[string]interface{}
|
2017-08-01 01:26:15 +00:00
|
|
|
if outp := res.Outputs; outp != nil {
|
Lift context parameter to SerializeDeployment/Resource/Operations/Properties (#15929)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
SerializePropertyValue needed a `context.Context` object to pass to the
`config.Encrypter`. It was using `context.TODO()`, this change instead
accepts a context on the parameters and lifts that up to
SerializeProperties, SerializeResource, SerializeOperation, and
SerializeDeployment.
There were a few call sites for those methods that already had a context
on hand, and they now pass that context. The other calls sites now use
`context.TODO()`, we should continue to iterate in this area to ensure
everywhere that needs a context has one passed in.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2024-04-15 07:45:46 +00:00
|
|
|
soutp, err := SerializeProperties(ctx, outp, enc, showSecrets)
|
2019-04-17 20:48:38 +00:00
|
|
|
if err != nil {
|
|
|
|
return apitype.ResourceV3{}, err
|
|
|
|
}
|
|
|
|
outputs = soutp
|
2017-06-06 23:42:14 +00:00
|
|
|
}
|
2017-02-22 02:31:43 +00:00
|
|
|
|
2019-08-20 22:01:27 +00:00
|
|
|
v3Resource := apitype.ResourceV3{
|
2019-05-09 21:27:34 +00:00
|
|
|
URN: res.URN,
|
|
|
|
Custom: res.Custom,
|
|
|
|
Delete: res.Delete,
|
|
|
|
ID: res.ID,
|
|
|
|
Type: res.Type,
|
|
|
|
Parent: res.Parent,
|
|
|
|
Inputs: inputs,
|
|
|
|
Outputs: outputs,
|
|
|
|
Protect: res.Protect,
|
|
|
|
External: res.External,
|
|
|
|
Dependencies: res.Dependencies,
|
|
|
|
InitErrors: res.InitErrors,
|
|
|
|
Provider: res.Provider,
|
|
|
|
PropertyDependencies: res.PropertyDependencies,
|
|
|
|
PendingReplacement: res.PendingReplacement,
|
|
|
|
AdditionalSecretOutputs: res.AdditionalSecretOutputs,
|
2022-03-24 19:08:18 +00:00
|
|
|
Aliases: res.Aliases,
|
2020-04-16 01:52:40 +00:00
|
|
|
ImportID: res.ImportID,
|
2022-02-16 22:11:12 +00:00
|
|
|
RetainOnDelete: res.RetainOnDelete,
|
2022-10-20 06:15:43 +00:00
|
|
|
DeletedWith: res.DeletedWith,
|
This commit adds the `Created` and `Modified` timestamps to pulumi state that are optional.
`Created`: Created tracks when the remote resource was first added to state by pulumi. Checkpoints prior to early 2023 do not include this. (Create, Import)
`Modified`: Modified tracks when the resource state was last altered. Checkpoints prior to early 2023 do not include this. (Create, Import, Read, Refresh, Update)
When serialized they will follow RFC3339 with nanoseconds captured by a test case.
https://pkg.go.dev/time#RFC3339
Note: Older versions of pulumi may strip these fields when modifying the state.
For future expansion, when we inevitably need to track other timestamps, we'll add a new "operationTimestamps" field (or something similarly named that clarified these are timestamps of the actual Pulumi operations).
operationTimestamps: {
created: ...,
updated: ...,
imported: ...,
}
Fixes https://github.com/pulumi/pulumi/issues/12022
2023-02-06 20:39:11 +00:00
|
|
|
Created: res.Created,
|
|
|
|
Modified: res.Modified,
|
[engine] Add support for source positions
These changes add support for passing source position information in
gRPC metadata and recording the source position that corresponds to a
resource registration in the statefile.
Enabling source position information in the resource model can provide
substantial benefits, including but not limited to:
- Better errors from the Pulumi CLI
- Go-to-defintion for resources in state
- Editor integration for errors, etc. from `pulumi preview`
Source positions are (file, line) or (file, line, column) tuples
represented as URIs. The line and column are stored in the fragment
portion of the URI as "line(,column)?". The scheme of the URI and the
form of its path component depends on the context in which it is
generated or used:
- During an active update, the URI's scheme is `file` and paths are
absolute filesystem paths. This allows consumers to easily access
arbitrary files that are available on the host.
- In a statefile, the URI's scheme is `project` and paths are relative
to the project root. This allows consumers to resolve source positions
relative to the project file in different contexts irrespective of the
location of the project itself (e.g. given a project-relative path and
the URL of the project's root on GitHub, one can build a GitHub URL for
the source position).
During an update, source position information may be attached to gRPC
calls as "source-position" metadata. This allows arbitrary calls to be
associated with source positions without changes to their protobuf
payloads. Modifying the protobuf payloads is also a viable approach, but
is somewhat more invasive than attaching metadata, and requires changes
to every call signature.
Source positions should reflect the position in user code that initiated
a resource model operation (e.g. the source position passed with
`RegisterResource` for `pet` in the example above should be the source
position in `index.ts`, _not_ the source position in the Pulumi SDK). In
general, the Pulumi SDK should be able to infer the source position of
the resource registration, as the relationship between a resource
registration and its corresponding user code should be static per SDK.
Source positions in state files will be stored as a new `registeredAt`
property on each resource. This property is optional.
2023-06-29 18:41:19 +00:00
|
|
|
SourcePosition: res.SourcePosition,
|
Change `pulumi refresh` to report diff relative to desired state instead of relative to only output changes (#16146)
Presently, the behaviour of diffing during refresh steps is incomplete,
returning only an "output diff" that presents the changes in outputs.
This commit changes refresh steps so that:
* they compute a diff similar to the one that would be computed if a
`preview` were run immediately after the refresh, which is more
typically what users expect and want; and
* `IgnoreChanges` resource options are respected when performing the new
desired-state diffs, so that property additions or changes reported by a
refresh can be ignored.
In particular, `IgnoreChanges` can now be used to acknowledge that part
or all of a resource may change in the provider, but the user is OK with
this and doesn't want to be notified about it during a refresh.
Importantly, this means that the diff won't be reported, but also that
the changes won't be applied to state.
The implementation covers the following:
* A diff is computed using the inputs from the program and then
inverting the result, since in the case of a refresh the diff is being
driven by the provider side and not the program. This doesn't change
what is stored back into the state, but it does produce a diff that is
more aligned with the "true changes to the desired state".
* `IgnoreChanges` resource options are now stored in state, so that this
information can be used in refresh operations that do not have access
to/run the program.
* In the context of a refresh operation, `IgnoreChanges` applies to
*both* input and output properties. This differs from the behaviour of a
normal update operation, where `IgnoreChanges` only considers input
properties.
* The special `"*"` value for `IgnoreChanges` can be used to ignore all
properties. It _also_ ignores the case where the resource cannot be
found in the provider, and instead keeps the resource intact in state
with its existing input and output properties.
Because the program is not run for refresh operations, `IgnoreChanges`
options must be applied separately before a refresh takes place. This
can be accomplished using e.g. a `pulumi up` that applies the options
prior to a refresh. We should investigate perhaps providing a `pulumi
state set ...`-like CLI to make these sorts of changes directly to a
state.
For use cases relying on the legacy refresh diff provider, the
`PULUMI_USE_LEGACY_REFRESH_DIFF` environment variable can be set, which
will disable desired-state diff computation. We only need to perform
checks in `RefreshStep.{ResultOp,Apply}`, since downstream code will
work correctly based on the presence or absence of a `DetailedDiff` in
the step.
### Notes
- https://github.com/pulumi/pulumi/issues/16144 affects some of these
cases - though its technically orthogonal
- https://github.com/pulumi/pulumi/issues/11279 is another technically
orthogonal issue that many providers (at least TFBridge ones) - do not
report back changes to input properties on Read when the input property
(or property path) was missing on the inputs. This is again technically
orthogonal - but leads to cases that appear "wrong" in terms of what is
stored back into the state still - though the same as before this
change.
- Azure Native doesn't seem to handle `ignoreChanges` passed to Diff, so
the ability to ignore changes on refresh doesn't currently work for
Azure Native.
### Fixes
* Fixes #16072
* Fixes #16278
* Fixes #16334
* Not quite #12346, but likely replaces the need for that
Co-authored-by: Will Jones <will@sacharissa.co.uk>
2024-06-12 16:17:05 +00:00
|
|
|
IgnoreChanges: res.IgnoreChanges,
|
2019-08-20 22:01:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if res.CustomTimeouts.IsNotEmpty() {
|
|
|
|
v3Resource.CustomTimeouts = &res.CustomTimeouts
|
|
|
|
}
|
|
|
|
|
|
|
|
return v3Resource, nil
|
2017-02-22 02:31:43 +00:00
|
|
|
}
|
|
|
|
|
This commit adds the `Created` and `Modified` timestamps to pulumi state that are optional.
`Created`: Created tracks when the remote resource was first added to state by pulumi. Checkpoints prior to early 2023 do not include this. (Create, Import)
`Modified`: Modified tracks when the resource state was last altered. Checkpoints prior to early 2023 do not include this. (Create, Import, Read, Refresh, Update)
When serialized they will follow RFC3339 with nanoseconds captured by a test case.
https://pkg.go.dev/time#RFC3339
Note: Older versions of pulumi may strip these fields when modifying the state.
For future expansion, when we inevitably need to track other timestamps, we'll add a new "operationTimestamps" field (or something similarly named that clarified these are timestamps of the actual Pulumi operations).
operationTimestamps: {
created: ...,
updated: ...,
imported: ...,
}
Fixes https://github.com/pulumi/pulumi/issues/12022
2023-02-06 20:39:11 +00:00
|
|
|
// SerializeOperation serializes a resource in a pending state.
|
Lift context parameter to SerializeDeployment/Resource/Operations/Properties (#15929)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
SerializePropertyValue needed a `context.Context` object to pass to the
`config.Encrypter`. It was using `context.TODO()`, this change instead
accepts a context on the parameters and lifts that up to
SerializeProperties, SerializeResource, SerializeOperation, and
SerializeDeployment.
There were a few call sites for those methods that already had a context
on hand, and they now pass that context. The other calls sites now use
`context.TODO()`, we should continue to iterate in this area to ensure
everywhere that needs a context has one passed in.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2024-04-15 07:45:46 +00:00
|
|
|
func SerializeOperation(
|
|
|
|
ctx context.Context, op resource.Operation, enc config.Encrypter, showSecrets bool,
|
|
|
|
) (apitype.OperationV2, error) {
|
|
|
|
res, err := SerializeResource(ctx, op.Resource, enc, showSecrets)
|
2019-04-17 20:48:38 +00:00
|
|
|
if err != nil {
|
2021-11-13 02:37:17 +00:00
|
|
|
return apitype.OperationV2{}, fmt.Errorf("serializing resource: %w", err)
|
2019-04-17 20:48:38 +00:00
|
|
|
}
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
return apitype.OperationV2{
|
Add a list of in-flight operations to the deployment (#1759)
* Add a list of in-flight operations to the deployment
This commit augments 'DeploymentV2' with a list of operations that are
currently in flight. This information is used by the engine to keep
track of whether or not a particular deployment is in a valid state.
The SnapshotManager is responsible for inserting and removing operations
from the in-flight operation list. When the engine registers an intent
to perform an operation, SnapshotManager inserts an Operation into this
list and saves it to the snapshot. When an operation completes, the
SnapshotManager removes it from the snapshot. From this, the engine can
infer that if it ever sees a deployment with pending operations, the
Pulumi CLI must have crashed or otherwise abnormally terminated before
seeing whether or not an operation completed successfully.
To remedy this state, this commit also adds code to 'pulumi stack
import' that clears all pending operations from a deployment, as well as
code to plan generation that will reject any deployments that have
pending operations present.
At the CLI level, if we see that we are in a state where pending
operations were in-flight when the engine died, we'll issue a
human-friendly error message that indicates which resources are in a bad
state and how to recover their stack.
* CR: Multi-line string literals, renaming in-flight -> pending
* CR: Add enum to apitype for operation type, also name status -> type for clarity
* Fix the yaml type
* Fix missed renames
* Add implementation for lifecycle_test.go
* Rebase against master
2018-08-11 04:39:59 +00:00
|
|
|
Resource: res,
|
|
|
|
Type: apitype.OperationType(op.Type),
|
2019-04-17 20:48:38 +00:00
|
|
|
}, nil
|
Add a list of in-flight operations to the deployment (#1759)
* Add a list of in-flight operations to the deployment
This commit augments 'DeploymentV2' with a list of operations that are
currently in flight. This information is used by the engine to keep
track of whether or not a particular deployment is in a valid state.
The SnapshotManager is responsible for inserting and removing operations
from the in-flight operation list. When the engine registers an intent
to perform an operation, SnapshotManager inserts an Operation into this
list and saves it to the snapshot. When an operation completes, the
SnapshotManager removes it from the snapshot. From this, the engine can
infer that if it ever sees a deployment with pending operations, the
Pulumi CLI must have crashed or otherwise abnormally terminated before
seeing whether or not an operation completed successfully.
To remedy this state, this commit also adds code to 'pulumi stack
import' that clears all pending operations from a deployment, as well as
code to plan generation that will reject any deployments that have
pending operations present.
At the CLI level, if we see that we are in a state where pending
operations were in-flight when the engine died, we'll issue a
human-friendly error message that indicates which resources are in a bad
state and how to recover their stack.
* CR: Multi-line string literals, renaming in-flight -> pending
* CR: Add enum to apitype for operation type, also name status -> type for clarity
* Fix the yaml type
* Fix missed renames
* Add implementation for lifecycle_test.go
* Rebase against master
2018-08-11 04:39:59 +00:00
|
|
|
}
|
|
|
|
|
2017-06-10 01:34:37 +00:00
|
|
|
// SerializeProperties serializes a resource property bag so that it's suitable for serialization.
|
Lift context parameter to SerializeDeployment/Resource/Operations/Properties (#15929)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
SerializePropertyValue needed a `context.Context` object to pass to the
`config.Encrypter`. It was using `context.TODO()`, this change instead
accepts a context on the parameters and lifts that up to
SerializeProperties, SerializeResource, SerializeOperation, and
SerializeDeployment.
There were a few call sites for those methods that already had a context
on hand, and they now pass that context. The other calls sites now use
`context.TODO()`, we should continue to iterate in this area to ensure
everywhere that needs a context has one passed in.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2024-04-15 07:45:46 +00:00
|
|
|
func SerializeProperties(ctx context.Context, props resource.PropertyMap, enc config.Encrypter,
|
2023-03-03 16:36:39 +00:00
|
|
|
showSecrets bool,
|
|
|
|
) (map[string]interface{}, error) {
|
2017-06-06 23:42:14 +00:00
|
|
|
dst := 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 18:50:47 +00:00
|
|
|
for _, k := range props.StableKeys() {
|
Lift context parameter to SerializeDeployment/Resource/Operations/Properties (#15929)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
SerializePropertyValue needed a `context.Context` object to pass to the
`config.Encrypter`. It was using `context.TODO()`, this change instead
accepts a context on the parameters and lifts that up to
SerializeProperties, SerializeResource, SerializeOperation, and
SerializeDeployment.
There were a few call sites for those methods that already had a context
on hand, and they now pass that context. The other calls sites now use
`context.TODO()`, we should continue to iterate in this area to ensure
everywhere that needs a context has one passed in.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2024-04-15 07:45:46 +00:00
|
|
|
v, err := SerializePropertyValue(ctx, props[k], enc, showSecrets)
|
2019-04-17 20:48:38 +00:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2019-11-22 19:03:02 +00:00
|
|
|
dst[string(k)] = v
|
2017-02-22 22:32:03 +00:00
|
|
|
}
|
2019-04-17 20:48:38 +00:00
|
|
|
return dst, nil
|
2017-02-22 22:32:03 +00:00
|
|
|
}
|
|
|
|
|
2017-06-10 01:34:37 +00:00
|
|
|
// SerializePropertyValue serializes a resource property value so that it's suitable for serialization.
|
Lift context parameter to SerializeDeployment/Resource/Operations/Properties (#15929)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
SerializePropertyValue needed a `context.Context` object to pass to the
`config.Encrypter`. It was using `context.TODO()`, this change instead
accepts a context on the parameters and lifts that up to
SerializeProperties, SerializeResource, SerializeOperation, and
SerializeDeployment.
There were a few call sites for those methods that already had a context
on hand, and they now pass that context. The other calls sites now use
`context.TODO()`, we should continue to iterate in this area to ensure
everywhere that needs a context has one passed in.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2024-04-15 07:45:46 +00:00
|
|
|
func SerializePropertyValue(ctx context.Context, prop resource.PropertyValue, enc config.Encrypter,
|
2023-03-03 16:36:39 +00:00
|
|
|
showSecrets bool,
|
|
|
|
) (interface{}, error) {
|
2019-11-22 19:03:02 +00:00
|
|
|
// Serialize nulls as nil.
|
|
|
|
if prop.IsNull() {
|
2019-04-17 20:48:38 +00:00
|
|
|
return nil, nil
|
2017-02-22 02:31:43 +00:00
|
|
|
}
|
|
|
|
|
2019-11-21 22:58:30 +00:00
|
|
|
// A computed value marks something that will be determined at a later time. (e.g. the result of
|
|
|
|
// a computation that we don't perform during a preview operation.) We serialize a magic constant
|
|
|
|
// to record its existence.
|
2019-11-22 19:03:02 +00:00
|
|
|
if prop.IsComputed() || prop.IsOutput() {
|
2019-11-21 22:58:30 +00:00
|
|
|
return computedValuePlaceholder, nil
|
|
|
|
}
|
|
|
|
|
2017-02-22 02:31:43 +00:00
|
|
|
// For arrays, make sure to recurse.
|
|
|
|
if prop.IsArray() {
|
2017-06-06 23:42:14 +00:00
|
|
|
srcarr := prop.ArrayValue()
|
|
|
|
dstarr := make([]interface{}, len(srcarr))
|
|
|
|
for i, elem := range prop.ArrayValue() {
|
Lift context parameter to SerializeDeployment/Resource/Operations/Properties (#15929)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
SerializePropertyValue needed a `context.Context` object to pass to the
`config.Encrypter`. It was using `context.TODO()`, this change instead
accepts a context on the parameters and lifts that up to
SerializeProperties, SerializeResource, SerializeOperation, and
SerializeDeployment.
There were a few call sites for those methods that already had a context
on hand, and they now pass that context. The other calls sites now use
`context.TODO()`, we should continue to iterate in this area to ensure
everywhere that needs a context has one passed in.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2024-04-15 07:45:46 +00:00
|
|
|
selem, err := SerializePropertyValue(ctx, elem, enc, showSecrets)
|
2019-04-17 20:48:38 +00:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
dstarr[i] = selem
|
2017-02-22 02:31:43 +00:00
|
|
|
}
|
2019-04-17 20:48:38 +00:00
|
|
|
return dstarr, nil
|
2017-02-22 02:31:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Also for objects, recurse and use naked properties.
|
|
|
|
if prop.IsObject() {
|
Lift context parameter to SerializeDeployment/Resource/Operations/Properties (#15929)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
SerializePropertyValue needed a `context.Context` object to pass to the
`config.Encrypter`. It was using `context.TODO()`, this change instead
accepts a context on the parameters and lifts that up to
SerializeProperties, SerializeResource, SerializeOperation, and
SerializeDeployment.
There were a few call sites for those methods that already had a context
on hand, and they now pass that context. The other calls sites now use
`context.TODO()`, we should continue to iterate in this area to ensure
everywhere that needs a context has one passed in.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2024-04-15 07:45:46 +00:00
|
|
|
return SerializeProperties(ctx, prop.ObjectValue(), enc, showSecrets)
|
2017-02-22 02:31:43 +00:00
|
|
|
}
|
|
|
|
|
2017-07-17 17:38:57 +00:00
|
|
|
// For assets, we need to serialize them a little carefully, so we can recover them afterwards.
|
|
|
|
if prop.IsAsset() {
|
2019-04-17 20:48:38 +00:00
|
|
|
return prop.AssetValue().Serialize(), nil
|
2017-07-17 17:38:57 +00:00
|
|
|
} else if prop.IsArchive() {
|
2019-04-17 20:48:38 +00:00
|
|
|
return prop.ArchiveValue().Serialize(), nil
|
2017-07-17 17:38:57 +00:00
|
|
|
}
|
|
|
|
|
2020-10-27 17:12:12 +00:00
|
|
|
// We serialize resource references using a map-based representation similar to assets, archives, and secrets.
|
|
|
|
if prop.IsResourceReference() {
|
|
|
|
ref := prop.ResourceReferenceValue()
|
2021-01-21 23:40:27 +00:00
|
|
|
serialized := map[string]interface{}{
|
2020-10-27 17:12:12 +00:00
|
|
|
resource.SigKey: resource.ResourceReferenceSig,
|
2021-01-21 23:40:27 +00:00
|
|
|
"urn": string(ref.URN),
|
2020-10-27 17:12:12 +00:00
|
|
|
"packageVersion": ref.PackageVersion,
|
2021-01-21 23:40:27 +00:00
|
|
|
}
|
|
|
|
if id, hasID := ref.IDString(); hasID {
|
|
|
|
serialized["id"] = id
|
|
|
|
}
|
|
|
|
return serialized, nil
|
2020-10-27 17:12:12 +00:00
|
|
|
}
|
|
|
|
|
2019-04-12 21:29:08 +00:00
|
|
|
if prop.IsSecret() {
|
2019-04-17 20:48:38 +00:00
|
|
|
// Since we are going to encrypt property value, we can elide encrypting sub-elements. We'll mark them as
|
2022-01-24 20:33:40 +00:00
|
|
|
// "secret" so we retain that information when deserializing the overall structure, but there is no
|
2019-04-17 20:48:38 +00:00
|
|
|
// need to double encrypt everything.
|
Lift context parameter to SerializeDeployment/Resource/Operations/Properties (#15929)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
SerializePropertyValue needed a `context.Context` object to pass to the
`config.Encrypter`. It was using `context.TODO()`, this change instead
accepts a context on the parameters and lifts that up to
SerializeProperties, SerializeResource, SerializeOperation, and
SerializeDeployment.
There were a few call sites for those methods that already had a context
on hand, and they now pass that context. The other calls sites now use
`context.TODO()`, we should continue to iterate in this area to ensure
everywhere that needs a context has one passed in.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2024-04-15 07:45:46 +00:00
|
|
|
value, err := SerializePropertyValue(ctx, prop.SecretValue().Element, config.NopEncrypter, showSecrets)
|
2019-04-17 20:48:38 +00:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2019-04-12 21:29:08 +00:00
|
|
|
bytes, err := json.Marshal(value)
|
2019-04-17 20:48:38 +00:00
|
|
|
if err != nil {
|
2021-11-13 02:37:17 +00:00
|
|
|
return nil, fmt.Errorf("encoding serialized property value: %w", err)
|
2019-04-17 20:48:38 +00:00
|
|
|
}
|
2019-09-18 22:52:31 +00:00
|
|
|
plaintext := string(bytes)
|
|
|
|
|
2020-05-11 18:16:30 +00:00
|
|
|
secret := apitype.SecretV1{
|
|
|
|
Sig: resource.SecretSig,
|
|
|
|
}
|
|
|
|
|
|
|
|
if showSecrets {
|
|
|
|
secret.Plaintext = plaintext
|
|
|
|
} else {
|
2024-01-30 09:51:51 +00:00
|
|
|
// If the encrypter is a cachingCrypter, call through its encryptSecret method, which will look for a matching
|
|
|
|
// *resource.Secret + plaintext in its cache in order to avoid re-encrypting the value.
|
|
|
|
var ciphertext string
|
|
|
|
if cachingCrypter, ok := enc.(*cachingCrypter); ok {
|
2024-03-25 10:27:47 +00:00
|
|
|
ciphertext, err = cachingCrypter.encryptSecret(ctx, prop.SecretValue(), plaintext)
|
2024-01-30 09:51:51 +00:00
|
|
|
} else {
|
|
|
|
ciphertext, err = enc.EncryptValue(ctx, plaintext)
|
|
|
|
}
|
|
|
|
if err != nil {
|
|
|
|
return nil, fmt.Errorf("failed to encrypt secret value: %w", err)
|
|
|
|
}
|
|
|
|
contract.AssertNoErrorf(err, "marshalling underlying secret value to JSON")
|
|
|
|
|
2020-05-11 18:16:30 +00:00
|
|
|
secret.Ciphertext = ciphertext
|
|
|
|
}
|
|
|
|
|
|
|
|
return secret, nil
|
2019-04-12 21:29:08 +00:00
|
|
|
}
|
|
|
|
|
2017-02-22 02:31:43 +00:00
|
|
|
// All others are returned as-is.
|
2019-04-17 20:48:38 +00:00
|
|
|
return prop.V, nil
|
2017-02-22 02:31:43 +00:00
|
|
|
}
|
|
|
|
|
2022-02-25 16:51:52 +00:00
|
|
|
// collectCiphertexts collects encrypted secrets from resource properties.
|
|
|
|
func collectCiphertexts(ciphertexts *[]string, prop interface{}) {
|
|
|
|
switch prop := prop.(type) {
|
|
|
|
case []interface{}:
|
|
|
|
for _, v := range prop {
|
|
|
|
collectCiphertexts(ciphertexts, v)
|
|
|
|
}
|
|
|
|
case map[string]interface{}:
|
|
|
|
if prop[resource.SigKey] == resource.SecretSig {
|
|
|
|
if ciphertext, cipherOk := prop["ciphertext"].(string); cipherOk {
|
|
|
|
*ciphertexts = append(*ciphertexts, ciphertext)
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
for _, v := range prop {
|
|
|
|
collectCiphertexts(ciphertexts, v)
|
2022-01-24 20:33:40 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-10-05 21:08:35 +00:00
|
|
|
// DeserializeResource turns a serialized resource back into its usual form.
|
2020-05-11 18:16:30 +00:00
|
|
|
func DeserializeResource(res apitype.ResourceV3, dec config.Decrypter, enc config.Encrypter) (*resource.State, error) {
|
2017-10-05 21:08:35 +00:00
|
|
|
// Deserialize the resource properties, if they exist.
|
2020-05-11 18:16:30 +00:00
|
|
|
inputs, err := DeserializeProperties(res.Inputs, dec, enc)
|
2017-10-22 20:39:21 +00:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2020-05-11 18:16:30 +00:00
|
|
|
outputs, err := DeserializeProperties(res.Outputs, dec, enc)
|
2017-10-22 20:39:21 +00:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2017-10-05 21:08:35 +00:00
|
|
|
|
2021-05-17 08:47:28 +00:00
|
|
|
if res.URN == "" {
|
2023-12-12 12:19:42 +00:00
|
|
|
return nil, errors.New("resource missing required 'urn' field")
|
2021-05-17 08:47:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if res.Type == "" {
|
2021-11-13 02:37:17 +00:00
|
|
|
return nil, fmt.Errorf("resource '%s' missing required 'type' field", res.URN)
|
2021-05-17 08:47:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if !res.Custom && res.ID != "" {
|
2021-11-13 02:37:17 +00:00
|
|
|
return nil, fmt.Errorf("resource '%s' has 'custom' false but non-empty ID", res.URN)
|
2021-05-17 08:47:28 +00:00
|
|
|
}
|
|
|
|
|
2017-10-22 20:39:21 +00:00
|
|
|
return resource.NewState(
|
2018-08-03 21:06:00 +00:00
|
|
|
res.Type, res.URN, res.Custom, res.Delete, res.ID,
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
inputs, outputs, res.Parent, res.Protect, res.External, res.Dependencies, res.InitErrors, res.Provider,
|
2022-03-24 19:08:18 +00:00
|
|
|
res.PropertyDependencies, res.PendingReplacement, res.AdditionalSecretOutputs, res.Aliases, res.CustomTimeouts,
|
Change `pulumi refresh` to report diff relative to desired state instead of relative to only output changes (#16146)
Presently, the behaviour of diffing during refresh steps is incomplete,
returning only an "output diff" that presents the changes in outputs.
This commit changes refresh steps so that:
* they compute a diff similar to the one that would be computed if a
`preview` were run immediately after the refresh, which is more
typically what users expect and want; and
* `IgnoreChanges` resource options are respected when performing the new
desired-state diffs, so that property additions or changes reported by a
refresh can be ignored.
In particular, `IgnoreChanges` can now be used to acknowledge that part
or all of a resource may change in the provider, but the user is OK with
this and doesn't want to be notified about it during a refresh.
Importantly, this means that the diff won't be reported, but also that
the changes won't be applied to state.
The implementation covers the following:
* A diff is computed using the inputs from the program and then
inverting the result, since in the case of a refresh the diff is being
driven by the provider side and not the program. This doesn't change
what is stored back into the state, but it does produce a diff that is
more aligned with the "true changes to the desired state".
* `IgnoreChanges` resource options are now stored in state, so that this
information can be used in refresh operations that do not have access
to/run the program.
* In the context of a refresh operation, `IgnoreChanges` applies to
*both* input and output properties. This differs from the behaviour of a
normal update operation, where `IgnoreChanges` only considers input
properties.
* The special `"*"` value for `IgnoreChanges` can be used to ignore all
properties. It _also_ ignores the case where the resource cannot be
found in the provider, and instead keeps the resource intact in state
with its existing input and output properties.
Because the program is not run for refresh operations, `IgnoreChanges`
options must be applied separately before a refresh takes place. This
can be accomplished using e.g. a `pulumi up` that applies the options
prior to a refresh. We should investigate perhaps providing a `pulumi
state set ...`-like CLI to make these sorts of changes directly to a
state.
For use cases relying on the legacy refresh diff provider, the
`PULUMI_USE_LEGACY_REFRESH_DIFF` environment variable can be set, which
will disable desired-state diff computation. We only need to perform
checks in `RefreshStep.{ResultOp,Apply}`, since downstream code will
work correctly based on the presence or absence of a `DetailedDiff` in
the step.
### Notes
- https://github.com/pulumi/pulumi/issues/16144 affects some of these
cases - though its technically orthogonal
- https://github.com/pulumi/pulumi/issues/11279 is another technically
orthogonal issue that many providers (at least TFBridge ones) - do not
report back changes to input properties on Read when the input property
(or property path) was missing on the inputs. This is again technically
orthogonal - but leads to cases that appear "wrong" in terms of what is
stored back into the state still - though the same as before this
change.
- Azure Native doesn't seem to handle `ignoreChanges` passed to Diff, so
the ability to ignore changes on refresh doesn't currently work for
Azure Native.
### Fixes
* Fixes #16072
* Fixes #16278
* Fixes #16334
* Not quite #12346, but likely replaces the need for that
Co-authored-by: Will Jones <will@sacharissa.co.uk>
2024-06-12 16:17:05 +00:00
|
|
|
res.ImportID, res.RetainOnDelete, res.DeletedWith, res.Created, res.Modified, res.SourcePosition, res.IgnoreChanges,
|
|
|
|
), nil
|
2017-10-05 21:08:35 +00:00
|
|
|
}
|
|
|
|
|
This commit adds the `Created` and `Modified` timestamps to pulumi state that are optional.
`Created`: Created tracks when the remote resource was first added to state by pulumi. Checkpoints prior to early 2023 do not include this. (Create, Import)
`Modified`: Modified tracks when the resource state was last altered. Checkpoints prior to early 2023 do not include this. (Create, Import, Read, Refresh, Update)
When serialized they will follow RFC3339 with nanoseconds captured by a test case.
https://pkg.go.dev/time#RFC3339
Note: Older versions of pulumi may strip these fields when modifying the state.
For future expansion, when we inevitably need to track other timestamps, we'll add a new "operationTimestamps" field (or something similarly named that clarified these are timestamps of the actual Pulumi operations).
operationTimestamps: {
created: ...,
updated: ...,
imported: ...,
}
Fixes https://github.com/pulumi/pulumi/issues/12022
2023-02-06 20:39:11 +00:00
|
|
|
// DeserializeOperation hydrates a pending resource/operation pair.
|
2020-05-11 18:16:30 +00:00
|
|
|
func DeserializeOperation(op apitype.OperationV2, dec config.Decrypter,
|
2023-03-03 16:36:39 +00:00
|
|
|
enc config.Encrypter,
|
|
|
|
) (resource.Operation, error) {
|
2020-05-11 18:16:30 +00:00
|
|
|
res, err := DeserializeResource(op.Resource, dec, enc)
|
Add a list of in-flight operations to the deployment (#1759)
* Add a list of in-flight operations to the deployment
This commit augments 'DeploymentV2' with a list of operations that are
currently in flight. This information is used by the engine to keep
track of whether or not a particular deployment is in a valid state.
The SnapshotManager is responsible for inserting and removing operations
from the in-flight operation list. When the engine registers an intent
to perform an operation, SnapshotManager inserts an Operation into this
list and saves it to the snapshot. When an operation completes, the
SnapshotManager removes it from the snapshot. From this, the engine can
infer that if it ever sees a deployment with pending operations, the
Pulumi CLI must have crashed or otherwise abnormally terminated before
seeing whether or not an operation completed successfully.
To remedy this state, this commit also adds code to 'pulumi stack
import' that clears all pending operations from a deployment, as well as
code to plan generation that will reject any deployments that have
pending operations present.
At the CLI level, if we see that we are in a state where pending
operations were in-flight when the engine died, we'll issue a
human-friendly error message that indicates which resources are in a bad
state and how to recover their stack.
* CR: Multi-line string literals, renaming in-flight -> pending
* CR: Add enum to apitype for operation type, also name status -> type for clarity
* Fix the yaml type
* Fix missed renames
* Add implementation for lifecycle_test.go
* Rebase against master
2018-08-11 04:39:59 +00:00
|
|
|
if err != nil {
|
|
|
|
return resource.Operation{}, err
|
|
|
|
}
|
|
|
|
return resource.NewOperation(res, resource.OperationType(op.Type)), nil
|
|
|
|
}
|
|
|
|
|
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 18:50:47 +00:00
|
|
|
// DeserializeProperties deserializes an entire map of deploy properties into a resource property map.
|
2020-05-11 18:16:30 +00:00
|
|
|
func DeserializeProperties(props map[string]interface{}, dec config.Decrypter,
|
2023-03-03 16:36:39 +00:00
|
|
|
enc config.Encrypter,
|
|
|
|
) (resource.PropertyMap, error) {
|
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 18:50:47 +00:00
|
|
|
result := make(resource.PropertyMap)
|
2017-02-22 22:32:03 +00:00
|
|
|
for k, prop := range props {
|
2020-05-11 18:16:30 +00:00
|
|
|
desprop, err := DeserializePropertyValue(prop, dec, enc)
|
2017-10-22 20:39:21 +00:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
result[resource.PropertyKey(k)] = desprop
|
2017-02-22 22:32:03 +00:00
|
|
|
}
|
2017-10-22 20:39:21 +00:00
|
|
|
return result, nil
|
2017-02-22 22:32:03 +00:00
|
|
|
}
|
|
|
|
|
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 18:50:47 +00:00
|
|
|
// DeserializePropertyValue deserializes a single deploy property into a resource property value.
|
2020-05-11 18:16:30 +00:00
|
|
|
func DeserializePropertyValue(v interface{}, dec config.Decrypter,
|
2023-03-03 16:36:39 +00:00
|
|
|
enc config.Encrypter,
|
|
|
|
) (resource.PropertyValue, error) {
|
2022-07-18 13:36:31 +00:00
|
|
|
ctx := context.TODO()
|
2017-02-22 22:32:03 +00:00
|
|
|
if v != nil {
|
|
|
|
switch w := v.(type) {
|
|
|
|
case bool:
|
2017-10-22 20:39:21 +00:00
|
|
|
return resource.NewBoolProperty(w), nil
|
2017-02-22 22:32:03 +00:00
|
|
|
case float64:
|
2017-10-22 20:39:21 +00:00
|
|
|
return resource.NewNumberProperty(w), nil
|
2017-02-22 22:32:03 +00:00
|
|
|
case string:
|
2019-11-21 22:58:30 +00:00
|
|
|
if w == computedValuePlaceholder {
|
|
|
|
return resource.MakeComputed(resource.NewStringProperty("")), nil
|
|
|
|
}
|
2017-10-22 20:39:21 +00:00
|
|
|
return resource.NewStringProperty(w), nil
|
2017-02-22 22:32:03 +00:00
|
|
|
case []interface{}:
|
2024-04-10 16:00:24 +00:00
|
|
|
arr := make([]resource.PropertyValue, len(w))
|
|
|
|
for i, elem := range w {
|
2020-05-11 18:16:30 +00:00
|
|
|
ev, err := DeserializePropertyValue(elem, dec, enc)
|
2017-10-22 20:39:21 +00:00
|
|
|
if err != nil {
|
|
|
|
return resource.PropertyValue{}, err
|
|
|
|
}
|
2024-04-10 16:00:24 +00:00
|
|
|
arr[i] = ev
|
2017-02-22 22:32:03 +00:00
|
|
|
}
|
2017-10-22 20:39:21 +00:00
|
|
|
return resource.NewArrayProperty(arr), nil
|
2017-02-22 22:32:03 +00:00
|
|
|
case map[string]interface{}:
|
2020-05-11 18:16:30 +00:00
|
|
|
obj, err := DeserializeProperties(w, dec, enc)
|
2017-10-22 20:39:21 +00:00
|
|
|
if err != nil {
|
|
|
|
return resource.PropertyValue{}, err
|
|
|
|
}
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
|
2017-07-17 17:38:57 +00:00
|
|
|
// This could be an asset or archive; if so, recover its type.
|
|
|
|
objmap := obj.Mappable()
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
if sig, hasSig := objmap[resource.SigKey]; hasSig {
|
|
|
|
switch sig {
|
Move assets and archives to their own package (#15157)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
This PR is motivated by https://github.com/pulumi/pulumi/pull/15145.
`resource.*` should be built on top of `property.Value`,[^1] which means
that `resource`
needs to be able to import `property.Value`, and so `property` cannot
import
`resource`. Since Assets and Archives are both types of properties, they
must be moved out
of `resource`.
[^1]: For example:
https://github.com/pulumi/pulumi/blob/a1d686227cd7e3c70c51bd772450cb0cd57c1479/sdk/go/common/resource/resource_state.go#L35-L36
## Open Question
This PR moves them to their own sub-folders in `resource`. Should
`asset` and `archive`
live somewhere more high level, like `sdk/go/property/{asset,archive}`?
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
## Checklist
- [ ] I have run `make tidy` to update any new dependencies
- [ ] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2024-01-25 20:39:31 +00:00
|
|
|
case asset.AssetSig:
|
|
|
|
asset, isasset, err := asset.Deserialize(objmap)
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
if err != nil {
|
|
|
|
return resource.PropertyValue{}, err
|
|
|
|
}
|
2023-02-17 18:46:23 +00:00
|
|
|
contract.Assertf(isasset, "resource with asset signature is not an asset")
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
return resource.NewAssetProperty(asset), nil
|
Move assets and archives to their own package (#15157)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
This PR is motivated by https://github.com/pulumi/pulumi/pull/15145.
`resource.*` should be built on top of `property.Value`,[^1] which means
that `resource`
needs to be able to import `property.Value`, and so `property` cannot
import
`resource`. Since Assets and Archives are both types of properties, they
must be moved out
of `resource`.
[^1]: For example:
https://github.com/pulumi/pulumi/blob/a1d686227cd7e3c70c51bd772450cb0cd57c1479/sdk/go/common/resource/resource_state.go#L35-L36
## Open Question
This PR moves them to their own sub-folders in `resource`. Should
`asset` and `archive`
live somewhere more high level, like `sdk/go/property/{asset,archive}`?
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
## Checklist
- [ ] I have run `make tidy` to update any new dependencies
- [ ] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2024-01-25 20:39:31 +00:00
|
|
|
case archive.ArchiveSig:
|
|
|
|
archive, isarchive, err := archive.Deserialize(objmap)
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
if err != nil {
|
|
|
|
return resource.PropertyValue{}, err
|
|
|
|
}
|
2023-02-17 18:46:23 +00:00
|
|
|
contract.Assertf(isarchive, "resource with archive signature is not an archive")
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
return resource.NewArchiveProperty(archive), nil
|
|
|
|
case resource.SecretSig:
|
2020-05-11 18:16:30 +00:00
|
|
|
ciphertext, cipherOk := objmap["ciphertext"].(string)
|
|
|
|
plaintext, plainOk := objmap["plaintext"].(string)
|
|
|
|
if (!cipherOk && !plainOk) || (plainOk && cipherOk) {
|
|
|
|
return resource.PropertyValue{}, errors.New(
|
|
|
|
"malformed secret value: one of `ciphertext` or `plaintext` must be supplied")
|
2019-04-12 21:29:08 +00:00
|
|
|
}
|
2020-05-11 18:16:30 +00:00
|
|
|
|
|
|
|
if plainOk {
|
2022-07-18 13:36:31 +00:00
|
|
|
encryptedText, err := enc.EncryptValue(ctx, plaintext)
|
2020-05-11 18:16:30 +00:00
|
|
|
if err != nil {
|
2021-11-13 02:37:17 +00:00
|
|
|
return resource.PropertyValue{}, fmt.Errorf("encrypting secret value: %w", err)
|
2020-05-11 18:16:30 +00:00
|
|
|
}
|
|
|
|
ciphertext = encryptedText
|
|
|
|
|
|
|
|
} else {
|
2022-07-18 13:36:31 +00:00
|
|
|
unencryptedText, err := dec.DecryptValue(ctx, ciphertext)
|
2020-05-11 18:16:30 +00:00
|
|
|
if err != nil {
|
2023-12-20 15:54:06 +00:00
|
|
|
return resource.PropertyValue{}, fmt.Errorf("error decrypting secret value: %w", err)
|
2020-05-11 18:16:30 +00:00
|
|
|
}
|
|
|
|
plaintext = unencryptedText
|
2019-04-17 20:48:38 +00:00
|
|
|
}
|
2020-05-11 18:16:30 +00:00
|
|
|
|
|
|
|
var elem interface{}
|
|
|
|
|
2019-04-17 20:48:38 +00:00
|
|
|
if err := json.Unmarshal([]byte(plaintext), &elem); err != nil {
|
2019-04-12 21:29:08 +00:00
|
|
|
return resource.PropertyValue{}, err
|
|
|
|
}
|
2020-05-11 18:16:30 +00:00
|
|
|
ev, err := DeserializePropertyValue(elem, config.NopDecrypter, enc)
|
2019-04-12 21:29:08 +00:00
|
|
|
if err != nil {
|
|
|
|
return resource.PropertyValue{}, err
|
|
|
|
}
|
2019-09-18 22:52:31 +00:00
|
|
|
prop := resource.MakeSecret(ev)
|
|
|
|
// If the decrypter is a cachingCrypter, insert the plain- and ciphertext into the cache with the
|
|
|
|
// new *resource.Secret as the key.
|
|
|
|
if cachingCrypter, ok := dec.(*cachingCrypter); ok {
|
|
|
|
cachingCrypter.insert(prop.SecretValue(), plaintext, ciphertext)
|
|
|
|
}
|
|
|
|
return prop, nil
|
2020-10-27 17:12:12 +00:00
|
|
|
case resource.ResourceReferenceSig:
|
2021-01-21 23:40:27 +00:00
|
|
|
var packageVersion string
|
|
|
|
if packageVersionV, ok := objmap["packageVersion"]; ok {
|
|
|
|
packageVersion, ok = packageVersionV.(string)
|
|
|
|
if !ok {
|
|
|
|
return resource.PropertyValue{},
|
|
|
|
errors.New("malformed resource reference: packageVersion must be a string")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-27 17:12:12 +00:00
|
|
|
urnStr, ok := objmap["urn"].(string)
|
|
|
|
if !ok {
|
2021-01-21 23:40:27 +00:00
|
|
|
return resource.PropertyValue{}, errors.New("malformed resource reference: missing urn")
|
2020-10-27 17:12:12 +00:00
|
|
|
}
|
|
|
|
urn := resource.URN(urnStr)
|
|
|
|
|
2021-01-21 23:40:27 +00:00
|
|
|
// deserializeID handles two cases, one of which arose from a bug in a refactoring of resource.ResourceReference.
|
|
|
|
// This bug caused the raw ID PropertyValue to be serialized as a map[string]interface{}. In the normal case, the
|
|
|
|
// ID is serialized as a string.
|
|
|
|
deserializeID := func() (string, bool, error) {
|
|
|
|
idV, ok := objmap["id"]
|
2020-10-27 17:12:12 +00:00
|
|
|
if !ok {
|
2021-01-21 23:40:27 +00:00
|
|
|
return "", false, nil
|
2020-10-27 17:12:12 +00:00
|
|
|
}
|
2021-01-21 20:37:40 +00:00
|
|
|
|
2021-01-21 23:40:27 +00:00
|
|
|
switch idV := idV.(type) {
|
|
|
|
case string:
|
|
|
|
return idV, true, nil
|
|
|
|
case map[string]interface{}:
|
|
|
|
switch v := idV["V"].(type) {
|
|
|
|
case nil:
|
|
|
|
// This happens for component resource references, which do not have an associated ID.
|
|
|
|
return "", false, nil
|
|
|
|
case string:
|
|
|
|
// This happens for custom resource references, which do have an associated ID.
|
|
|
|
return v, true, nil
|
|
|
|
case map[string]interface{}:
|
|
|
|
// This happens for custom resource references with an unknown ID. In this case, the ID should be
|
|
|
|
// deserialized as the empty string.
|
|
|
|
return "", true, nil
|
|
|
|
}
|
2021-01-21 20:37:40 +00:00
|
|
|
}
|
2021-01-21 23:40:27 +00:00
|
|
|
return "", false, errors.New("malformed resource reference: id must be a string")
|
2020-10-27 17:12:12 +00:00
|
|
|
}
|
|
|
|
|
2021-01-21 23:40:27 +00:00
|
|
|
id, hasID, err := deserializeID()
|
|
|
|
if err != nil {
|
|
|
|
return resource.PropertyValue{}, err
|
|
|
|
}
|
|
|
|
if hasID {
|
|
|
|
return resource.MakeCustomResourceReference(urn, resource.ID(id), packageVersion), nil
|
|
|
|
}
|
|
|
|
return resource.MakeComponentResourceReference(urn, packageVersion), nil
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
default:
|
2021-11-13 02:37:17 +00:00
|
|
|
return resource.PropertyValue{}, fmt.Errorf("unrecognized signature '%v' in property map", sig)
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
}
|
2017-07-17 17:38:57 +00:00
|
|
|
}
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
|
2017-07-17 17:38:57 +00:00
|
|
|
// Otherwise, it's just a weakly typed object map.
|
2017-10-22 20:39:21 +00:00
|
|
|
return resource.NewObjectProperty(obj), nil
|
2017-02-22 22:32:03 +00:00
|
|
|
default:
|
2021-09-21 22:02:10 +00:00
|
|
|
contract.Failf("Unrecognized property type %T: %v", v, reflect.ValueOf(v))
|
2017-02-22 22:32:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-10-22 20:39:21 +00:00
|
|
|
return resource.NewNullProperty(), nil
|
2017-02-22 02:31:43 +00:00
|
|
|
}
|