maxmustermann/pulumi
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
pulumi/pkg/engine/destroy.go

37 lines
791 B
Go
Raw Normal View History

Wire up Lumi to the new runtime strategy :fire: :fire: :fire: :boat: :fire: :fire: :fire: Getting closer on #311.
2017-08-30 03:24:12 +02:00
// Copyright 2017, Pulumi Corporation. All rights reserved.
Move a bunch of code around Move most of the guts of `lumi` into the newly created `engine` package.
2017-08-23 01:56:15 +02:00
package engine
Require environment name on deployment APIs Deployments always need to be done in the context of some environment, so let's make the argument explicit instead of it coming in the property bag
2017-10-02 20:14:27 +02:00
import (
Have engine emit "events" instead of writing to streams Previously, the engine would write to io.Writer's to display output. When hosted in `pulumi` these writers were tied to os.Stdout and os.Stderr, but other applications hosting the engine could send them other places (e.g. a log to be sent to an another application later). While much better than just using the ambient streams, this was still not the best. It would be ideal if the engine could just emit strongly typed events and whatever is hosting the engine could care about displaying them. As a first step down that road, we move to a model where operations on the engine now take a `chan engine.Event` and during the course of the operation, events are written to this channel. It is the responsibility of the caller of the method to read from the channel until it is closed (singifying that the operation is complete). The events we do emit are still intermingle presentation with data, which is unfortunate, but can be improved over time. Most of the events today are just colorized in the client and printed to stdout or stderr without much thought.
2017-10-05 23:08:46 +02:00
"github.com/pulumi/pulumi/pkg/diag"
Require environment name on deployment APIs Deployments always need to be done in the context of some environment, so let's make the argument explicit instead of it coming in the property bag
2017-10-02 20:14:27 +02:00
"github.com/pulumi/pulumi/pkg/tokens"
Have the CLI keep track of the current environment Previously, the engine was concered with maintaing information about the currently active environment. Now, the CLI is in charge of this. As part of this change, the engine can now assume that every environment has a non empty name (and I've added asserts on the entrypoints of the engine API to ensure that any consumer of the engine passes a non empty environment name)
2017-10-03 01:37:12 +02:00
"github.com/pulumi/pulumi/pkg/util/contract"
Require environment name on deployment APIs Deployments always need to be done in the context of some environment, so let's make the argument explicit instead of it coming in the property bag
2017-10-02 20:14:27 +02:00
)
Move a bunch of code around Move most of the guts of `lumi` into the newly created `engine` package.
2017-08-23 01:56:15 +02:00
Clean up Destroy API boundary
2017-08-24 01:50:20 +02:00
type DestroyOptions struct {
Require environment name on deployment APIs Deployments always need to be done in the context of some environment, so let's make the argument explicit instead of it coming in the property bag
2017-10-02 20:14:27 +02:00
Package string
DryRun bool
Parallel int
Summary bool
Clean up Destroy API boundary
2017-08-24 01:50:20 +02:00
}
Use `Stack` over `Environment` to describe a deployment target Previously we used the word "Environment" as the term for a deployment target, but since then we've started to use the term Stack. Adopt this across the CLI. From a user's point of view, there are a few changes: 1. The `env` verb has been renamed to `stack` 2. The `-e` and `--env` options to commands which operate on an environment now take `-s` or `--stack` instead. 3. Becase of (2), the commands that used `-s` to display a summary now only support passing the full option name (`--summary`). On the local file system, we still store checkpoint data in the `env` sub-folder under `.pulumi` (so we can reuse existing checkpoint files that were written to the old folder)
2017-10-16 21:04:35 +02:00
func (eng *Engine) Destroy(stack tokens.QName, events chan<- Event, opts DestroyOptions) error {
contract.Require(stack != tokens.QName(""), "stack")
Have the CLI keep track of the current environment Previously, the engine was concered with maintaing information about the currently active environment. Now, the CLI is in charge of this. As part of this change, the engine can now assume that every environment has a non empty name (and I've added asserts on the entrypoints of the engine API to ensure that any consumer of the engine passes a non empty environment name)
2017-10-03 01:37:12 +02:00
Use `Stack` over `Environment` to describe a deployment target Previously we used the word "Environment" as the term for a deployment target, but since then we've started to use the term Stack. Adopt this across the CLI. From a user's point of view, there are a few changes: 1. The `env` verb has been renamed to `stack` 2. The `-e` and `--env` options to commands which operate on an environment now take `-s` or `--stack` instead. 3. Becase of (2), the commands that used `-s` to display a summary now only support passing the full option name (`--summary`). On the local file system, we still store checkpoint data in the `env` sub-folder under `.pulumi` (so we can reuse existing checkpoint files that were written to the old folder)
2017-10-16 21:04:35 +02:00
info, err := eng.planContextFromStack(stack, opts.Package)
Move a bunch of code around Move most of the guts of `lumi` into the newly created `engine` package.
2017-08-23 01:56:15 +02:00
if err != nil {
return err
}
Alow multiple instances of engine.Engine This refactors the engine so all of the APIs on it are instance methods on the type instead of raw methods that float around and use data from a global engine. A mechcanical change as we remove the global `E` and then make anything that interacted with that in pkg/engine to be an instance method and the dealing with the fallout.
2017-08-23 19:58:35 +02:00
return eng.deployLatest(info, deployOptions{
Switch to a --parallel=P flag This change flips the polarity on parallelism: rather than having a --serialize flag, we will have a --parallel=P flag, and by default we will shut off parallelism. We aren't benefiting from it at the moment (until we implement pulumi/pulumi-fabric#106), and there are more hidden dependencies in places like AWS Lambdas and Permissions than I had realized. We may revisit the default, but this allows us to bite off the messiness of dependsOn only when we benefit from it. And in any case, the --parallel=P capability will be useful.
2017-09-17 17:10:46 +02:00
Destroy: true,
DryRun: opts.DryRun,
Parallel: opts.Parallel,
Summary: opts.Summary,
Have engine emit "events" instead of writing to streams Previously, the engine would write to io.Writer's to display output. When hosted in `pulumi` these writers were tied to os.Stdout and os.Stderr, but other applications hosting the engine could send them other places (e.g. a log to be sent to an another application later). While much better than just using the ambient streams, this was still not the best. It would be ideal if the engine could just emit strongly typed events and whatever is hosting the engine could care about displaying them. As a first step down that road, we move to a model where operations on the engine now take a `chan engine.Event` and during the course of the operation, events are written to this channel. It is the responsibility of the caller of the method to read from the channel until it is closed (singifying that the operation is complete). The events we do emit are still intermingle presentation with data, which is unfortunate, but can be improved over time. Most of the events today are just colorized in the client and printed to stdout or stderr without much thought.
2017-10-05 23:08:46 +02:00
Events: events,
Fix diag channel errors The event diagnostic goroutines could error out sometimes during early program exits, due to a race between the goroutine writing to the channel and the early exiting goroutine which closed the channel. This change stops closing the channels entirely on the abrupt exit paths, since it's not necessary and we want to exit immediately.
2017-10-23 00:22:15 +02:00
Diag: newEventSink(events, diag.FormatOptions{
Colors: true,
}),
Move a bunch of code around Move most of the guts of `lumi` into the newly created `engine` package.
2017-08-23 01:56:15 +02:00
})
}
Reference in a new issue Copy permalink