2018-05-22 21:43:36 +02:00
|
|
|
// Copyright 2016-2018, 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.
|
2017-03-15 23:40:06 +01:00
|
|
|
|
2017-09-22 04:18:21 +02:00
|
|
|
package cmd
|
2017-03-15 23:40:06 +01:00
|
|
|
|
|
|
|
import (
|
2018-05-05 20:57:09 +02:00
|
|
|
"github.com/pkg/errors"
|
2017-03-15 23:40:06 +01:00
|
|
|
"github.com/spf13/cobra"
|
Make major commands more pleasant
This change eliminates the need to constantly type in the environment
name when performing major commands like configuration, planning, and
deployment. It's probably due to my age, however, I keep fat-fingering
simple commands in front of investors and I am embarrassed!
In the new model, there is a notion of a "current environment", and
I have modeled it kinda sorta just like Git's notion of "current branch."
By default, the current environment is set when you `init` something.
Otherwise, there is the `coco env select <env>` command to change it.
(Running this command w/out a new <env> will show you the current one.)
The major commands `config`, `plan`, `deploy`, and `destroy` will prefer
to use the current environment, unless it is overridden by using the
--env flag. All of the `coco env <cmd> <env>` commands still require the
explicit passing of an environment which seems reasonable since they are,
after all, about manipulating environments.
As part of this, I've overhauled the aging workspace settings cruft,
which had fallen into disrepair since the initial prototype.
2017-03-22 03:23:32 +01:00
|
|
|
|
2018-05-05 20:57:09 +02:00
|
|
|
"github.com/pulumi/pulumi/pkg/backend"
|
|
|
|
"github.com/pulumi/pulumi/pkg/engine"
|
2017-09-22 04:18:21 +02:00
|
|
|
"github.com/pulumi/pulumi/pkg/util/cmdutil"
|
2017-03-15 23:40:06 +01:00
|
|
|
)
|
|
|
|
|
2017-09-23 00:15:42 +02:00
|
|
|
func newPreviewCmd() *cobra.Command {
|
2017-07-14 02:09:46 +02:00
|
|
|
var debug bool
|
2018-05-16 02:33:16 +02:00
|
|
|
var expectNop bool
|
2018-05-05 20:57:09 +02:00
|
|
|
var message string
|
2017-10-16 21:04:35 +02:00
|
|
|
var stack string
|
2018-01-18 20:10:15 +01:00
|
|
|
|
|
|
|
// Flags for engine.UpdateOptions.
|
|
|
|
var analyzers []string
|
|
|
|
var color colorFlag
|
Implement a refresh command
This change implements a `pulumi refresh` command. It operates a bit
like `pulumi update`, and friends, in that it supports `--preview` and
`--diff`, along with the usual flags, and will update your checkpoint.
It works through substitution of the deploy.Source abstraction, which
generates a sequence of resource registration events. This new
deploy.RefreshSource takes in a prior checkpoint and will walk it,
refreshing the state via the associated resource providers by invoking
Read for each resource encountered, and merging the resulting state with
the prior checkpoint, to yield a new resource.Goal state. This state is
then fed through the engine in the usual ways with a few minor caveats:
namely, although the engine must generate steps for the logical
operations (permitting us to get nice summaries, progress, and diffs),
it mustn't actually carry them out because the state being imported
already reflects reality (a deleted resource has *already* been deleted,
so of course the engine need not perform the deletion). The diffing
logic also needs to know how to treat the case of refresh slightly
differently, because we are going to be diffing outputs and not inputs.
Note that support for managed stacks is not yet complete, since that
requires updates to the service to support a refresh endpoint. That
will be coming soon ...
2018-04-10 20:22:39 +02:00
|
|
|
var diffDisplay bool
|
2018-05-05 20:57:09 +02:00
|
|
|
var nonInteractive bool
|
2017-09-17 17:10:46 +02:00
|
|
|
var parallel int
|
2017-03-15 23:40:06 +01:00
|
|
|
var showConfig bool
|
2017-08-06 19:05:51 +02:00
|
|
|
var showReplacementSteps bool
|
2017-06-11 17:09:20 +02:00
|
|
|
var showSames bool
|
2018-01-18 20:10:15 +01:00
|
|
|
|
2017-03-15 23:40:06 +01:00
|
|
|
var cmd = &cobra.Command{
|
2017-10-21 02:36:47 +02:00
|
|
|
Use: "preview",
|
2017-11-13 23:59:11 +01:00
|
|
|
Aliases: []string{"pre"},
|
|
|
|
SuggestFor: []string{"build", "plan"},
|
2018-05-05 20:57:09 +02:00
|
|
|
Short: "Show a preview of updates to a stack's resources",
|
|
|
|
Long: "Show a preview of updates a stack's resources.\n" +
|
|
|
|
"\n" +
|
|
|
|
"This command displays a preview of the updates to an existing stack whose state is\n" +
|
|
|
|
"represented by an existing snapshot file. The new desired state is computed by running\n" +
|
|
|
|
"a Pulumi program, and extracting all resource allocations from its resulting object graph.\n" +
|
|
|
|
"These allocations are then compared against the existing state to determine what\n" +
|
|
|
|
"operations must take place to achieve the desired state. No changes to the stack will\n" +
|
|
|
|
"actually take place.\n" +
|
|
|
|
"\n" +
|
|
|
|
"The program to run is loaded from the project in the current directory. Use the `-C` or\n" +
|
|
|
|
"`--cwd` flag to use a different directory.",
|
|
|
|
Args: cmdutil.NoArgs,
|
2017-04-12 20:12:25 +02:00
|
|
|
Run: cmdutil.RunFunc(func(cmd *cobra.Command, args []string) error {
|
2018-05-05 20:57:09 +02:00
|
|
|
s, err := requireStack(stack, true)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
proj, root, err := readProject()
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
m, err := getUpdateMetadata("", root)
|
|
|
|
if err != nil {
|
|
|
|
return errors.Wrap(err, "gathering environment metadata")
|
|
|
|
}
|
|
|
|
|
|
|
|
opts := backend.UpdateOptions{
|
|
|
|
Engine: engine.UpdateOptions{
|
|
|
|
Analyzers: analyzers,
|
|
|
|
Parallel: parallel,
|
|
|
|
Debug: debug,
|
|
|
|
},
|
|
|
|
Display: backend.DisplayOptions{
|
|
|
|
Color: color.Colorization(),
|
|
|
|
ShowConfig: showConfig,
|
|
|
|
ShowReplacementSteps: showReplacementSteps,
|
|
|
|
ShowSameResources: showSames,
|
|
|
|
IsInteractive: isInteractive(nonInteractive),
|
|
|
|
DiffDisplay: diffDisplay,
|
|
|
|
Debug: debug,
|
|
|
|
},
|
|
|
|
}
|
2018-05-16 02:33:16 +02:00
|
|
|
changes, err := s.Preview(commandContext(), proj, root, m, opts, cancellationScopes)
|
|
|
|
switch {
|
|
|
|
case err != nil:
|
|
|
|
return err
|
2018-05-16 19:22:09 +02:00
|
|
|
case expectNop && changes != nil && changes.HasChanges():
|
2018-05-16 02:33:16 +02:00
|
|
|
return errors.New("error: no changes were expected but changes were proposed")
|
|
|
|
default:
|
|
|
|
return nil
|
|
|
|
}
|
2017-03-15 23:40:06 +01:00
|
|
|
}),
|
|
|
|
}
|
|
|
|
|
2017-07-14 02:09:46 +02:00
|
|
|
cmd.PersistentFlags().BoolVarP(
|
|
|
|
&debug, "debug", "d", false,
|
|
|
|
"Print detailed debugging output during resource operations")
|
2018-05-16 02:33:16 +02:00
|
|
|
cmd.PersistentFlags().BoolVar(
|
|
|
|
&expectNop, "expect-no-changes", false,
|
|
|
|
"Return an error if any changes are proposed by this preview")
|
Make major commands more pleasant
This change eliminates the need to constantly type in the environment
name when performing major commands like configuration, planning, and
deployment. It's probably due to my age, however, I keep fat-fingering
simple commands in front of investors and I am embarrassed!
In the new model, there is a notion of a "current environment", and
I have modeled it kinda sorta just like Git's notion of "current branch."
By default, the current environment is set when you `init` something.
Otherwise, there is the `coco env select <env>` command to change it.
(Running this command w/out a new <env> will show you the current one.)
The major commands `config`, `plan`, `deploy`, and `destroy` will prefer
to use the current environment, unless it is overridden by using the
--env flag. All of the `coco env <cmd> <env>` commands still require the
explicit passing of an environment which seems reasonable since they are,
after all, about manipulating environments.
As part of this, I've overhauled the aging workspace settings cruft,
which had fallen into disrepair since the initial prototype.
2017-03-22 03:23:32 +01:00
|
|
|
cmd.PersistentFlags().StringVarP(
|
2017-10-16 21:04:35 +02:00
|
|
|
&stack, "stack", "s", "",
|
Implement basic plugin management
This change implements basic plugin management, but we do not yet
actually use the plugins for anything (that comes next).
Plugins are stored in `~/.pulumi/plugins`, and are expected to be
in the format `pulumi-<KIND>-<NAME>-v<VERSION>[.exe]`. The KIND is
one of `analyzer`, `language`, or `resource`, the NAME is a hyphen-
delimited name (e.g., `aws` or `foo-bar`), and VERSION is the
plugin's semantic version (e.g., `0.9.11`, `1.3.7-beta.a736cf`, etc).
This commit includes four new CLI commands:
* `pulumi plugin` is the top-level plugin command. It does nothing
but show the help text for associated child commands.
* `pulumi plugin install` can be used to install plugins manually.
If run with no additional arguments, it will compute the set of
plugins used by the current project, and download them all. It
may be run to explicitly download a single plugin, however, by
invoking it as `pulumi plugin install KIND NAME VERSION`. For
example, `pulumi plugin install resource aws v0.9.11`. By default,
this command uses the cloud backend in the usual way to perform the
download, although a separate URL may be given with --cloud-url,
just like all other commands that interact with our backend service.
* `pulumi plugin ls` lists all plugins currently installed in the
plugin cache. It displays some useful statistics, like the size
of the plugin, when it was installed, when it was last used, and
so on. It sorts the display alphabetically by plugin name, and
for plugins with multiple versions, it shows the newest at the top.
The command also summarizes how much disk space is currently being
consumed by the plugin cache. There are no filtering capabilities yet.
* `pulumi plugin prune` will delete plugins from the cache. By
default, when run with no arguments, it will delete everything.
It may be run with additional arguments, KIND, NAME, and VERSION,
each one getting more specific about what it will delete. For
instance, `pulumi plugin prune resource aws` will delete all AWS
plugin versions, while `pulumi plugin prune resource aws <0.9`
will delete all AWS plugins before version 0.9. Unless --yes is
passed, the command will confirm the deletion with a count of how
many plugins will be affected by the command.
We do not yet actually download plugins on demand yet. That will
come in a subsequent change.
2018-02-04 19:51:29 +01:00
|
|
|
"Choose a stack other than the currently selected one")
|
2018-01-18 20:10:15 +01:00
|
|
|
|
2018-05-05 20:57:09 +02:00
|
|
|
cmd.PersistentFlags().StringVarP(
|
|
|
|
&message, "message", "m", "",
|
|
|
|
"Optional message to associate with the preview operation")
|
|
|
|
|
2018-01-18 20:10:15 +01:00
|
|
|
// Flags for engine.UpdateOptions.
|
|
|
|
cmd.PersistentFlags().StringSliceVar(
|
|
|
|
&analyzers, "analyzer", []string{},
|
|
|
|
"Run one or more analyzers as part of this update")
|
Implement a refresh command
This change implements a `pulumi refresh` command. It operates a bit
like `pulumi update`, and friends, in that it supports `--preview` and
`--diff`, along with the usual flags, and will update your checkpoint.
It works through substitution of the deploy.Source abstraction, which
generates a sequence of resource registration events. This new
deploy.RefreshSource takes in a prior checkpoint and will walk it,
refreshing the state via the associated resource providers by invoking
Read for each resource encountered, and merging the resulting state with
the prior checkpoint, to yield a new resource.Goal state. This state is
then fed through the engine in the usual ways with a few minor caveats:
namely, although the engine must generate steps for the logical
operations (permitting us to get nice summaries, progress, and diffs),
it mustn't actually carry them out because the state being imported
already reflects reality (a deleted resource has *already* been deleted,
so of course the engine need not perform the deletion). The diffing
logic also needs to know how to treat the case of refresh slightly
differently, because we are going to be diffing outputs and not inputs.
Note that support for managed stacks is not yet complete, since that
requires updates to the service to support a refresh endpoint. That
will be coming soon ...
2018-04-10 20:22:39 +02:00
|
|
|
cmd.PersistentFlags().VarP(
|
|
|
|
&color, "color", "c", "Colorize output. Choices are: always, never, raw, auto")
|
|
|
|
cmd.PersistentFlags().BoolVar(
|
|
|
|
&diffDisplay, "diff", false,
|
|
|
|
"Display operation as a rich diff showing the overall change")
|
2018-05-05 20:57:09 +02:00
|
|
|
cmd.PersistentFlags().BoolVar(
|
|
|
|
&nonInteractive, "non-interactive", false, "Disable interactive mode")
|
2017-09-17 17:10:46 +02:00
|
|
|
cmd.PersistentFlags().IntVarP(
|
|
|
|
¶llel, "parallel", "p", 0,
|
|
|
|
"Allow P resource operations to run in parallel at once (<=1 for no parallelism)")
|
2017-03-15 23:40:06 +01:00
|
|
|
cmd.PersistentFlags().BoolVar(
|
|
|
|
&showConfig, "show-config", false,
|
|
|
|
"Show configuration keys and variables")
|
Implement `get` functions on all resources
This change implements the `get` function for resources. Per pulumi/lumi#83,
this allows Lumi scripts to actually read from the target environment.
For example, we can now look up a SecurityGroup from its ARN:
let group = aws.ec2.SecurityGroup.get(
"arn:aws:ec2:us-west-2:153052954103:security-group:sg-02150d79");
The returned object is a fully functional resource object. So, we can then
link it up with an EC2 instance, for example, in the usual ways:
let instance = new aws.ec2.Instance(..., {
securityGroups: [ group ],
});
This didn't require any changes to the RPC or provider model, since we
already implement the Get function.
There are a few loose ends; two are short term:
1) URNs are not rehydrated.
2) Query is not yet implemented.
One is mid-term:
3) We probably want a URN-based lookup function. But we will likely
wait until we tackle pulumi/lumi#109 before adding this.
And one is long term (and subtle):
4) These amount to I/O and are not repeatable! A change in the target
environment may cause a script to generate a different plan
intermittently. Most likely we want to apply a different kind of
deployment "policy" for such scripts. These are inching towards the
scripting model of pulumi/lumi#121, which is an entirely different
beast than the repeatable immutable infrastructure deployments.
Finally, it is worth noting that with this, we have some of the fundamental
underpinnings required to finally tackle "inference" (pulumi/lumi#142).
2017-06-20 02:24:00 +02:00
|
|
|
cmd.PersistentFlags().BoolVar(
|
2017-08-06 19:05:51 +02:00
|
|
|
&showReplacementSteps, "show-replacement-steps", false,
|
|
|
|
"Show detailed resource replacement creates and deletes instead of a single step")
|
2017-03-15 23:40:06 +01:00
|
|
|
cmd.PersistentFlags().BoolVar(
|
2017-06-11 17:09:20 +02:00
|
|
|
&showSames, "show-sames", false,
|
2017-03-15 23:40:06 +01:00
|
|
|
"Show resources that needn't be updated because they haven't changed, alongside those that do")
|
|
|
|
|
|
|
|
return cmd
|
|
|
|
}
|