2024-04-11 22:54:08 +00:00
|
|
|
// Copyright 2016-2024, 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.
|
|
|
|
|
2018-04-26 00:20:08 +00:00
|
|
|
package backend
|
|
|
|
|
|
|
|
import (
|
2021-11-13 02:37:17 +00:00
|
|
|
"errors"
|
|
|
|
"fmt"
|
2018-08-20 21:14:50 +00:00
|
|
|
"reflect"
|
2018-04-26 00:20:08 +00:00
|
|
|
"time"
|
|
|
|
|
2024-04-18 08:14:51 +00:00
|
|
|
"golang.org/x/exp/slices"
|
|
|
|
|
2021-03-17 13:20:05 +00:00
|
|
|
"github.com/pulumi/pulumi/pkg/v3/engine"
|
|
|
|
"github.com/pulumi/pulumi/pkg/v3/resource/deploy"
|
|
|
|
"github.com/pulumi/pulumi/pkg/v3/secrets"
|
|
|
|
"github.com/pulumi/pulumi/pkg/v3/version"
|
2022-12-15 14:46:39 +00:00
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/env"
|
2021-03-17 13:20:05 +00:00
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/resource"
|
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/util/contract"
|
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/util/logging"
|
2018-04-26 00:20:08 +00:00
|
|
|
)
|
|
|
|
|
2023-12-04 15:12:56 +00:00
|
|
|
// DisableIntegrityChecking can be set to true to disable checkpoint state integrity verification. This is not
|
|
|
|
// recommended, because it could mean proceeding even in the face of a corrupted checkpoint state file, but can
|
|
|
|
// be used as a last resort when a command absolutely must be run.
|
|
|
|
var DisableIntegrityChecking bool
|
|
|
|
|
2018-04-26 00:20:08 +00:00
|
|
|
// SnapshotPersister is an interface implemented by our backends that implements snapshot
|
|
|
|
// persistence. In order to fit into our current model, snapshot persisters have two functions:
|
|
|
|
// saving snapshots and invalidating already-persisted snapshots.
|
|
|
|
type SnapshotPersister interface {
|
|
|
|
// Persists the given snapshot. Returns an error if the persistence failed.
|
|
|
|
Save(snapshot *deploy.Snapshot) error
|
|
|
|
}
|
|
|
|
|
|
|
|
// SnapshotManager is an implementation of engine.SnapshotManager that inspects steps and performs
|
|
|
|
// mutations on the global snapshot object serially. This implementation maintains two bits of state: the "base"
|
|
|
|
// snapshot, which is completely immutable and represents the state of the world prior to the application
|
|
|
|
// of the current plan, and a "new" list of resources, which consists of the resources that were operated upon
|
|
|
|
// by the current plan.
|
|
|
|
//
|
|
|
|
// Important to note is that, although this SnapshotManager is designed to be easily convertible into a thread-safe
|
|
|
|
// implementation, the code as it is today is *not thread safe*. In particular, it is not legal for there to be
|
|
|
|
// more than one `SnapshotMutation` active at any point in time. This is because this SnapshotManager invalidates
|
|
|
|
// the last persisted snapshot in `BeginSnapshot`. This is designed to match existing behavior and will not
|
|
|
|
// be the state of things going forward.
|
|
|
|
//
|
|
|
|
// The resources stored in the `resources` slice are pointers to resource objects allocated by the engine.
|
|
|
|
// This is subtle and a little confusing. The reason for this is that the engine directly mutates resource objects
|
|
|
|
// that it creates and expects those mutations to be persisted directly to the snapshot.
|
|
|
|
type SnapshotManager struct {
|
|
|
|
persister SnapshotPersister // The persister responsible for invalidating and persisting the snapshot
|
|
|
|
baseSnapshot *deploy.Snapshot // The base snapshot for this plan
|
2023-09-19 18:31:56 +00:00
|
|
|
secretsManager secrets.Manager // The default secrets manager to use
|
2018-04-26 00:20:08 +00:00
|
|
|
resources []*resource.State // The list of resources operated upon by this plan
|
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
|
|
|
operations []resource.Operation // The set of operations known to be outstanding in this plan
|
2018-04-26 00:20:08 +00:00
|
|
|
dones map[*resource.State]bool // The set of resources that have been operated upon already by this plan
|
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
|
|
|
completeOps map[*resource.State]bool // The set of resources that have completed their operation
|
2018-08-20 21:14:50 +00:00
|
|
|
mutationRequests chan<- mutationRequest // The queue of mutation requests, to be retired serially by the manager
|
2018-08-30 04:00:05 +00:00
|
|
|
cancel chan bool // A channel used to request cancellation of any new mutation requests.
|
2018-08-20 21:14:50 +00:00
|
|
|
done <-chan error // A channel that sends a single result when the manager has shut down.
|
2018-04-26 00:20:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
var _ engine.SnapshotManager = (*SnapshotManager)(nil)
|
|
|
|
|
2018-08-20 21:14:50 +00:00
|
|
|
type mutationRequest struct {
|
|
|
|
mutator func() bool
|
|
|
|
result chan<- error
|
|
|
|
}
|
|
|
|
|
2018-04-26 00:20:08 +00:00
|
|
|
func (sm *SnapshotManager) Close() error {
|
2018-08-30 04:00:05 +00:00
|
|
|
close(sm.cancel)
|
2018-08-20 21:14:50 +00:00
|
|
|
return <-sm.done
|
2018-04-26 00:20:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// If you need to understand what's going on in this file, start here!
|
|
|
|
//
|
|
|
|
// mutate is the serialization point for reads and writes of the global snapshot state.
|
|
|
|
// The given function will be, at the time of its invocation, the only function allowed to
|
|
|
|
// mutate state within the SnapshotManager.
|
|
|
|
//
|
2018-08-20 21:14:50 +00:00
|
|
|
// Serialization is performed by pushing the mutator function onto a channel, where another
|
2018-04-26 00:20:08 +00:00
|
|
|
// goroutine is polling the channel and executing the mutation functions as they come.
|
|
|
|
// This function optionally verifies the integrity of the snapshot before and after mutation.
|
2018-08-20 21:14:50 +00:00
|
|
|
//
|
|
|
|
// The mutator may indicate that its corresponding checkpoint write may be safely elided by
|
|
|
|
// returning `false`. As of this writing, we only elide writes after same steps with no
|
|
|
|
// meaningful changes (see sameSnapshotMutation.mustWrite for details). Any elided writes
|
|
|
|
// are flushed by the next non-elided write or the next call to Close.
|
2018-04-26 00:20:08 +00:00
|
|
|
//
|
|
|
|
// You should never observe or mutate the global snapshot without using this function unless
|
|
|
|
// you have a very good justification.
|
2018-08-20 21:14:50 +00:00
|
|
|
func (sm *SnapshotManager) mutate(mutator func() bool) error {
|
|
|
|
result := make(chan error)
|
2018-08-30 04:00:05 +00:00
|
|
|
select {
|
|
|
|
case sm.mutationRequests <- mutationRequest{mutator: mutator, result: result}:
|
|
|
|
return <-result
|
|
|
|
case <-sm.cancel:
|
|
|
|
return errors.New("snapshot manager closed")
|
|
|
|
}
|
2018-04-26 00:20:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// RegisterResourceOutputs handles the registering of outputs on a Step that has already
|
|
|
|
// completed. This is accomplished by doing an in-place mutation of the resources currently
|
|
|
|
// resident in the snapshot.
|
|
|
|
//
|
|
|
|
// Due to the way this is currently implemented, the engine directly mutates output properties
|
|
|
|
// on the resource State object that it created. Since we are storing pointers to these objects
|
|
|
|
// in the `resources` slice, we need only to do a no-op mutation in order to flush these new
|
|
|
|
// mutations to disk.
|
|
|
|
//
|
|
|
|
// Note that this is completely not thread-safe and defeats the purpose of having a `mutate` callback
|
|
|
|
// entirely, but the hope is that this state of things will not be permament.
|
|
|
|
func (sm *SnapshotManager) RegisterResourceOutputs(step deploy.Step) error {
|
2024-04-18 22:09:08 +00:00
|
|
|
return sm.mutate(func() bool {
|
|
|
|
old, new := step.Old(), step.New()
|
|
|
|
if old != nil && new != nil && old.Outputs.DeepEquals(new.Outputs) {
|
|
|
|
logging.V(9).Infof("SnapshotManager: eliding RegisterResourceOutputs due to equal outputs")
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
|
|
|
return true
|
|
|
|
})
|
2018-04-26 00:20:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// BeginMutation signals to the SnapshotManager that the engine intends to mutate the global snapshot
|
|
|
|
// by performing the given Step. This function gives the SnapshotManager a chance to record the
|
|
|
|
// intent to mutate before the mutation occurs.
|
|
|
|
func (sm *SnapshotManager) BeginMutation(step deploy.Step) (engine.SnapshotMutation, error) {
|
2023-02-16 20:36:43 +00:00
|
|
|
contract.Requiref(step != nil, "step", "cannot be nil")
|
2020-07-09 14:19:12 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager: Beginning mutation for step `%s` on resource `%s`", step.Op(), step.URN())
|
2018-04-26 00:20:08 +00:00
|
|
|
|
|
|
|
switch step.Op() {
|
|
|
|
case deploy.OpSame:
|
|
|
|
return &sameSnapshotMutation{sm}, nil
|
|
|
|
case deploy.OpCreate, deploy.OpCreateReplacement:
|
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
|
|
|
return sm.doCreate(step)
|
2018-04-26 00:20:08 +00:00
|
|
|
case deploy.OpUpdate:
|
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
|
|
|
return sm.doUpdate(step)
|
2019-01-31 21:48:44 +00:00
|
|
|
case deploy.OpDelete, deploy.OpDeleteReplaced, deploy.OpReadDiscard, deploy.OpDiscardReplaced:
|
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
|
|
|
return sm.doDelete(step)
|
2018-04-26 00:20:08 +00:00
|
|
|
case deploy.OpReplace:
|
2018-08-08 20:45:48 +00:00
|
|
|
return &replaceSnapshotMutation{sm}, nil
|
2018-08-03 21:06:00 +00:00
|
|
|
case deploy.OpRead, deploy.OpReadReplacement:
|
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
|
|
|
return sm.doRead(step)
|
2018-08-23 00:52:46 +00:00
|
|
|
case deploy.OpRefresh:
|
|
|
|
return &refreshSnapshotMutation{sm}, 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
|
|
|
case deploy.OpRemovePendingReplace:
|
|
|
|
return &removePendingReplaceSnapshotMutation{sm}, nil
|
2019-07-12 18:12:01 +00:00
|
|
|
case deploy.OpImport, deploy.OpImportReplacement:
|
|
|
|
return sm.doImport(step)
|
2018-04-26 00:20:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
contract.Failf("unknown StepOp: %s", step.Op())
|
|
|
|
return nil, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// All SnapshotMutation implementations in this file follow the same basic formula:
|
|
|
|
// mark the "old" state as done and mark the "new" state as new. The two special
|
|
|
|
// cases are Create (where the "old" state does not exist) and Delete (where the "new" state
|
|
|
|
// does not exist).
|
|
|
|
//
|
|
|
|
// Marking a resource state as old prevents it from being persisted to the snapshot in
|
|
|
|
// the `snap` function. Marking a resource state as new /enables/ it to be persisted to
|
|
|
|
// the snapshot in `snap`. See the comments in `snap` for more details.
|
|
|
|
|
|
|
|
type sameSnapshotMutation struct {
|
|
|
|
manager *SnapshotManager
|
|
|
|
}
|
|
|
|
|
2018-08-20 21:14:50 +00:00
|
|
|
// mustWrite returns true if any semantically meaningful difference exists between the old and new states of a same
|
|
|
|
// step that forces us to write the checkpoint. If no such difference exists, the checkpoint write that corresponds to
|
|
|
|
// this step can be elided.
|
2019-11-19 04:28:25 +00:00
|
|
|
func (ssm *sameSnapshotMutation) mustWrite(step *deploy.SameStep) bool {
|
|
|
|
old := step.Old()
|
|
|
|
new := step.New()
|
|
|
|
|
2023-02-16 20:36:43 +00:00
|
|
|
contract.Assertf(old.Delete == new.Delete,
|
|
|
|
"either both or neither resource must be pending deletion, got %v (old) != %v (new)",
|
|
|
|
old.Delete, new.Delete)
|
|
|
|
contract.Assertf(old.External == new.External,
|
|
|
|
"either both or neither resource must be external, got %v (old) != %v (new)",
|
|
|
|
old.External, new.External)
|
|
|
|
contract.Assertf(!step.IsSkippedCreate(), "create cannot be skipped for step")
|
2019-11-19 04:28:25 +00:00
|
|
|
|
2019-06-01 06:01:01 +00:00
|
|
|
// If the URN of this resource has changed, we must write the checkpoint. This should only be possible when a
|
|
|
|
// resource is aliased.
|
|
|
|
if old.URN != new.URN {
|
2021-02-22 22:04:57 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager: mustWrite() true because of URN")
|
2019-06-01 06:01:01 +00:00
|
|
|
return true
|
|
|
|
}
|
|
|
|
|
|
|
|
// If the type of this resource has changed, we must write the checkpoint. This should only be possible when a
|
|
|
|
// resource is aliased.
|
|
|
|
if old.Type != new.Type {
|
2021-02-22 22:04:57 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager: mustWrite() true because of Type")
|
2019-06-01 06:01:01 +00:00
|
|
|
return true
|
|
|
|
}
|
|
|
|
|
2018-08-20 21:14:50 +00:00
|
|
|
// If the kind of this resource has changed, we must write the checkpoint.
|
|
|
|
if old.Custom != new.Custom {
|
2021-02-22 22:04:57 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager: mustWrite() true because of Custom")
|
2018-08-20 21:14:50 +00:00
|
|
|
return true
|
|
|
|
}
|
|
|
|
|
Addition of Custom Timeouts (#2885)
* Plumbing the custom timeouts from the engine to the providers
* Plumbing the CustomTimeouts through to the engine and adding test to show this
* Change the provider proto to include individual timeouts
* Plumbing the CustomTimeouts from the engine through to the Provider RPC interface
* Change how the CustomTimeouts are sent across RPC
These errors were spotted in testing. We can now see that the timeout
information is arriving in the RegisterResourceRequest
```
req=&pulumirpc.RegisterResourceRequest{
Type: "aws:s3/bucket:Bucket",
Name: "my-bucket",
Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev",
Custom: true,
Object: &structpb.Struct{},
Protect: false,
Dependencies: nil,
Provider: "",
PropertyDependencies: {},
DeleteBeforeReplace: false,
Version: "",
IgnoreChanges: nil,
AcceptSecrets: true,
AdditionalSecretOutputs: nil,
Aliases: nil,
CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{
Create: 300,
Update: 400,
Delete: 500,
XXX_NoUnkeyedLiteral: struct {}{},
XXX_unrecognized: nil,
XXX_sizecache: 0,
},
XXX_NoUnkeyedLiteral: struct {}{},
XXX_unrecognized: nil,
XXX_sizecache: 0,
}
```
* Changing the design to use strings
* CHANGELOG entry to include the CustomTimeouts work
* Changing custom timeouts to be passed around the engine as converted value
We don't want to pass around strings - the user can provide it but we want
to make the engine aware of the timeout in seconds as a float64
2019-07-15 21:26:28 +00:00
|
|
|
// We need to persist the changes if CustomTimes have changed
|
|
|
|
if old.CustomTimeouts != new.CustomTimeouts {
|
2021-02-22 22:04:57 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager: mustWrite() true because of CustomTimeouts")
|
Addition of Custom Timeouts (#2885)
* Plumbing the custom timeouts from the engine to the providers
* Plumbing the CustomTimeouts through to the engine and adding test to show this
* Change the provider proto to include individual timeouts
* Plumbing the CustomTimeouts from the engine through to the Provider RPC interface
* Change how the CustomTimeouts are sent across RPC
These errors were spotted in testing. We can now see that the timeout
information is arriving in the RegisterResourceRequest
```
req=&pulumirpc.RegisterResourceRequest{
Type: "aws:s3/bucket:Bucket",
Name: "my-bucket",
Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev",
Custom: true,
Object: &structpb.Struct{},
Protect: false,
Dependencies: nil,
Provider: "",
PropertyDependencies: {},
DeleteBeforeReplace: false,
Version: "",
IgnoreChanges: nil,
AcceptSecrets: true,
AdditionalSecretOutputs: nil,
Aliases: nil,
CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{
Create: 300,
Update: 400,
Delete: 500,
XXX_NoUnkeyedLiteral: struct {}{},
XXX_unrecognized: nil,
XXX_sizecache: 0,
},
XXX_NoUnkeyedLiteral: struct {}{},
XXX_unrecognized: nil,
XXX_sizecache: 0,
}
```
* Changing the design to use strings
* CHANGELOG entry to include the CustomTimeouts work
* Changing custom timeouts to be passed around the engine as converted value
We don't want to pass around strings - the user can provide it but we want
to make the engine aware of the timeout in seconds as a float64
2019-07-15 21:26:28 +00:00
|
|
|
return true
|
|
|
|
}
|
|
|
|
|
2022-02-16 22:11:12 +00:00
|
|
|
// We need to persist the changes if CustomTimes have changed
|
|
|
|
if old.RetainOnDelete != new.RetainOnDelete {
|
|
|
|
logging.V(9).Infof("SnapshotManager: mustWrite() true because of RetainOnDelete")
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
|
2023-02-16 20:36:43 +00:00
|
|
|
contract.Assertf(old.ID == new.ID,
|
|
|
|
"old and new resource IDs must be equal, got %v (old) != %v (new)", old.ID, new.ID)
|
2019-06-05 23:27:26 +00:00
|
|
|
|
|
|
|
// If this resource's provider has changed, we must write the checkpoint. This can happen in scenarios involving
|
|
|
|
// aliased providers or upgrades to default providers.
|
|
|
|
if old.Provider != new.Provider {
|
2021-02-22 22:04:57 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager: mustWrite() true because of Provider")
|
2019-06-05 23:27:26 +00:00
|
|
|
return true
|
|
|
|
}
|
2018-08-20 21:14:50 +00:00
|
|
|
|
|
|
|
// If this resource's parent has changed, we must write the checkpoint.
|
|
|
|
if old.Parent != new.Parent {
|
2021-02-22 22:04:57 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager: mustWrite() true because of Parent")
|
2018-08-20 21:14:50 +00:00
|
|
|
return true
|
|
|
|
}
|
|
|
|
|
2022-10-20 06:15:43 +00:00
|
|
|
// If the DeletedWith attribute of this resource has changed, we must write the checkpoint.
|
|
|
|
if old.DeletedWith != new.DeletedWith {
|
|
|
|
logging.V(9).Infof("SnapshotManager: mustWrite() true because of DeletedWith")
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
|
2018-08-20 21:14:50 +00:00
|
|
|
// If the protection attribute of this resource has changed, we must write the checkpoint.
|
|
|
|
if old.Protect != new.Protect {
|
2021-02-22 22:04:57 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager: mustWrite() true because of Protect")
|
2018-08-20 21:14:50 +00:00
|
|
|
return true
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
// If the source position of this resource has changed, we must write the checkpoint.
|
|
|
|
if old.SourcePosition != new.SourcePosition {
|
|
|
|
logging.V(9).Infof("SnapshotManager: mustWrite() true because of SourcePosition")
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
|
2018-09-07 22:10:02 +00:00
|
|
|
// If the inputs or outputs of this resource have changed, we must write the checkpoint. Note that it is possible
|
|
|
|
// for the inputs of a "same" resource to have changed even if the contents of the input bags are different if the
|
|
|
|
// resource's provider deems the physical change to be semantically irrelevant.
|
2021-02-22 22:04:57 +00:00
|
|
|
if !old.Inputs.DeepEquals(new.Inputs) {
|
|
|
|
logging.V(9).Infof("SnapshotManager: mustWrite() true because of Inputs")
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
if !old.Outputs.DeepEquals(new.Outputs) {
|
|
|
|
logging.V(9).Infof("SnapshotManager: mustWrite() true because of Outputs")
|
2018-08-20 21:14:50 +00:00
|
|
|
return true
|
|
|
|
}
|
|
|
|
|
2020-02-05 02:56:24 +00:00
|
|
|
// reflect.DeepEqual does not treat `nil` and `[]URN{}` as equal, so we must check for both
|
|
|
|
// lists being empty ourselves.
|
|
|
|
if len(old.Dependencies) != 0 || len(new.Dependencies) != 0 {
|
2024-04-11 22:54:08 +00:00
|
|
|
// Sort dependencies before comparing them. If the dependencies have changed, we must write the checkpoint.
|
|
|
|
sortDeps := func(deps []resource.URN) []resource.URN {
|
|
|
|
result := make([]resource.URN, len(deps))
|
|
|
|
copy(result, deps)
|
2024-04-18 08:14:51 +00:00
|
|
|
slices.Sort(result)
|
2024-04-11 22:54:08 +00:00
|
|
|
return result
|
|
|
|
}
|
|
|
|
oldDeps := sortDeps(old.Dependencies)
|
|
|
|
newDeps := sortDeps(new.Dependencies)
|
|
|
|
if !reflect.DeepEqual(oldDeps, newDeps) {
|
2021-02-22 22:04:57 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager: mustWrite() true because of Dependencies")
|
2020-02-05 02:56:24 +00:00
|
|
|
return true
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Init errors are strictly advisory, so we do not consider them when deciding whether or not to write the
|
|
|
|
// checkpoint.
|
|
|
|
|
2021-02-22 22:04:57 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager: mustWrite() false")
|
2020-02-05 02:56:24 +00:00
|
|
|
return false
|
2018-08-20 21:14:50 +00:00
|
|
|
}
|
|
|
|
|
2018-04-26 00:20:08 +00:00
|
|
|
func (ssm *sameSnapshotMutation) End(step deploy.Step, successful bool) error {
|
2023-02-16 20:36:43 +00:00
|
|
|
contract.Requiref(step != nil, "step", "must not be nil")
|
|
|
|
contract.Requiref(step.Op() == deploy.OpSame, "step.Op()", "must be %q, got %q", deploy.OpSame, step.Op())
|
2018-05-18 20:54:23 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager: sameSnapshotMutation.End(..., %v)", successful)
|
2018-08-20 21:14:50 +00:00
|
|
|
return ssm.manager.mutate(func() bool {
|
2020-01-24 20:37:13 +00:00
|
|
|
sameStep := step.(*deploy.SameStep)
|
|
|
|
|
2023-10-13 11:13:22 +00:00
|
|
|
ssm.manager.markOperationComplete(step.New())
|
|
|
|
if successful {
|
|
|
|
ssm.manager.markDone(step.Old())
|
|
|
|
|
|
|
|
// In the case of a 'resource create' in a program that wasn't specified by the user in the
|
|
|
|
// --target list, we *never* want to write this to the checkpoint. We treat it as if it
|
|
|
|
// doesn't exist at all. That way when the program runs the next time, we'll actually
|
|
|
|
// create it.
|
|
|
|
if sameStep.IsSkippedCreate() {
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
|
|
|
ssm.manager.markNew(step.New())
|
|
|
|
|
|
|
|
// Note that "Same" steps only consider input and provider diffs, so it is possible to see a same step for a
|
|
|
|
// resource with new dependencies, outputs, parent, protection. etc.
|
|
|
|
//
|
|
|
|
// As such, we diff all of the non-input properties of the resource here and write the snapshot if we find any
|
|
|
|
// changes.
|
|
|
|
if !ssm.mustWrite(sameStep) {
|
|
|
|
logging.V(9).Infof("SnapshotManager: sameSnapshotMutation.End() eliding write")
|
|
|
|
return false
|
|
|
|
}
|
2018-04-26 00:20:08 +00:00
|
|
|
}
|
2020-01-24 20:37:13 +00:00
|
|
|
|
2021-02-22 22:04:57 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager: sameSnapshotMutation.End() not eliding write")
|
2018-08-20 21:14:50 +00:00
|
|
|
return true
|
2018-04-26 00:20:08 +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
|
|
|
func (sm *SnapshotManager) doCreate(step deploy.Step) (engine.SnapshotMutation, error) {
|
2020-07-09 14:19:12 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager.doCreate(%s)", step.URN())
|
2018-08-20 21:14:50 +00:00
|
|
|
err := sm.mutate(func() bool {
|
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
|
|
|
sm.markOperationPending(step.New(), resource.OperationTypeCreating)
|
2018-08-20 21:14:50 +00:00
|
|
|
return true
|
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
|
|
|
|
}
|
|
|
|
|
|
|
|
return &createSnapshotMutation{sm}, nil
|
|
|
|
}
|
|
|
|
|
2018-04-26 00:20:08 +00:00
|
|
|
type createSnapshotMutation struct {
|
|
|
|
manager *SnapshotManager
|
|
|
|
}
|
|
|
|
|
|
|
|
func (csm *createSnapshotMutation) End(step deploy.Step, successful bool) error {
|
2023-02-16 20:36:43 +00:00
|
|
|
contract.Requiref(step != nil, "step", "must not be nil")
|
2018-05-18 20:54:23 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager: createSnapshotMutation.End(..., %v)", successful)
|
2018-08-20 21:14:50 +00:00
|
|
|
return csm.manager.mutate(func() bool {
|
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
|
|
|
csm.manager.markOperationComplete(step.New())
|
2018-04-26 00:20:08 +00:00
|
|
|
if successful {
|
|
|
|
// There is some very subtle behind-the-scenes magic here that
|
|
|
|
// comes into play whenever this create is a CreateReplacement.
|
|
|
|
//
|
|
|
|
// Despite intending for the base snapshot to be immutable, the engine
|
|
|
|
// does in fact mutate it by setting a `Delete` flag on resources
|
|
|
|
// being replaced as part of a Create-Before-Delete replacement sequence.
|
|
|
|
// Since we are storing the base snapshot and all resources by reference
|
|
|
|
// (we have pointers to engine-allocated objects), this transparently
|
|
|
|
// "just works" for the SnapshotManager.
|
|
|
|
csm.manager.markNew(step.New())
|
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 we had an old state that was marked as pending-replacement, mark its replacement as complete such
|
|
|
|
// that it is flushed from the state file.
|
|
|
|
if old := step.Old(); old != nil && old.PendingReplacement {
|
|
|
|
csm.manager.markDone(old)
|
|
|
|
}
|
2018-04-26 00:20:08 +00:00
|
|
|
}
|
2018-08-20 21:14:50 +00:00
|
|
|
return true
|
2018-04-26 00:20:08 +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
|
|
|
func (sm *SnapshotManager) doUpdate(step deploy.Step) (engine.SnapshotMutation, error) {
|
2020-07-09 14:19:12 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager.doUpdate(%s)", step.URN())
|
2018-08-20 21:14:50 +00:00
|
|
|
err := sm.mutate(func() bool {
|
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
|
|
|
sm.markOperationPending(step.New(), resource.OperationTypeUpdating)
|
2018-08-20 21:14:50 +00:00
|
|
|
return true
|
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
|
|
|
|
}
|
|
|
|
|
|
|
|
return &updateSnapshotMutation{sm}, nil
|
|
|
|
}
|
|
|
|
|
2018-04-26 00:20:08 +00:00
|
|
|
type updateSnapshotMutation struct {
|
|
|
|
manager *SnapshotManager
|
|
|
|
}
|
|
|
|
|
|
|
|
func (usm *updateSnapshotMutation) End(step deploy.Step, successful bool) error {
|
2023-02-16 20:36:43 +00:00
|
|
|
contract.Requiref(step != nil, "step", "must not be nil")
|
2018-05-18 20:54:23 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager: updateSnapshotMutation.End(..., %v)", successful)
|
2018-08-20 21:14:50 +00:00
|
|
|
return usm.manager.mutate(func() bool {
|
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
|
|
|
usm.manager.markOperationComplete(step.New())
|
2018-04-26 00:20:08 +00:00
|
|
|
if successful {
|
|
|
|
usm.manager.markDone(step.Old())
|
|
|
|
usm.manager.markNew(step.New())
|
|
|
|
}
|
2018-08-20 21:14:50 +00:00
|
|
|
return true
|
2018-04-26 00:20:08 +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
|
|
|
func (sm *SnapshotManager) doDelete(step deploy.Step) (engine.SnapshotMutation, error) {
|
2020-07-09 14:19:12 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager.doDelete(%s)", step.URN())
|
2018-08-20 21:14:50 +00:00
|
|
|
err := sm.mutate(func() bool {
|
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
|
|
|
sm.markOperationPending(step.Old(), resource.OperationTypeDeleting)
|
2018-08-20 21:14:50 +00:00
|
|
|
return true
|
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
|
|
|
|
}
|
|
|
|
|
|
|
|
return &deleteSnapshotMutation{sm}, nil
|
|
|
|
}
|
|
|
|
|
2018-04-26 00:20:08 +00:00
|
|
|
type deleteSnapshotMutation struct {
|
|
|
|
manager *SnapshotManager
|
|
|
|
}
|
|
|
|
|
|
|
|
func (dsm *deleteSnapshotMutation) End(step deploy.Step, successful bool) error {
|
2023-02-16 20:36:43 +00:00
|
|
|
contract.Requiref(step != nil, "step", "must not be nil")
|
2018-05-18 20:54:23 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager: deleteSnapshotMutation.End(..., %v)", successful)
|
2018-08-20 21:14:50 +00:00
|
|
|
return dsm.manager.mutate(func() bool {
|
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
|
|
|
dsm.manager.markOperationComplete(step.Old())
|
2018-04-26 00:20:08 +00:00
|
|
|
if successful {
|
2023-02-16 20:36:43 +00:00
|
|
|
contract.Assertf(
|
2022-02-17 19:52:38 +00:00
|
|
|
!step.Old().Protect ||
|
|
|
|
step.Op() == deploy.OpDiscardReplaced ||
|
2023-02-16 20:36:43 +00:00
|
|
|
step.Op() == deploy.OpDeleteReplaced,
|
|
|
|
"Old must be unprotected (got %v) or the operation must be a replace (got %q)",
|
|
|
|
step.Old().Protect, step.Op())
|
2022-02-17 19:52: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
|
|
|
if !step.Old().PendingReplacement {
|
|
|
|
dsm.manager.markDone(step.Old())
|
|
|
|
}
|
2018-04-26 00:20:08 +00:00
|
|
|
}
|
2018-08-20 21:14:50 +00:00
|
|
|
return true
|
2018-04-26 00:20:08 +00:00
|
|
|
})
|
|
|
|
}
|
|
|
|
|
2018-08-08 20:45:48 +00:00
|
|
|
type replaceSnapshotMutation struct {
|
|
|
|
manager *SnapshotManager
|
|
|
|
}
|
2018-04-26 00:20:08 +00:00
|
|
|
|
2018-08-08 20:45:48 +00:00
|
|
|
func (rsm *replaceSnapshotMutation) End(step deploy.Step, successful bool) error {
|
|
|
|
logging.V(9).Infof("SnapshotManager: replaceSnapshotMutation.End(..., %v)", successful)
|
2018-08-20 21:14:50 +00:00
|
|
|
return nil
|
2018-08-08 20:45:48 +00:00
|
|
|
}
|
2018-04-26 00:20:08 +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
|
|
|
func (sm *SnapshotManager) doRead(step deploy.Step) (engine.SnapshotMutation, error) {
|
2020-07-09 14:19:12 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager.doRead(%s)", step.URN())
|
2018-08-20 21:14:50 +00:00
|
|
|
err := sm.mutate(func() bool {
|
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
|
|
|
sm.markOperationPending(step.New(), resource.OperationTypeReading)
|
2018-08-20 21:14:50 +00:00
|
|
|
return true
|
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
|
|
|
|
}
|
|
|
|
|
|
|
|
return &readSnapshotMutation{sm}, nil
|
|
|
|
}
|
|
|
|
|
2018-08-03 21:06:00 +00:00
|
|
|
type readSnapshotMutation struct {
|
|
|
|
manager *SnapshotManager
|
|
|
|
}
|
|
|
|
|
|
|
|
func (rsm *readSnapshotMutation) End(step deploy.Step, successful bool) error {
|
2023-02-16 20:36:43 +00:00
|
|
|
contract.Requiref(step != nil, "step", "must not be nil")
|
2018-08-03 21:06:00 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager: readSnapshotMutation.End(..., %v)", successful)
|
2018-08-20 21:14:50 +00:00
|
|
|
return rsm.manager.mutate(func() bool {
|
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
|
|
|
rsm.manager.markOperationComplete(step.New())
|
2018-08-03 21:06:00 +00:00
|
|
|
if successful {
|
|
|
|
if step.Old() != nil {
|
|
|
|
rsm.manager.markDone(step.Old())
|
|
|
|
}
|
|
|
|
|
|
|
|
rsm.manager.markNew(step.New())
|
|
|
|
}
|
2018-08-20 21:14:50 +00:00
|
|
|
return true
|
2018-08-03 21:06:00 +00:00
|
|
|
})
|
|
|
|
}
|
|
|
|
|
2018-08-23 00:52:46 +00:00
|
|
|
type refreshSnapshotMutation struct {
|
|
|
|
manager *SnapshotManager
|
|
|
|
}
|
|
|
|
|
|
|
|
func (rsm *refreshSnapshotMutation) End(step deploy.Step, successful bool) error {
|
2023-02-16 20:36:43 +00:00
|
|
|
contract.Requiref(step != nil, "step", "must not be nil")
|
|
|
|
contract.Requiref(step.Op() == deploy.OpRefresh, "step.Op", "must be %q, got %q", deploy.OpRefresh, step.Op())
|
2018-08-23 00:52:46 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager: refreshSnapshotMutation.End(..., %v)", successful)
|
|
|
|
return rsm.manager.mutate(func() bool {
|
|
|
|
// We always elide refreshes. The expectation is that all of these run before any actual mutations and that
|
|
|
|
// some other component will rewrite the base snapshot in-memory, so there's no action the snapshot
|
|
|
|
// manager needs to take other than to remember that the base snapshot--and therefore the actual snapshot--may
|
|
|
|
// have changed.
|
|
|
|
return false
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
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
|
|
|
type removePendingReplaceSnapshotMutation struct {
|
|
|
|
manager *SnapshotManager
|
|
|
|
}
|
|
|
|
|
|
|
|
func (rsm *removePendingReplaceSnapshotMutation) End(step deploy.Step, successful bool) error {
|
2023-02-16 20:36:43 +00:00
|
|
|
contract.Requiref(step != nil, "step", "must not be nil")
|
|
|
|
contract.Requiref(step.Op() == deploy.OpRemovePendingReplace, "step.Op",
|
|
|
|
"must be %q, got %q", deploy.OpRemovePendingReplace, step.Op())
|
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 rsm.manager.mutate(func() bool {
|
|
|
|
res := step.Old()
|
2023-02-16 20:36:43 +00:00
|
|
|
contract.Assertf(res.PendingReplacement, "resource %q must be pending replacement", res.URN)
|
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
|
|
|
rsm.manager.markDone(res)
|
|
|
|
return true
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
2019-07-12 18:12:01 +00:00
|
|
|
func (sm *SnapshotManager) doImport(step deploy.Step) (engine.SnapshotMutation, error) {
|
2020-07-09 14:19:12 +00:00
|
|
|
logging.V(9).Infof("SnapshotManager.doImport(%s)", step.URN())
|
2019-07-12 18:12:01 +00:00
|
|
|
err := sm.mutate(func() bool {
|
|
|
|
sm.markOperationPending(step.New(), resource.OperationTypeImporting)
|
|
|
|
return true
|
|
|
|
})
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
return &importSnapshotMutation{sm}, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
type importSnapshotMutation struct {
|
|
|
|
manager *SnapshotManager
|
|
|
|
}
|
|
|
|
|
|
|
|
func (ism *importSnapshotMutation) End(step deploy.Step, successful bool) error {
|
2023-02-16 20:36:43 +00:00
|
|
|
contract.Requiref(step != nil, "step", "must not be nil")
|
|
|
|
contract.Requiref(step.Op() == deploy.OpImport || step.Op() == deploy.OpImportReplacement, "step.Op",
|
|
|
|
"must be %q or %q, got %q", deploy.OpImport, deploy.OpImportReplacement, step.Op())
|
2019-07-12 18:12:01 +00:00
|
|
|
|
|
|
|
return ism.manager.mutate(func() bool {
|
|
|
|
ism.manager.markOperationComplete(step.New())
|
|
|
|
if successful {
|
|
|
|
ism.manager.markNew(step.New())
|
|
|
|
}
|
|
|
|
return true
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
2018-04-26 00:20:08 +00:00
|
|
|
// markDone marks a resource as having been processed. Resources that have been marked
|
|
|
|
// in this manner won't be persisted in the snapshot.
|
|
|
|
func (sm *SnapshotManager) markDone(state *resource.State) {
|
2023-02-16 20:36:43 +00:00
|
|
|
contract.Requiref(state != nil, "state", "must not be nil")
|
2018-04-26 00:20:08 +00:00
|
|
|
sm.dones[state] = true
|
2018-05-15 22:28:00 +00:00
|
|
|
logging.V(9).Infof("Marked old state snapshot as done: %v", state.URN)
|
2018-04-26 00:20:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// markNew marks a resource as existing in the new snapshot. This occurs on
|
|
|
|
// successful non-deletion operations where the given state is the new state
|
|
|
|
// of a resource that will be persisted to the snapshot.
|
|
|
|
func (sm *SnapshotManager) markNew(state *resource.State) {
|
2023-02-16 20:36:43 +00:00
|
|
|
contract.Requiref(state != nil, "state", "must not be nil")
|
2018-04-26 00:20:08 +00:00
|
|
|
sm.resources = append(sm.resources, state)
|
2018-05-15 22:28:00 +00:00
|
|
|
logging.V(9).Infof("Appended new state snapshot to be written: %v", state.URN)
|
2018-04-26 00:20:08 +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
|
|
|
// markOperationPending marks a resource as undergoing an operation that will now be considered pending.
|
|
|
|
func (sm *SnapshotManager) markOperationPending(state *resource.State, op resource.OperationType) {
|
2023-02-16 20:36:43 +00:00
|
|
|
contract.Requiref(state != nil, "state", "must not be 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
|
|
|
sm.operations = append(sm.operations, resource.NewOperation(state, op))
|
|
|
|
logging.V(9).Infof("SnapshotManager.markPendingOperation(%s, %s)", state.URN, string(op))
|
|
|
|
}
|
|
|
|
|
|
|
|
// markOperationComplete marks a resource as having completed the operation that it previously was performing.
|
|
|
|
func (sm *SnapshotManager) markOperationComplete(state *resource.State) {
|
2023-02-16 20:36:43 +00:00
|
|
|
contract.Requiref(state != nil, "state", "must not be 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
|
|
|
sm.completeOps[state] = true
|
|
|
|
logging.V(9).Infof("SnapshotManager.markOperationComplete(%s)", state.URN)
|
|
|
|
}
|
|
|
|
|
2018-04-26 00:20:08 +00:00
|
|
|
// snap produces a new Snapshot given the base snapshot and a list of resources that the current
|
|
|
|
// plan has created.
|
|
|
|
func (sm *SnapshotManager) snap() *deploy.Snapshot {
|
|
|
|
// At this point we have two resource DAGs. One of these is the base DAG for this plan; the other is the current DAG
|
|
|
|
// for this plan. Any resource r may be present in both DAGs. In order to produce a snapshot, we need to merge these
|
|
|
|
// DAGs such that all resource dependencies are correctly preserved. Conceptually, the merge proceeds as follows:
|
|
|
|
//
|
|
|
|
// - Begin with an empty merged DAG.
|
|
|
|
// - For each resource r in the current DAG, insert r and its outgoing edges into the merged DAG.
|
|
|
|
// - For each resource r in the base DAG:
|
|
|
|
// - If r is in the merged DAG, we are done: if the resource is in the merged DAG, it must have been in the
|
|
|
|
// current DAG, which accurately captures its current dependencies.
|
|
|
|
// - If r is not in the merged DAG, insert it and its outgoing edges into the merged DAG.
|
|
|
|
//
|
|
|
|
// Physically, however, each DAG is represented as list of resources without explicit dependency edges. In place of
|
|
|
|
// edges, it is assumed that the list represents a valid topological sort of its source DAG. Thus, any resource r at
|
|
|
|
// index i in a list L must be assumed to be dependent on all resources in L with index j s.t. j < i. Due to this
|
|
|
|
// representation, we implement the algorithm above as follows to produce a merged list that represents a valid
|
|
|
|
// topological sort of the merged DAG:
|
|
|
|
//
|
|
|
|
// - Begin with an empty merged list.
|
|
|
|
// - For each resource r in the current list, append r to the merged list. r must be in a correct location in the
|
|
|
|
// merged list, as its position relative to its assumed dependencies has not changed.
|
|
|
|
// - For each resource r in the base list:
|
|
|
|
// - If r is in the merged list, we are done by the logic given in the original algorithm.
|
|
|
|
// - If r is not in the merged list, append r to the merged list. r must be in a correct location in the merged
|
|
|
|
// list:
|
|
|
|
// - If any of r's dependencies were in the current list, they must already be in the merged list and their
|
|
|
|
// relative order w.r.t. r has not changed.
|
|
|
|
// - If any of r's dependencies were not in the current list, they must already be in the merged list, as
|
|
|
|
// they would have been appended to the list before r.
|
|
|
|
|
|
|
|
// Start with a copy of the resources produced during the evaluation of the current plan.
|
|
|
|
resources := make([]*resource.State, len(sm.resources))
|
|
|
|
copy(resources, sm.resources)
|
|
|
|
|
|
|
|
// Append any resources from the base plan that were not produced by the current plan.
|
|
|
|
if base := sm.baseSnapshot; base != nil {
|
|
|
|
for _, res := range base.Resources {
|
|
|
|
if !sm.dones[res] {
|
|
|
|
resources = append(resources, res)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
// Record any pending operations, if there are any outstanding that have not completed yet.
|
|
|
|
var operations []resource.Operation
|
|
|
|
for _, op := range sm.operations {
|
|
|
|
if !sm.completeOps[op.Resource] {
|
|
|
|
operations = append(operations, op)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-03-25 09:59:19 +00:00
|
|
|
// Track pending create operations from the base snapshot
|
|
|
|
// and propagate them to the new snapshot: we don't want to clear pending CREATE operations
|
|
|
|
// because these must require user intervention to be cleared or resolved.
|
2022-03-25 22:11:18 +00:00
|
|
|
if base := sm.baseSnapshot; base != nil {
|
|
|
|
for _, pendingOperation := range base.PendingOperations {
|
|
|
|
if pendingOperation.Type == resource.OperationTypeCreating {
|
|
|
|
operations = append(operations, pendingOperation)
|
|
|
|
}
|
2022-03-25 09:59:19 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-04-26 00:20:08 +00:00
|
|
|
manifest := deploy.Manifest{
|
|
|
|
Time: time.Now(),
|
|
|
|
Version: version.Version,
|
2019-04-23 16:53:44 +00:00
|
|
|
// Plugins: sm.plugins, - Explicitly dropped, since we don't use the plugin list in the manifest anymore.
|
2018-04-26 00:20:08 +00:00
|
|
|
}
|
|
|
|
|
2023-09-19 18:31:56 +00:00
|
|
|
// The backend.SnapshotManager and backend.SnapshotPersister will keep track of any changes to
|
|
|
|
// the Snapshot (checkpoint file) in the HTTP backend. We will reuse the snapshot's secrets manager when possible
|
|
|
|
// to ensure that secrets are not re-encrypted on each update.
|
|
|
|
secretsManager := sm.secretsManager
|
|
|
|
if sm.baseSnapshot != nil && secrets.AreCompatible(secretsManager, sm.baseSnapshot.SecretsManager) {
|
|
|
|
secretsManager = sm.baseSnapshot.SecretsManager
|
|
|
|
}
|
|
|
|
|
2018-04-26 00:20:08 +00:00
|
|
|
manifest.Magic = manifest.NewMagic()
|
2023-09-19 18:31:56 +00:00
|
|
|
return deploy.NewSnapshot(manifest, secretsManager, resources, operations)
|
2018-04-26 00:20:08 +00:00
|
|
|
}
|
|
|
|
|
2018-08-20 21:14:50 +00:00
|
|
|
// saveSnapshot persists the current snapshot and optionally verifies it afterwards.
|
|
|
|
func (sm *SnapshotManager) saveSnapshot() error {
|
2022-07-18 18:04:19 +00:00
|
|
|
snap, err := sm.snap().NormalizeURNReferences()
|
|
|
|
if err != nil {
|
2021-11-13 02:37:17 +00:00
|
|
|
return fmt.Errorf("failed to normalize URN references: %w", err)
|
2019-11-06 16:49:13 +00:00
|
|
|
}
|
2018-08-20 21:14:50 +00:00
|
|
|
if err := sm.persister.Save(snap); err != nil {
|
2021-11-13 02:37:17 +00:00
|
|
|
return fmt.Errorf("failed to save snapshot: %w", err)
|
2018-08-20 21:14:50 +00:00
|
|
|
}
|
2024-04-11 16:38:19 +00:00
|
|
|
if !DisableIntegrityChecking {
|
|
|
|
if err := snap.VerifyIntegrity(); err != nil {
|
|
|
|
return fmt.Errorf("failed to verify snapshot: %w", err)
|
|
|
|
}
|
2018-08-20 21:14:50 +00:00
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2022-09-15 16:46:45 +00:00
|
|
|
// defaultServiceLoop saves a Snapshot whenever a mutation occurs
|
|
|
|
func (sm *SnapshotManager) defaultServiceLoop(mutationRequests chan mutationRequest, done chan error) {
|
|
|
|
// True if we have elided writes since the last actual write.
|
2024-04-11 22:54:08 +00:00
|
|
|
hasElidedWrites := true
|
2022-09-15 16:46:45 +00:00
|
|
|
|
|
|
|
// Service each mutation request in turn.
|
|
|
|
serviceLoop:
|
|
|
|
for {
|
|
|
|
select {
|
|
|
|
case request := <-mutationRequests:
|
|
|
|
var err error
|
|
|
|
if request.mutator() {
|
|
|
|
err = sm.saveSnapshot()
|
|
|
|
hasElidedWrites = false
|
|
|
|
} else {
|
|
|
|
hasElidedWrites = true
|
|
|
|
}
|
|
|
|
request.result <- err
|
|
|
|
case <-sm.cancel:
|
|
|
|
break serviceLoop
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we still have elided writes once the channel has closed, flush the snapshot.
|
|
|
|
var err error
|
|
|
|
if hasElidedWrites {
|
|
|
|
logging.V(9).Infof("SnapshotManager: flushing elided writes...")
|
|
|
|
err = sm.saveSnapshot()
|
|
|
|
}
|
|
|
|
done <- err
|
|
|
|
}
|
|
|
|
|
2022-09-14 17:01:42 +00:00
|
|
|
// unsafeServiceLoop doesn't save Snapshots when mutations occur and instead saves Snapshots when
|
|
|
|
// SnapshotManager.Close() is invoked. It trades reliability for speed as every mutation does not
|
|
|
|
// cause a Snapshot to be serialized to the user's state backend.
|
2022-09-12 21:53:50 +00:00
|
|
|
func (sm *SnapshotManager) unsafeServiceLoop(mutationRequests chan mutationRequest, done chan error) {
|
|
|
|
for {
|
|
|
|
select {
|
|
|
|
case request := <-mutationRequests:
|
|
|
|
request.mutator()
|
|
|
|
request.result <- nil
|
|
|
|
case <-sm.cancel:
|
|
|
|
done <- sm.saveSnapshot()
|
|
|
|
return
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-09-19 18:31:56 +00:00
|
|
|
// NewSnapshotManager creates a new SnapshotManager for the given stack name, using the given persister, default secrets
|
|
|
|
// manager and base snapshot.
|
2018-04-26 00:20:08 +00:00
|
|
|
//
|
2023-09-19 18:31:56 +00:00
|
|
|
// It is *very important* that the baseSnap pointer refers to the same Snapshot given to the engine! The engine will
|
|
|
|
// mutate this object and correctness of the SnapshotManager depends on being able to observe this mutation. (This is
|
|
|
|
// not ideal...)
|
|
|
|
func NewSnapshotManager(
|
|
|
|
persister SnapshotPersister,
|
|
|
|
secretsManager secrets.Manager,
|
|
|
|
baseSnap *deploy.Snapshot,
|
|
|
|
) *SnapshotManager {
|
2018-08-30 04:00:05 +00:00
|
|
|
mutationRequests, cancel, done := make(chan mutationRequest), make(chan bool), make(chan error)
|
2018-08-20 21:14:50 +00:00
|
|
|
|
2018-04-26 00:20:08 +00:00
|
|
|
manager := &SnapshotManager{
|
|
|
|
persister: persister,
|
2023-09-19 18:31:56 +00:00
|
|
|
secretsManager: secretsManager,
|
2018-04-26 00:20:08 +00:00
|
|
|
baseSnapshot: baseSnap,
|
|
|
|
dones: make(map[*resource.State]bool),
|
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
|
|
|
completeOps: make(map[*resource.State]bool),
|
2018-08-20 21:14:50 +00:00
|
|
|
mutationRequests: mutationRequests,
|
2018-08-30 04:00:05 +00:00
|
|
|
cancel: cancel,
|
2018-08-20 21:14:50 +00:00
|
|
|
done: done,
|
2018-04-26 00:20:08 +00:00
|
|
|
}
|
|
|
|
|
2022-09-15 16:46:45 +00:00
|
|
|
serviceLoop := manager.defaultServiceLoop
|
2022-09-15 20:00:44 +00:00
|
|
|
|
2022-12-15 14:46:39 +00:00
|
|
|
if env.SkipCheckpoints.Value() {
|
2022-09-15 16:46:45 +00:00
|
|
|
serviceLoop = manager.unsafeServiceLoop
|
|
|
|
}
|
2022-09-15 20:00:44 +00:00
|
|
|
|
2022-09-15 16:46:45 +00:00
|
|
|
go serviceLoop(mutationRequests, done)
|
2018-04-26 00:20:08 +00:00
|
|
|
|
|
|
|
return manager
|
|
|
|
}
|