pulumi/pkg/engine/deployment_test.go

170 lines
4.2 KiB
Go
Raw Normal View History

ctrl-c should cause Pulumi to call Cancel operation on providers (#14057) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description Fixes #14054 This PR fixes a problem that the engine cannot forward a cancellation signal to the provider, because the plugin context is already closed. An [earlier commit](https://github.com/pulumi/pulumi/pull/9793/commits/a9ae602867834efc9821abd866ef388c1b051114) made the plugin context be closed too eagerly, with the intent of cancelling plugin installation. This PR attempts to decouple the cancellation of plugin installation from the lifecycle of the plugin context, so that plugin installation may be cancelled during the cancelation phase as opposed to the termination phase. Then, it closes the plugin context in termination phase. There's an existing test case in the engine lifecycle tests called `TestProviderCancellation`, but it didn't catch the problem because it uses a fake plugin host that behaves differently after being closed. The issue was fixed in https://github.com/pulumi/pulumi/pull/14063 and the test was temporarily disabled. This PR re-enables the test case. A new test case `TestSourceFuncCancellation` is added to test cancellation of the source func (where plugin installation happens, see [update.go](https://github.com/pulumi/pulumi/pull/14057/files#diff-7d2ca3e83a05073b332435271496050e28466b4f7af8c0c91bbc77947a75a3a2R378)), as this was the original motivation of https://github.com/pulumi/pulumi/pull/9793/commits/a9ae602867834efc9821abd866ef388c1b051114. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] ~Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version~ <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-09-29 22:12:35 +00:00
// Copyright 2016-2023, Pulumi Corporation.
//
// 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.
package engine
import (
"context"
"sync"
"testing"
"github.com/stretchr/testify/assert"
"github.com/pulumi/pulumi/pkg/v3/resource/deploy"
"github.com/pulumi/pulumi/pkg/v3/resource/deploy/deploytest"
"github.com/pulumi/pulumi/pkg/v3/util/cancel"
"github.com/pulumi/pulumi/sdk/v3/go/common/resource/plugin"
"github.com/pulumi/pulumi/sdk/v3/go/common/testing/diagtest"
Add tokens.StackName (#14487) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds a new type `tokens.StackName` which is a relatively strongly typed container for a stack name. The only weakly typed aspect of it is Go will always allow the "zero" value to be created for a struct, which for a stack name is the empty string which is invalid. To prevent introducing unexpected empty strings when working with stack names the `String()` method will panic for zero initialized stack names. Apart from the zero value, all other instances of `StackName` are via `ParseStackName` which returns a descriptive error if the string is not valid. This PR only updates "pkg/" to use this type. There are a number of places in "sdk/" which could do with this type as well, but there's no harm in doing a staggered roll out, and some parts of "sdk/" are user facing and will probably have to stay on the current `tokens.Name` and `tokens.QName` types. There are two places in the system where we panic on invalid stack names, both in the http backend. This _should_ be fine as we've had long standing validation that stacks created in the service are valid stack names. Just in case people have managed to introduce invalid stack names, there is the `PULUMI_DISABLE_VALIDATION` environment variable which will turn off the validation _and_ panicing for stack names. Users can use that to temporarily disable the validation and continue working, but it should only be seen as a temporary measure. If they have invalid names they should rename them, or if they think they should be valid raise an issue with us to change the validation code. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-11-15 07:44:54 +00:00
"github.com/pulumi/pulumi/sdk/v3/go/common/tokens"
ctrl-c should cause Pulumi to call Cancel operation on providers (#14057) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description Fixes #14054 This PR fixes a problem that the engine cannot forward a cancellation signal to the provider, because the plugin context is already closed. An [earlier commit](https://github.com/pulumi/pulumi/pull/9793/commits/a9ae602867834efc9821abd866ef388c1b051114) made the plugin context be closed too eagerly, with the intent of cancelling plugin installation. This PR attempts to decouple the cancellation of plugin installation from the lifecycle of the plugin context, so that plugin installation may be cancelled during the cancelation phase as opposed to the termination phase. Then, it closes the plugin context in termination phase. There's an existing test case in the engine lifecycle tests called `TestProviderCancellation`, but it didn't catch the problem because it uses a fake plugin host that behaves differently after being closed. The issue was fixed in https://github.com/pulumi/pulumi/pull/14063 and the test was temporarily disabled. This PR re-enables the test case. A new test case `TestSourceFuncCancellation` is added to test cancellation of the source func (where plugin installation happens, see [update.go](https://github.com/pulumi/pulumi/pull/14057/files#diff-7d2ca3e83a05073b332435271496050e28466b4f7af8c0c91bbc77947a75a3a2R378)), as this was the original motivation of https://github.com/pulumi/pulumi/pull/9793/commits/a9ae602867834efc9821abd866ef388c1b051114. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] ~Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version~ <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-09-29 22:12:35 +00:00
"github.com/pulumi/pulumi/sdk/v3/go/common/util/contract"
"github.com/pulumi/pulumi/sdk/v3/go/common/workspace"
)
type updateInfo struct {
project workspace.Project
target deploy.Target
}
func (u *updateInfo) GetRoot() string {
return ""
}
func (u *updateInfo) GetProject() *workspace.Project {
return &u.project
}
func (u *updateInfo) GetTarget() *deploy.Target {
return &u.target
}
func makeUpdateInfo() *updateInfo {
return &updateInfo{
project: workspace.Project{
Name: "test",
Runtime: workspace.NewProjectRuntimeInfo("test", nil),
},
Add tokens.StackName (#14487) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds a new type `tokens.StackName` which is a relatively strongly typed container for a stack name. The only weakly typed aspect of it is Go will always allow the "zero" value to be created for a struct, which for a stack name is the empty string which is invalid. To prevent introducing unexpected empty strings when working with stack names the `String()` method will panic for zero initialized stack names. Apart from the zero value, all other instances of `StackName` are via `ParseStackName` which returns a descriptive error if the string is not valid. This PR only updates "pkg/" to use this type. There are a number of places in "sdk/" which could do with this type as well, but there's no harm in doing a staggered roll out, and some parts of "sdk/" are user facing and will probably have to stay on the current `tokens.Name` and `tokens.QName` types. There are two places in the system where we panic on invalid stack names, both in the http backend. This _should_ be fine as we've had long standing validation that stacks created in the service are valid stack names. Just in case people have managed to introduce invalid stack names, there is the `PULUMI_DISABLE_VALIDATION` environment variable which will turn off the validation _and_ panicing for stack names. Users can use that to temporarily disable the validation and continue working, but it should only be seen as a temporary measure. If they have invalid names they should rename them, or if they think they should be valid raise an issue with us to change the validation code. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-11-15 07:44:54 +00:00
target: deploy.Target{Name: tokens.MustParseStackName("test")},
ctrl-c should cause Pulumi to call Cancel operation on providers (#14057) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description Fixes #14054 This PR fixes a problem that the engine cannot forward a cancellation signal to the provider, because the plugin context is already closed. An [earlier commit](https://github.com/pulumi/pulumi/pull/9793/commits/a9ae602867834efc9821abd866ef388c1b051114) made the plugin context be closed too eagerly, with the intent of cancelling plugin installation. This PR attempts to decouple the cancellation of plugin installation from the lifecycle of the plugin context, so that plugin installation may be cancelled during the cancelation phase as opposed to the termination phase. Then, it closes the plugin context in termination phase. There's an existing test case in the engine lifecycle tests called `TestProviderCancellation`, but it didn't catch the problem because it uses a fake plugin host that behaves differently after being closed. The issue was fixed in https://github.com/pulumi/pulumi/pull/14063 and the test was temporarily disabled. This PR re-enables the test case. A new test case `TestSourceFuncCancellation` is added to test cancellation of the source func (where plugin installation happens, see [update.go](https://github.com/pulumi/pulumi/pull/14057/files#diff-7d2ca3e83a05073b332435271496050e28466b4f7af8c0c91bbc77947a75a3a2R378)), as this was the original motivation of https://github.com/pulumi/pulumi/pull/9793/commits/a9ae602867834efc9821abd866ef388c1b051114. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] ~Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version~ <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-09-29 22:12:35 +00:00
}
}
type testContext struct {
Context
wg sync.WaitGroup
events chan Event
journal *Journal
firedEvents []Event
}
func makeTestContext(t testing.TB, cancelCtx *cancel.Context) *testContext {
events := make(chan Event)
journal := NewJournal()
ctx := &testContext{
Context: Context{
Cancel: cancelCtx,
Events: events,
SnapshotManager: journal,
BackendClient: nil,
},
events: events,
journal: journal,
}
// Begin draining events.
ctx.wg.Add(1)
go func() {
for e := range events {
ctx.firedEvents = append(ctx.firedEvents, e)
}
ctx.wg.Done()
}()
return ctx
}
func (ctx *testContext) makeEventEmitter(t testing.TB) eventEmitter {
emitter, err := makeQueryEventEmitter(ctx.events)
assert.NoError(t, err)
return emitter
}
func (ctx *testContext) Close() error {
contract.IgnoreClose(ctx.journal)
close(ctx.events)
return nil
}
func makePluginHost(t testing.TB, program deploytest.ProgramFunc) plugin.Host {
sink := diagtest.LogSink(t)
statusSink := diagtest.LogSink(t)
lang := deploytest.NewLanguageRuntime(program)
return deploytest.NewPluginHost(sink, statusSink, lang)
}
// Tests cancellation during early stage of deployment, e.g. plugin installation.
func TestSourceFuncCancellation(t *testing.T) {
t.Parallel()
// Set up a cancelable context for the operation.
cancelCtx, cancelSrc := cancel.NewContext(context.Background())
// Wait for our source func, then cancel.
ops := make(chan bool)
go func() {
<-ops
cancelSrc.Cancel()
}()
// Create a source func that waits for cancellation.
sourceF := func(ctx context.Context,
client deploy.BackendClient, opts *deploymentOptions, proj *workspace.Project, pwd, main, projectRoot string,
Clean up deployment options (#16357) # Description There are a number of parts of the deployment process that require context about and configuration for the operation being executed. For instance: * Source evaluation -- evaluating programs in order to emit resource registrations * Step generation -- processing resource registrations in order to generate steps (create this, update that, delete the other, etc.) * Step execution -- executing steps in order to action a deployment. Presently, these pieces all take some form of `Options` struct or pass explicit arguments. This is problematic for a couple of reasons: * It could be possible for different parts of the codebase to end up operating in different contexts/with different configurations, whether due to different values being passed explicitly or due to missed copying/instantiation. * Some parts need less context/configuration than others, but still accept full `Options`, making it hard to discern what information is actually necessary in any given part of the process. This commit attempts to clean things up by moving deployment options directly into the `Deployment` itself. Since step generation and execution already refer to a `Deployment`, they get a consistent view of the options for free. For source evaluation, we introduce an `EvalSourceOptions` struct for configuring just the options necessary there. At the top level, the engine configures a single set of options to flow through the deployment steps later on. As part of this work, a few other things have been changed: * Preview/dry-run parameters have been incorporated into options. This lets up lop off another argument and mitigate a bit of "boolean blindness". We don't appear to flip this flag within a deployment process (indeed, all options seem to be immutable) and so having it as a separate flag doesn't seem to buy us anything. * Several methods representing parts of the deployment process have lost arguments in favour of state that is already being carried on (or can be carried on) their receiver. For instance, `deployment.run` no longer takes actions or preview configuration. While doing so means that a `deployment` could be run multiple times with different actions/preview arguments, we don't currently exploit this fact anywhere, so moving this state to the point of construction both simplifies things considerably and reduces the possibility for error (e.g. passing different values of `preview` when instantiating a `deployment` and subsequently calling `run`). * Event handlers have been split out of the options object and attached to `Deployment` separately. This means we can talk about options at a higher level without having to `nil` out/worry about this field and mutate it correctly later on. * Options are no longer mutated during deployment. Presently there appears to be only one case of this -- when handling `ContinueOnError` in the presence of `IgnoreChanges` (e.g. when performing a refresh). This case has been refactored so that the mutation is no longer necessary. # Notes * This change is in preparation for #16146, where we'd like to add an environment variable to control behaviour and having a single unified `Options` struct would make it easier to pass this configuration down with introducing (more) global state into deployments. Indeed, this change should make it easier to factor global state into `Options` so that it can be controlled and tested more easily/is less susceptible to bugs, race conditions, etc. * I've tweaked/extended some comments while I'm here and have learned things the hard way (e.g. `Refresh` vs `isRefresh`). Feedback welcome on this if we'd rather not conflate. * This change does mean that if in future we wanted e.g. to be able to run a `Deployment` in multiple different ways with multiple sets of actions, we'd have to refactor. Pushing state to the point of object construction reduces the flexibility of the code. However, since we are not presently using that flexibility (nor is there an obvious [to my mind] use case in the near future), this seems like a good trade-off to guard against bugs/make it simpler to move that state around. * I've left some other review comments in the code around questions/changes that might be a bad idea; happy to receive feedback on it all though!
2024-06-11 13:37:57 +00:00
target *deploy.Target, plugctx *plugin.Context,
ctrl-c should cause Pulumi to call Cancel operation on providers (#14057) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description Fixes #14054 This PR fixes a problem that the engine cannot forward a cancellation signal to the provider, because the plugin context is already closed. An [earlier commit](https://github.com/pulumi/pulumi/pull/9793/commits/a9ae602867834efc9821abd866ef388c1b051114) made the plugin context be closed too eagerly, with the intent of cancelling plugin installation. This PR attempts to decouple the cancellation of plugin installation from the lifecycle of the plugin context, so that plugin installation may be cancelled during the cancelation phase as opposed to the termination phase. Then, it closes the plugin context in termination phase. There's an existing test case in the engine lifecycle tests called `TestProviderCancellation`, but it didn't catch the problem because it uses a fake plugin host that behaves differently after being closed. The issue was fixed in https://github.com/pulumi/pulumi/pull/14063 and the test was temporarily disabled. This PR re-enables the test case. A new test case `TestSourceFuncCancellation` is added to test cancellation of the source func (where plugin installation happens, see [update.go](https://github.com/pulumi/pulumi/pull/14057/files#diff-7d2ca3e83a05073b332435271496050e28466b4f7af8c0c91bbc77947a75a3a2R378)), as this was the original motivation of https://github.com/pulumi/pulumi/pull/9793/commits/a9ae602867834efc9821abd866ef388c1b051114. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] ~Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version~ <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-09-29 22:12:35 +00:00
) (deploy.Source, error) {
// Send ops completion then wait for the cancellation signal.
close(ops)
<-ctx.Done()
return nil, ctx.Err()
}
program := func(_ plugin.RunInfo, resmon *deploytest.ResourceMonitor) error {
return nil
}
ctx := makeTestContext(t, cancelCtx)
defer ctx.Close()
info, err := newDeploymentContext(makeUpdateInfo(), "test", nil)
assert.NoError(t, err)
defer info.Close()
host := makePluginHost(t, program)
defer host.Close()
opts := &deploymentOptions{
ctrl-c should cause Pulumi to call Cancel operation on providers (#14057) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description Fixes #14054 This PR fixes a problem that the engine cannot forward a cancellation signal to the provider, because the plugin context is already closed. An [earlier commit](https://github.com/pulumi/pulumi/pull/9793/commits/a9ae602867834efc9821abd866ef388c1b051114) made the plugin context be closed too eagerly, with the intent of cancelling plugin installation. This PR attempts to decouple the cancellation of plugin installation from the lifecycle of the plugin context, so that plugin installation may be cancelled during the cancelation phase as opposed to the termination phase. Then, it closes the plugin context in termination phase. There's an existing test case in the engine lifecycle tests called `TestProviderCancellation`, but it didn't catch the problem because it uses a fake plugin host that behaves differently after being closed. The issue was fixed in https://github.com/pulumi/pulumi/pull/14063 and the test was temporarily disabled. This PR re-enables the test case. A new test case `TestSourceFuncCancellation` is added to test cancellation of the source func (where plugin installation happens, see [update.go](https://github.com/pulumi/pulumi/pull/14057/files#diff-7d2ca3e83a05073b332435271496050e28466b4f7af8c0c91bbc77947a75a3a2R378)), as this was the original motivation of https://github.com/pulumi/pulumi/pull/9793/commits/a9ae602867834efc9821abd866ef388c1b051114. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] ~Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version~ <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-09-29 22:12:35 +00:00
UpdateOptions: UpdateOptions{
Host: host,
},
SourceFunc: sourceF,
Events: ctx.makeEventEmitter(t),
Diag: diagtest.LogSink(t),
StatusDiag: diagtest.LogSink(t),
Clean up deployment options (#16357) # Description There are a number of parts of the deployment process that require context about and configuration for the operation being executed. For instance: * Source evaluation -- evaluating programs in order to emit resource registrations * Step generation -- processing resource registrations in order to generate steps (create this, update that, delete the other, etc.) * Step execution -- executing steps in order to action a deployment. Presently, these pieces all take some form of `Options` struct or pass explicit arguments. This is problematic for a couple of reasons: * It could be possible for different parts of the codebase to end up operating in different contexts/with different configurations, whether due to different values being passed explicitly or due to missed copying/instantiation. * Some parts need less context/configuration than others, but still accept full `Options`, making it hard to discern what information is actually necessary in any given part of the process. This commit attempts to clean things up by moving deployment options directly into the `Deployment` itself. Since step generation and execution already refer to a `Deployment`, they get a consistent view of the options for free. For source evaluation, we introduce an `EvalSourceOptions` struct for configuring just the options necessary there. At the top level, the engine configures a single set of options to flow through the deployment steps later on. As part of this work, a few other things have been changed: * Preview/dry-run parameters have been incorporated into options. This lets up lop off another argument and mitigate a bit of "boolean blindness". We don't appear to flip this flag within a deployment process (indeed, all options seem to be immutable) and so having it as a separate flag doesn't seem to buy us anything. * Several methods representing parts of the deployment process have lost arguments in favour of state that is already being carried on (or can be carried on) their receiver. For instance, `deployment.run` no longer takes actions or preview configuration. While doing so means that a `deployment` could be run multiple times with different actions/preview arguments, we don't currently exploit this fact anywhere, so moving this state to the point of construction both simplifies things considerably and reduces the possibility for error (e.g. passing different values of `preview` when instantiating a `deployment` and subsequently calling `run`). * Event handlers have been split out of the options object and attached to `Deployment` separately. This means we can talk about options at a higher level without having to `nil` out/worry about this field and mutate it correctly later on. * Options are no longer mutated during deployment. Presently there appears to be only one case of this -- when handling `ContinueOnError` in the presence of `IgnoreChanges` (e.g. when performing a refresh). This case has been refactored so that the mutation is no longer necessary. # Notes * This change is in preparation for #16146, where we'd like to add an environment variable to control behaviour and having a single unified `Options` struct would make it easier to pass this configuration down with introducing (more) global state into deployments. Indeed, this change should make it easier to factor global state into `Options` so that it can be controlled and tested more easily/is less susceptible to bugs, race conditions, etc. * I've tweaked/extended some comments while I'm here and have learned things the hard way (e.g. `Refresh` vs `isRefresh`). Feedback welcome on this if we'd rather not conflate. * This change does mean that if in future we wanted e.g. to be able to run a `Deployment` in multiple different ways with multiple sets of actions, we'd have to refactor. Pushing state to the point of object construction reduces the flexibility of the code. However, since we are not presently using that flexibility (nor is there an obvious [to my mind] use case in the near future), this seems like a good trade-off to guard against bugs/make it simpler to move that state around. * I've left some other review comments in the code around questions/changes that might be a bad idea; happy to receive feedback on it all though!
2024-06-11 13:37:57 +00:00
DryRun: false,
ctrl-c should cause Pulumi to call Cancel operation on providers (#14057) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description Fixes #14054 This PR fixes a problem that the engine cannot forward a cancellation signal to the provider, because the plugin context is already closed. An [earlier commit](https://github.com/pulumi/pulumi/pull/9793/commits/a9ae602867834efc9821abd866ef388c1b051114) made the plugin context be closed too eagerly, with the intent of cancelling plugin installation. This PR attempts to decouple the cancellation of plugin installation from the lifecycle of the plugin context, so that plugin installation may be cancelled during the cancelation phase as opposed to the termination phase. Then, it closes the plugin context in termination phase. There's an existing test case in the engine lifecycle tests called `TestProviderCancellation`, but it didn't catch the problem because it uses a fake plugin host that behaves differently after being closed. The issue was fixed in https://github.com/pulumi/pulumi/pull/14063 and the test was temporarily disabled. This PR re-enables the test case. A new test case `TestSourceFuncCancellation` is added to test cancellation of the source func (where plugin installation happens, see [update.go](https://github.com/pulumi/pulumi/pull/14057/files#diff-7d2ca3e83a05073b332435271496050e28466b4f7af8c0c91bbc77947a75a3a2R378)), as this was the original motivation of https://github.com/pulumi/pulumi/pull/9793/commits/a9ae602867834efc9821abd866ef388c1b051114. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] ~Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version~ <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-09-29 22:12:35 +00:00
}
Clean up deployment options (#16357) # Description There are a number of parts of the deployment process that require context about and configuration for the operation being executed. For instance: * Source evaluation -- evaluating programs in order to emit resource registrations * Step generation -- processing resource registrations in order to generate steps (create this, update that, delete the other, etc.) * Step execution -- executing steps in order to action a deployment. Presently, these pieces all take some form of `Options` struct or pass explicit arguments. This is problematic for a couple of reasons: * It could be possible for different parts of the codebase to end up operating in different contexts/with different configurations, whether due to different values being passed explicitly or due to missed copying/instantiation. * Some parts need less context/configuration than others, but still accept full `Options`, making it hard to discern what information is actually necessary in any given part of the process. This commit attempts to clean things up by moving deployment options directly into the `Deployment` itself. Since step generation and execution already refer to a `Deployment`, they get a consistent view of the options for free. For source evaluation, we introduce an `EvalSourceOptions` struct for configuring just the options necessary there. At the top level, the engine configures a single set of options to flow through the deployment steps later on. As part of this work, a few other things have been changed: * Preview/dry-run parameters have been incorporated into options. This lets up lop off another argument and mitigate a bit of "boolean blindness". We don't appear to flip this flag within a deployment process (indeed, all options seem to be immutable) and so having it as a separate flag doesn't seem to buy us anything. * Several methods representing parts of the deployment process have lost arguments in favour of state that is already being carried on (or can be carried on) their receiver. For instance, `deployment.run` no longer takes actions or preview configuration. While doing so means that a `deployment` could be run multiple times with different actions/preview arguments, we don't currently exploit this fact anywhere, so moving this state to the point of construction both simplifies things considerably and reduces the possibility for error (e.g. passing different values of `preview` when instantiating a `deployment` and subsequently calling `run`). * Event handlers have been split out of the options object and attached to `Deployment` separately. This means we can talk about options at a higher level without having to `nil` out/worry about this field and mutate it correctly later on. * Options are no longer mutated during deployment. Presently there appears to be only one case of this -- when handling `ContinueOnError` in the presence of `IgnoreChanges` (e.g. when performing a refresh). This case has been refactored so that the mutation is no longer necessary. # Notes * This change is in preparation for #16146, where we'd like to add an environment variable to control behaviour and having a single unified `Options` struct would make it easier to pass this configuration down with introducing (more) global state into deployments. Indeed, this change should make it easier to factor global state into `Options` so that it can be controlled and tested more easily/is less susceptible to bugs, race conditions, etc. * I've tweaked/extended some comments while I'm here and have learned things the hard way (e.g. `Refresh` vs `isRefresh`). Feedback welcome on this if we'd rather not conflate. * This change does mean that if in future we wanted e.g. to be able to run a `Deployment` in multiple different ways with multiple sets of actions, we'd have to refactor. Pushing state to the point of object construction reduces the flexibility of the code. However, since we are not presently using that flexibility (nor is there an obvious [to my mind] use case in the near future), this seems like a good trade-off to guard against bugs/make it simpler to move that state around. * I've left some other review comments in the code around questions/changes that might be a bad idea; happy to receive feedback on it all though!
2024-06-11 13:37:57 +00:00
_, err = newDeployment(&ctx.Context, info, nil, opts)
ctrl-c should cause Pulumi to call Cancel operation on providers (#14057) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description Fixes #14054 This PR fixes a problem that the engine cannot forward a cancellation signal to the provider, because the plugin context is already closed. An [earlier commit](https://github.com/pulumi/pulumi/pull/9793/commits/a9ae602867834efc9821abd866ef388c1b051114) made the plugin context be closed too eagerly, with the intent of cancelling plugin installation. This PR attempts to decouple the cancellation of plugin installation from the lifecycle of the plugin context, so that plugin installation may be cancelled during the cancelation phase as opposed to the termination phase. Then, it closes the plugin context in termination phase. There's an existing test case in the engine lifecycle tests called `TestProviderCancellation`, but it didn't catch the problem because it uses a fake plugin host that behaves differently after being closed. The issue was fixed in https://github.com/pulumi/pulumi/pull/14063 and the test was temporarily disabled. This PR re-enables the test case. A new test case `TestSourceFuncCancellation` is added to test cancellation of the source func (where plugin installation happens, see [update.go](https://github.com/pulumi/pulumi/pull/14057/files#diff-7d2ca3e83a05073b332435271496050e28466b4f7af8c0c91bbc77947a75a3a2R378)), as this was the original motivation of https://github.com/pulumi/pulumi/pull/9793/commits/a9ae602867834efc9821abd866ef388c1b051114. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] ~Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version~ <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-09-29 22:12:35 +00:00
if !assert.ErrorIs(t, err, context.Canceled) {
t.FailNow()
}
}