2017-05-18 23:51:52 +02:00
|
|
|
// Licensed to Pulumi Corporation ("Pulumi") under one or more
|
|
|
|
// contributor license agreements. See the NOTICE file distributed with
|
|
|
|
// this work for additional information regarding copyright ownership.
|
|
|
|
// Pulumi licenses this file to You 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-04-12 19:38:12 +02:00
|
|
|
package main
|
2017-03-15 23:40:06 +01:00
|
|
|
|
|
|
|
import (
|
2017-05-26 01:19:13 +02:00
|
|
|
"bytes"
|
|
|
|
"fmt"
|
|
|
|
"sort"
|
|
|
|
"strconv"
|
|
|
|
|
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
|
|
|
|
2017-05-26 01:19:13 +02:00
|
|
|
"github.com/pulumi/lumi/pkg/diag"
|
|
|
|
"github.com/pulumi/lumi/pkg/diag/colors"
|
|
|
|
"github.com/pulumi/lumi/pkg/resource"
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
"github.com/pulumi/lumi/pkg/resource/deploy"
|
|
|
|
"github.com/pulumi/lumi/pkg/resource/plugin"
|
2017-05-18 20:38:28 +02:00
|
|
|
"github.com/pulumi/lumi/pkg/tokens"
|
|
|
|
"github.com/pulumi/lumi/pkg/util/cmdutil"
|
2017-05-26 01:19:13 +02:00
|
|
|
"github.com/pulumi/lumi/pkg/util/contract"
|
2017-03-15 23:40:06 +01:00
|
|
|
)
|
|
|
|
|
|
|
|
func newPlanCmd() *cobra.Command {
|
|
|
|
var analyzers []string
|
2017-03-23 16:10:33 +01:00
|
|
|
var dotOutput bool
|
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
|
|
|
var env string
|
2017-03-15 23:40:06 +01:00
|
|
|
var showConfig bool
|
|
|
|
var showReplaceSteps bool
|
2017-06-11 17:09:20 +02:00
|
|
|
var showSames bool
|
2017-03-15 23:40:06 +01:00
|
|
|
var summary bool
|
|
|
|
var cmd = &cobra.Command{
|
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
|
|
|
Use: "plan [<package>] [-- [<args>]]",
|
2017-03-15 23:40:06 +01:00
|
|
|
Aliases: []string{"dryrun"},
|
|
|
|
Short: "Show a plan to update, create, and delete an environment's resources",
|
|
|
|
Long: "Show a plan to update, create, and delete an environment's resources\n" +
|
|
|
|
"\n" +
|
|
|
|
"This command displays a plan to update an existing environment whose state is represented by\n" +
|
|
|
|
"an existing snapshot file. The new desired state is computed by compiling and evaluating an\n" +
|
|
|
|
"executable package, and extracting all resource allocations from its resulting object graph.\n" +
|
|
|
|
"This graph is compared against the existing state to determine what operations must take\n" +
|
|
|
|
"place to achieve the desired state. No changes to the environment will actually take place.\n" +
|
|
|
|
"\n" +
|
|
|
|
"By default, the package to execute is loaded from the current directory. Optionally, an\n" +
|
|
|
|
"explicit path can be provided using the [package] argument.",
|
2017-04-12 20:12:25 +02:00
|
|
|
Run: cmdutil.RunFunc(func(cmd *cobra.Command, args []string) error {
|
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
|
|
|
info, err := initEnvCmdName(tokens.QName(env), args)
|
2017-03-15 23:40:06 +01:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2017-06-11 17:58:21 +02:00
|
|
|
contract.Assertf(!dotOutput, "TODO[pulumi/lumi#235]: DOT files not yet supported")
|
2017-06-12 16:16:08 +02:00
|
|
|
opts := deployOptions{
|
2017-03-15 23:40:06 +01:00
|
|
|
Delete: false,
|
|
|
|
DryRun: true,
|
|
|
|
Analyzers: analyzers,
|
|
|
|
ShowConfig: showConfig,
|
|
|
|
ShowReplaceSteps: showReplaceSteps,
|
2017-06-11 17:09:20 +02:00
|
|
|
ShowSames: showSames,
|
2017-03-15 23:40:06 +01:00
|
|
|
Summary: summary,
|
2017-03-23 16:10:33 +01:00
|
|
|
DOT: dotOutput,
|
2017-06-12 16:16:08 +02:00
|
|
|
}
|
|
|
|
if result := plan(cmd, info, opts); result != nil {
|
2017-06-15 23:41:55 +02:00
|
|
|
if err := printPlan(result, opts); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2017-06-12 16:16:08 +02:00
|
|
|
}
|
2017-03-15 23:40:06 +01:00
|
|
|
return nil
|
|
|
|
}),
|
|
|
|
}
|
|
|
|
|
|
|
|
cmd.PersistentFlags().StringSliceVar(
|
|
|
|
&analyzers, "analyzer", []string{},
|
|
|
|
"Run one or more analyzers as part of this deployment")
|
2017-03-23 16:10:33 +01:00
|
|
|
cmd.PersistentFlags().BoolVar(
|
|
|
|
&dotOutput, "dot", false,
|
|
|
|
"Output the plan as a DOT digraph (graph description language)")
|
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(
|
|
|
|
&env, "env", "e", "",
|
|
|
|
"Choose an environment other than the currently selected one")
|
2017-03-15 23:40:06 +01:00
|
|
|
cmd.PersistentFlags().BoolVar(
|
|
|
|
&showConfig, "show-config", false,
|
|
|
|
"Show configuration keys and variables")
|
|
|
|
cmd.PersistentFlags().BoolVar(
|
|
|
|
&showReplaceSteps, "show-replace-steps", false,
|
|
|
|
"Show detailed resource replacement creates and deletes; normally shows as a single step")
|
|
|
|
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")
|
|
|
|
cmd.PersistentFlags().BoolVarP(
|
|
|
|
&summary, "summary", "s", false,
|
|
|
|
"Only display summarization of resources and plan operations")
|
|
|
|
|
|
|
|
return cmd
|
|
|
|
}
|
2017-05-26 01:19:13 +02:00
|
|
|
|
|
|
|
// plan just uses the standard logic to parse arguments, options, and to create a snapshot and plan.
|
|
|
|
func plan(cmd *cobra.Command, info *envCmdInfo, opts deployOptions) *planResult {
|
2017-06-11 15:52:56 +02:00
|
|
|
contract.Assert(info != nil)
|
|
|
|
contract.Assert(info.Target != nil)
|
2017-05-26 01:19:13 +02:00
|
|
|
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
var source deploy.Source
|
2017-05-26 01:19:13 +02:00
|
|
|
var analyzers []tokens.QName
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
if opts.Delete {
|
|
|
|
// If we are deleting, we use the null source. This just makes it look like we have no new resources.
|
|
|
|
source = deploy.NullSource
|
|
|
|
} else {
|
|
|
|
// If we aren't deleting, we will actually need an object source. This is formed over the result of compiling
|
|
|
|
// the supplied package and will wrap an underlying interpreter that runs the program to create resources.
|
|
|
|
result := compile(cmd, info.Args)
|
|
|
|
if result == nil {
|
2017-05-26 01:19:13 +02:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
// If that succeded, create a new source that will perform interpretation of the compiled program.
|
2017-06-11 02:03:58 +02:00
|
|
|
// TODO[pulumi/lumi#88]: we are passing `nil` as the arguments map; we need to allow a way to pass these.
|
|
|
|
source = deploy.NewEvalSource(result.B.Ctx(), result.Pkg, nil, info.Target.Config)
|
2017-05-26 01:19:13 +02:00
|
|
|
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
// If there are any analyzers in the project file, add them.
|
2017-05-26 01:19:13 +02:00
|
|
|
if as := result.Pkg.Node.Analyzers; as != nil {
|
|
|
|
for _, a := range *as {
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
analyzers = append(analyzers, a)
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
// Append any analyzers from the command line.
|
|
|
|
for _, a := range opts.Analyzers {
|
|
|
|
analyzers = append(analyzers, tokens.QName(a))
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
|
|
|
|
// Generate a plan; this API handles all interesting cases (create, update, delete).
|
|
|
|
ctx := plugin.NewContext(cmdutil.Diag(), nil)
|
2017-06-11 02:03:58 +02:00
|
|
|
plan := deploy.NewPlan(ctx, info.Target, info.Snapshot, source, analyzers)
|
2017-05-26 01:19:13 +02:00
|
|
|
return &planResult{
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
Info: info,
|
|
|
|
Plan: plan,
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
type planResult struct {
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
Info *envCmdInfo // plan command information.
|
|
|
|
Plan *deploy.Plan // the plan created by this command.
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
|
|
|
|
2017-06-15 23:41:55 +02:00
|
|
|
func printPlan(result *planResult, opts deployOptions) error {
|
2017-05-26 01:19:13 +02:00
|
|
|
// First print config/unchanged/etc. if necessary.
|
|
|
|
var prelude bytes.Buffer
|
2017-06-01 19:52:25 +02:00
|
|
|
printPrelude(&prelude, result, opts, true)
|
2017-05-26 01:19:13 +02:00
|
|
|
|
|
|
|
// Now walk the plan's steps and and pretty-print them out.
|
|
|
|
prelude.WriteString(fmt.Sprintf("%vPlanned changes:%v\n", colors.SpecUnimportant, colors.Reset))
|
2017-06-07 19:52:03 +02:00
|
|
|
fmt.Print(colors.Colorize(&prelude))
|
2017-05-26 01:19:13 +02:00
|
|
|
|
2017-06-11 17:09:20 +02:00
|
|
|
iter, err := result.Plan.Iterate()
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
if err != nil {
|
|
|
|
cmdutil.Diag().Errorf(diag.Message("An error occurred while preparing the plan: %v"), err)
|
2017-06-15 23:41:55 +02:00
|
|
|
return err
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
step, err := iter.Next()
|
|
|
|
if err != nil {
|
2017-06-15 00:52:36 +02:00
|
|
|
cmdutil.Diag().Errorf(diag.Message("An error occurred while enumerating the plan: %v"), err)
|
2017-06-15 23:41:55 +02:00
|
|
|
return err
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
}
|
|
|
|
|
2017-06-11 17:09:20 +02:00
|
|
|
var summary bytes.Buffer
|
|
|
|
empty := true
|
|
|
|
counts := make(map[deploy.StepOp]int)
|
|
|
|
for step != nil {
|
|
|
|
op := step.Op()
|
|
|
|
if empty && op != deploy.OpSame {
|
|
|
|
empty = false
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
|
|
|
|
2017-06-11 17:09:20 +02:00
|
|
|
// Print this step information (resource and all its properties).
|
|
|
|
// IDEA: it would be nice if, in the output, we showed the dependencies a la `git log --graph`.
|
|
|
|
if (opts.ShowReplaceSteps || op != deploy.OpReplaceDelete) &&
|
|
|
|
(opts.ShowSames || op != deploy.OpSame) {
|
|
|
|
printStep(&summary, step, opts.Summary, true, "")
|
|
|
|
}
|
2017-05-26 01:19:13 +02:00
|
|
|
|
2017-06-11 17:09:20 +02:00
|
|
|
// Be sure to skip the step so that in-memory state updates are performed.
|
|
|
|
step.Skip()
|
2017-05-26 01:19:13 +02:00
|
|
|
|
2017-06-11 17:09:20 +02:00
|
|
|
counts[step.Op()]++
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
|
2017-06-11 17:09:20 +02:00
|
|
|
var err error
|
|
|
|
if step, err = iter.Next(); err != nil {
|
|
|
|
cmdutil.Diag().Errorf(diag.Message("An error occurred while viewing the plan: %v"), err)
|
2017-06-15 23:41:55 +02:00
|
|
|
return err
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
2017-06-11 17:09:20 +02:00
|
|
|
}
|
2017-05-26 01:19:13 +02:00
|
|
|
|
2017-06-11 17:09:20 +02:00
|
|
|
// If we are doing an empty update, say so.
|
|
|
|
if empty {
|
|
|
|
cmdutil.Diag().Infof(diag.Message("no resources need to be updated"))
|
|
|
|
} else {
|
2017-05-26 01:19:13 +02:00
|
|
|
// Print a summary of operation counts.
|
|
|
|
printSummary(&summary, counts, opts.ShowReplaceSteps, true)
|
2017-06-07 19:52:03 +02:00
|
|
|
fmt.Print(colors.Colorize(&summary))
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
2017-06-15 23:41:55 +02:00
|
|
|
return nil
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
|
|
|
|
2017-06-01 19:52:25 +02:00
|
|
|
func printPrelude(b *bytes.Buffer, result *planResult, opts deployOptions, planning bool) {
|
2017-05-26 01:19:13 +02:00
|
|
|
// If there are configuration variables, show them.
|
|
|
|
if opts.ShowConfig {
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
printConfig(b, result.Info.Target.Config)
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
func printConfig(b *bytes.Buffer, config resource.ConfigMap) {
|
2017-05-26 01:19:13 +02:00
|
|
|
b.WriteString(fmt.Sprintf("%vConfiguration:%v\n", colors.SpecUnimportant, colors.Reset))
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
if config != nil {
|
2017-05-26 01:19:13 +02:00
|
|
|
var toks []string
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
for tok := range config {
|
2017-05-26 01:19:13 +02:00
|
|
|
toks = append(toks, string(tok))
|
|
|
|
}
|
|
|
|
sort.Strings(toks)
|
|
|
|
for _, tok := range toks {
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
b.WriteString(fmt.Sprintf("%v%v: %v\n", detailsIndent, tok, config[tokens.Token(tok)]))
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
func printSummary(b *bytes.Buffer, counts map[deploy.StepOp]int, showReplaceSteps bool, plan bool) {
|
2017-05-26 01:19:13 +02:00
|
|
|
total := 0
|
|
|
|
for op, c := range counts {
|
2017-06-11 17:09:20 +02:00
|
|
|
if op == deploy.OpSame || (!showReplaceSteps && op == deploy.OpReplaceDelete) {
|
2017-05-26 01:19:13 +02:00
|
|
|
continue // skip counting replacement steps unless explicitly requested.
|
|
|
|
}
|
|
|
|
total += c
|
|
|
|
}
|
|
|
|
|
|
|
|
var planned string
|
|
|
|
if plan {
|
|
|
|
planned = "planned "
|
|
|
|
}
|
|
|
|
var colon string
|
|
|
|
if total != 0 {
|
|
|
|
colon = ":"
|
|
|
|
}
|
|
|
|
b.WriteString(fmt.Sprintf("%v total %v%v%v\n", total, planned, plural("change", total), colon))
|
|
|
|
|
|
|
|
var planTo string
|
|
|
|
var pastTense string
|
|
|
|
if plan {
|
|
|
|
planTo = "to "
|
|
|
|
} else {
|
|
|
|
pastTense = "d"
|
|
|
|
}
|
|
|
|
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
for _, op := range deploy.StepOps {
|
2017-06-11 17:09:20 +02:00
|
|
|
if op == deploy.OpSame || (!showReplaceSteps && op == deploy.OpReplaceDelete) {
|
2017-05-26 01:19:13 +02:00
|
|
|
// Unless the user requested it, don't show the fine-grained replacement steps; just the logical ones.
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
if c := counts[op]; c > 0 {
|
|
|
|
b.WriteString(fmt.Sprintf(" %v%v %v %v%v%v%v\n",
|
|
|
|
op.Prefix(), c, plural("resource", c), planTo, op, pastTense, colors.Reset))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func plural(s string, c int) string {
|
|
|
|
if c != 1 {
|
|
|
|
s += "s"
|
|
|
|
}
|
|
|
|
return s
|
|
|
|
}
|
|
|
|
|
|
|
|
const detailsIndent = " " // 4 spaces, plus 2 for "+ ", "- ", and " " leaders
|
|
|
|
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
func printUnchanged(b *bytes.Buffer, stats deploy.PlanSummary, summary bool, planning bool) {
|
2017-05-26 01:19:13 +02:00
|
|
|
b.WriteString(fmt.Sprintf("%vUnchanged resources:%v\n", colors.SpecUnimportant, colors.Reset))
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
for _, res := range stats.Resources() {
|
|
|
|
if stats.Sames()[res.URN()] {
|
|
|
|
b.WriteString(" ") // simulate the 2 spaces for +, -, etc.
|
|
|
|
printResourceHeader(b, res, nil, "")
|
2017-06-15 02:00:13 +02:00
|
|
|
printResourceProperties(b, res.URN(), res, nil, nil, nil, summary, planning, "")
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
}
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
func printStep(b *bytes.Buffer, step *deploy.Step, summary bool, planning bool, indent string) {
|
2017-05-26 01:19:13 +02:00
|
|
|
// First print out the operation's prefix.
|
|
|
|
b.WriteString(step.Op().Prefix())
|
|
|
|
|
|
|
|
// Next print the resource URN, properties, etc.
|
|
|
|
printResourceHeader(b, step.Old(), step.New(), indent)
|
|
|
|
b.WriteString(step.Op().Suffix())
|
2017-06-15 02:00:13 +02:00
|
|
|
printResourceProperties(b, step.URN(), step.Old(), step.New(), step.Inputs(), step.Reasons(),
|
|
|
|
summary, planning, indent)
|
2017-05-26 01:19:13 +02:00
|
|
|
|
|
|
|
// Finally make sure to reset the color.
|
|
|
|
b.WriteString(colors.Reset)
|
|
|
|
}
|
|
|
|
|
2017-06-11 15:52:56 +02:00
|
|
|
func printResourceHeader(b *bytes.Buffer, old *resource.State, new *resource.Object, indent string) {
|
2017-05-26 01:19:13 +02:00
|
|
|
var t tokens.Type
|
2017-06-11 15:52:56 +02:00
|
|
|
if old != nil {
|
2017-05-26 01:19:13 +02:00
|
|
|
t = old.Type()
|
2017-06-11 15:52:56 +02:00
|
|
|
} else {
|
|
|
|
t = new.Type()
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// The primary header is the resource type (since it is easy on the eyes).
|
|
|
|
b.WriteString(fmt.Sprintf("%s:\n", string(t)))
|
|
|
|
}
|
|
|
|
|
2017-06-15 02:00:13 +02:00
|
|
|
func printResourceProperties(b *bytes.Buffer, urn resource.URN, old *resource.State, new *resource.Object,
|
2017-06-11 02:03:58 +02:00
|
|
|
inputs resource.PropertyMap, replaces []resource.PropertyKey, summary bool, planning bool, indent string) {
|
2017-05-26 01:19:13 +02:00
|
|
|
indent += detailsIndent
|
|
|
|
|
|
|
|
// Print out the URN and, if present, the ID, as "pseudo-properties".
|
|
|
|
var id resource.ID
|
2017-06-15 02:00:13 +02:00
|
|
|
if old != nil {
|
2017-05-26 01:19:13 +02:00
|
|
|
id = old.ID()
|
|
|
|
}
|
|
|
|
if id != "" {
|
|
|
|
b.WriteString(fmt.Sprintf("%s[id=%s]\n", indent, string(id)))
|
|
|
|
}
|
2017-06-16 18:46:09 +02:00
|
|
|
b.WriteString(fmt.Sprintf("%s[urn=%s]\n", indent, urn))
|
2017-05-26 01:19:13 +02:00
|
|
|
|
|
|
|
if !summary {
|
|
|
|
// Print all of the properties associated with this resource.
|
|
|
|
if old == nil && new != nil {
|
2017-06-11 02:03:58 +02:00
|
|
|
printObject(b, inputs, planning, indent)
|
2017-05-26 01:19:13 +02:00
|
|
|
} else if new == nil && old != nil {
|
2017-06-05 04:24:48 +02:00
|
|
|
printObject(b, old.Inputs(), planning, indent)
|
2017-05-26 01:19:13 +02:00
|
|
|
} else {
|
2017-06-11 02:03:58 +02:00
|
|
|
contract.Assert(inputs != nil) // use computed properties for diffs.
|
|
|
|
printOldNewDiffs(b, old.Inputs(), inputs, replaces, planning, indent)
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-31 19:36:09 +02:00
|
|
|
func maxKey(keys []resource.PropertyKey) int {
|
2017-05-26 01:19:13 +02:00
|
|
|
maxkey := 0
|
|
|
|
for _, k := range keys {
|
|
|
|
if len(k) > maxkey {
|
|
|
|
maxkey = len(k)
|
|
|
|
}
|
|
|
|
}
|
2017-05-31 19:36:09 +02:00
|
|
|
return maxkey
|
|
|
|
}
|
|
|
|
|
2017-06-01 19:52:25 +02:00
|
|
|
func printObject(b *bytes.Buffer, props resource.PropertyMap, planning bool, indent string) {
|
2017-05-31 19:36:09 +02:00
|
|
|
// Compute the maximum with of property keys so we can justify everything.
|
2017-06-11 02:03:58 +02:00
|
|
|
keys := props.StableKeys()
|
2017-05-31 19:36:09 +02:00
|
|
|
maxkey := maxKey(keys)
|
2017-05-26 01:19:13 +02:00
|
|
|
|
|
|
|
// Now print out the values intelligently based on the type.
|
|
|
|
for _, k := range keys {
|
2017-06-01 19:52:25 +02:00
|
|
|
if v := props[k]; shouldPrintPropertyValue(v, planning) {
|
2017-05-26 01:19:13 +02:00
|
|
|
printPropertyTitle(b, k, maxkey, indent)
|
2017-06-01 19:52:25 +02:00
|
|
|
printPropertyValue(b, v, planning, indent)
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-05 04:24:48 +02:00
|
|
|
// printResourceOutputProperties prints only those properties that either differ from the input properties or, if
|
|
|
|
// there is an old snapshot of the resource, differ from the prior old snapshot's output properties.
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
func printResourceOutputProperties(b *bytes.Buffer, step *deploy.Step, indent string) {
|
2017-05-31 19:36:09 +02:00
|
|
|
indent += detailsIndent
|
|
|
|
b.WriteString(step.Op().Color())
|
|
|
|
b.WriteString(step.Op().Suffix())
|
|
|
|
|
2017-06-05 04:24:48 +02:00
|
|
|
// First fetch all the relevant property maps that we may consult.
|
2017-06-11 02:03:58 +02:00
|
|
|
newins := step.Inputs()
|
|
|
|
newouts := step.Outputs()
|
2017-06-05 04:24:48 +02:00
|
|
|
var oldouts resource.PropertyMap
|
|
|
|
if old := step.Old(); old != nil {
|
|
|
|
oldouts = old.Outputs()
|
|
|
|
}
|
|
|
|
|
|
|
|
// Now sort the keys and enumerate each output property in a deterministic order.
|
2017-06-11 02:03:58 +02:00
|
|
|
keys := newouts.StableKeys()
|
2017-05-31 19:36:09 +02:00
|
|
|
maxkey := maxKey(keys)
|
|
|
|
for _, k := range keys {
|
2017-06-05 04:24:48 +02:00
|
|
|
newout := newouts[k]
|
|
|
|
// Print this property if it is printable, and one of these cases
|
|
|
|
// 1) new ins has it and it's different;
|
|
|
|
// 2) new ins doesn't have it, but old outs does, and it's different;
|
|
|
|
// 3) neither old outs nor new ins contain it;
|
|
|
|
if shouldPrintPropertyValue(newout, true) {
|
|
|
|
var print bool
|
|
|
|
if newin, has := newins[k]; has {
|
|
|
|
print = (newout.Diff(newin) != nil) // case 1
|
|
|
|
} else if oldouts != nil {
|
|
|
|
if oldout, has := oldouts[k]; has {
|
|
|
|
print = (newout.Diff(oldout) != nil) // case 2
|
|
|
|
} else {
|
|
|
|
print = true // case 3
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
print = true // also case 3
|
|
|
|
}
|
|
|
|
|
|
|
|
if print {
|
|
|
|
printPropertyTitle(b, k, maxkey, indent)
|
|
|
|
printPropertyValue(b, newout, false, indent)
|
|
|
|
}
|
2017-05-31 19:36:09 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
b.WriteString(colors.Reset)
|
|
|
|
}
|
|
|
|
|
|
|
|
func shouldPrintPropertyValue(v resource.PropertyValue, outs bool) bool {
|
|
|
|
if v.IsNull() {
|
|
|
|
// by default, don't print nulls (they just clutter up the output)
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
if v.IsOutput() && !outs {
|
|
|
|
// also don't show output properties until the outs parameter tells us to.
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
return true
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
func printPropertyTitle(b *bytes.Buffer, k resource.PropertyKey, align int, indent string) {
|
|
|
|
b.WriteString(fmt.Sprintf("%s%-"+strconv.Itoa(align)+"s: ", indent, k))
|
|
|
|
}
|
|
|
|
|
2017-06-01 19:52:25 +02:00
|
|
|
func printPropertyValue(b *bytes.Buffer, v resource.PropertyValue, planning bool, indent string) {
|
2017-05-26 01:19:13 +02:00
|
|
|
if v.IsNull() {
|
|
|
|
b.WriteString("<null>")
|
|
|
|
} else if v.IsBool() {
|
|
|
|
b.WriteString(fmt.Sprintf("%t", v.BoolValue()))
|
|
|
|
} else if v.IsNumber() {
|
|
|
|
b.WriteString(fmt.Sprintf("%v", v.NumberValue()))
|
|
|
|
} else if v.IsString() {
|
|
|
|
b.WriteString(fmt.Sprintf("%q", v.StringValue()))
|
|
|
|
} else if v.IsArray() {
|
|
|
|
b.WriteString(fmt.Sprintf("[\n"))
|
|
|
|
for i, elem := range v.ArrayValue() {
|
|
|
|
newIndent := printArrayElemHeader(b, i, indent)
|
2017-06-01 19:52:25 +02:00
|
|
|
printPropertyValue(b, elem, planning, newIndent)
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
|
|
|
b.WriteString(fmt.Sprintf("%s]", indent))
|
|
|
|
} else if v.IsComputed() || v.IsOutput() {
|
|
|
|
b.WriteString(v.TypeString())
|
|
|
|
} else {
|
|
|
|
contract.Assert(v.IsObject())
|
|
|
|
b.WriteString("{\n")
|
2017-06-01 19:52:25 +02:00
|
|
|
printObject(b, v.ObjectValue(), planning, indent+" ")
|
2017-05-26 01:19:13 +02:00
|
|
|
b.WriteString(fmt.Sprintf("%s}", indent))
|
|
|
|
}
|
|
|
|
b.WriteString("\n")
|
|
|
|
}
|
|
|
|
|
|
|
|
func getArrayElemHeader(b *bytes.Buffer, i int, indent string) (string, string) {
|
|
|
|
prefix := fmt.Sprintf(" %s[%d]: ", indent, i)
|
|
|
|
return prefix, fmt.Sprintf("%-"+strconv.Itoa(len(prefix))+"s", "")
|
|
|
|
}
|
|
|
|
|
|
|
|
func printArrayElemHeader(b *bytes.Buffer, i int, indent string) string {
|
|
|
|
prefix, newIndent := getArrayElemHeader(b, i, indent)
|
|
|
|
b.WriteString(prefix)
|
|
|
|
return newIndent
|
|
|
|
}
|
|
|
|
|
|
|
|
func printOldNewDiffs(b *bytes.Buffer, olds resource.PropertyMap, news resource.PropertyMap,
|
2017-06-01 19:52:25 +02:00
|
|
|
replaces []resource.PropertyKey, planning bool, indent string) {
|
2017-05-26 01:19:13 +02:00
|
|
|
// Get the full diff structure between the two, and print it (recursively).
|
|
|
|
if diff := olds.Diff(news); diff != nil {
|
2017-06-01 19:52:25 +02:00
|
|
|
printObjectDiff(b, *diff, replaces, false, planning, indent)
|
2017-05-26 01:19:13 +02:00
|
|
|
} else {
|
2017-06-01 19:52:25 +02:00
|
|
|
printObject(b, news, planning, indent)
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func printObjectDiff(b *bytes.Buffer, diff resource.ObjectDiff,
|
2017-06-01 19:52:25 +02:00
|
|
|
replaces []resource.PropertyKey, causedReplace bool, planning bool, indent string) {
|
2017-05-26 01:19:13 +02:00
|
|
|
contract.Assert(len(indent) > 2)
|
|
|
|
|
|
|
|
// Compute the maximum with of property keys so we can justify everything.
|
|
|
|
keys := diff.Keys()
|
2017-05-31 19:36:09 +02:00
|
|
|
maxkey := maxKey(keys)
|
2017-05-26 01:19:13 +02:00
|
|
|
|
|
|
|
// If a list of what causes a resource to get replaced exist, create a handy map.
|
|
|
|
var replaceMap map[resource.PropertyKey]bool
|
|
|
|
if len(replaces) > 0 {
|
|
|
|
replaceMap = make(map[resource.PropertyKey]bool)
|
|
|
|
for _, k := range replaces {
|
|
|
|
replaceMap[k] = true
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// To print an object diff, enumerate the keys in stable order, and print each property independently.
|
|
|
|
for _, k := range keys {
|
|
|
|
title := func(id string) { printPropertyTitle(b, k, maxkey, id) }
|
|
|
|
if add, isadd := diff.Adds[k]; isadd {
|
2017-06-01 19:52:25 +02:00
|
|
|
if shouldPrintPropertyValue(add, planning) {
|
2017-05-26 01:19:13 +02:00
|
|
|
b.WriteString(colors.SpecAdded)
|
|
|
|
title(addIndent(indent))
|
2017-06-01 19:52:25 +02:00
|
|
|
printPropertyValue(b, add, planning, addIndent(indent))
|
2017-05-26 01:19:13 +02:00
|
|
|
b.WriteString(colors.Reset)
|
|
|
|
}
|
|
|
|
} else if delete, isdelete := diff.Deletes[k]; isdelete {
|
2017-06-01 19:52:25 +02:00
|
|
|
if shouldPrintPropertyValue(delete, planning) {
|
2017-05-26 01:19:13 +02:00
|
|
|
b.WriteString(colors.SpecDeleted)
|
|
|
|
title(deleteIndent(indent))
|
2017-06-01 19:52:25 +02:00
|
|
|
printPropertyValue(b, delete, planning, deleteIndent(indent))
|
2017-05-26 01:19:13 +02:00
|
|
|
b.WriteString(colors.Reset)
|
|
|
|
}
|
|
|
|
} else if update, isupdate := diff.Updates[k]; isupdate {
|
|
|
|
if !causedReplace && replaceMap != nil {
|
|
|
|
causedReplace = replaceMap[k]
|
|
|
|
}
|
2017-06-01 19:52:25 +02:00
|
|
|
printPropertyValueDiff(b, title, update, causedReplace, planning, indent)
|
|
|
|
} else if same := diff.Sames[k]; shouldPrintPropertyValue(same, planning) {
|
2017-05-26 01:19:13 +02:00
|
|
|
title(indent)
|
2017-06-01 19:52:25 +02:00
|
|
|
printPropertyValue(b, diff.Sames[k], planning, indent)
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func printPropertyValueDiff(b *bytes.Buffer, title func(string), diff resource.ValueDiff,
|
2017-06-01 19:52:25 +02:00
|
|
|
causedReplace bool, planning bool, indent string) {
|
2017-05-26 01:19:13 +02:00
|
|
|
contract.Assert(len(indent) > 2)
|
|
|
|
|
|
|
|
if diff.Array != nil {
|
|
|
|
title(indent)
|
|
|
|
b.WriteString("[\n")
|
|
|
|
|
|
|
|
a := diff.Array
|
|
|
|
for i := 0; i < a.Len(); i++ {
|
|
|
|
_, newIndent := getArrayElemHeader(b, i, indent)
|
2017-06-08 20:44:16 +02:00
|
|
|
titleFunc := func(id string) { printArrayElemHeader(b, i, id) }
|
2017-05-26 01:19:13 +02:00
|
|
|
if add, isadd := a.Adds[i]; isadd {
|
2017-06-11 02:03:58 +02:00
|
|
|
b.WriteString(deploy.OpCreate.Color())
|
2017-05-26 01:19:13 +02:00
|
|
|
title(addIndent(indent))
|
2017-06-01 19:52:25 +02:00
|
|
|
printPropertyValue(b, add, planning, addIndent(newIndent))
|
2017-05-26 01:19:13 +02:00
|
|
|
b.WriteString(colors.Reset)
|
|
|
|
} else if delete, isdelete := a.Deletes[i]; isdelete {
|
2017-06-11 02:03:58 +02:00
|
|
|
b.WriteString(deploy.OpDelete.Color())
|
2017-05-26 01:19:13 +02:00
|
|
|
title(deleteIndent(indent))
|
2017-06-01 19:52:25 +02:00
|
|
|
printPropertyValue(b, delete, planning, deleteIndent(newIndent))
|
2017-05-26 01:19:13 +02:00
|
|
|
b.WriteString(colors.Reset)
|
|
|
|
} else if update, isupdate := a.Updates[i]; isupdate {
|
2017-06-12 01:33:09 +02:00
|
|
|
printPropertyValueDiff(b, title, update, causedReplace, planning, indent)
|
2017-05-26 01:19:13 +02:00
|
|
|
} else {
|
2017-06-08 20:44:16 +02:00
|
|
|
titleFunc(indent)
|
2017-06-01 19:52:25 +02:00
|
|
|
printPropertyValue(b, a.Sames[i], planning, newIndent)
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
b.WriteString(fmt.Sprintf("%s]\n", indent))
|
|
|
|
} else if diff.Object != nil {
|
|
|
|
title(indent)
|
|
|
|
b.WriteString("{\n")
|
2017-06-01 19:52:25 +02:00
|
|
|
printObjectDiff(b, *diff.Object, nil, causedReplace, planning, indent+" ")
|
2017-05-26 01:19:13 +02:00
|
|
|
b.WriteString(fmt.Sprintf("%s}\n", indent))
|
|
|
|
} else {
|
|
|
|
// If we ended up here, the two values either differ by type, or they have different primitive values. We will
|
|
|
|
// simply emit a deletion line followed by an addition line.
|
2017-05-31 19:36:09 +02:00
|
|
|
if shouldPrintPropertyValue(diff.Old, false) {
|
2017-05-26 01:19:13 +02:00
|
|
|
var color string
|
|
|
|
if causedReplace {
|
2017-06-11 02:03:58 +02:00
|
|
|
color = deploy.OpDelete.Color() // this property triggered replacement; color as a delete
|
2017-05-26 01:19:13 +02:00
|
|
|
} else {
|
2017-06-11 02:03:58 +02:00
|
|
|
color = deploy.OpUpdate.Color()
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
|
|
|
b.WriteString(color)
|
|
|
|
title(deleteIndent(indent))
|
2017-06-01 19:52:25 +02:00
|
|
|
printPropertyValue(b, diff.Old, planning, deleteIndent(indent))
|
2017-05-26 01:19:13 +02:00
|
|
|
b.WriteString(colors.Reset)
|
|
|
|
}
|
2017-05-31 19:36:09 +02:00
|
|
|
if shouldPrintPropertyValue(diff.New, false) {
|
2017-05-26 01:19:13 +02:00
|
|
|
var color string
|
|
|
|
if causedReplace {
|
2017-06-11 02:03:58 +02:00
|
|
|
color = deploy.OpCreate.Color() // this property triggered replacement; color as a create
|
2017-05-26 01:19:13 +02:00
|
|
|
} else {
|
2017-06-11 02:03:58 +02:00
|
|
|
color = deploy.OpUpdate.Color()
|
2017-05-26 01:19:13 +02:00
|
|
|
}
|
|
|
|
b.WriteString(color)
|
|
|
|
title(addIndent(indent))
|
2017-06-01 19:52:25 +02:00
|
|
|
printPropertyValue(b, diff.New, planning, addIndent(indent))
|
2017-05-26 01:19:13 +02:00
|
|
|
b.WriteString(colors.Reset)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func addIndent(indent string) string { return indent[:len(indent)-2] + "+ " }
|
|
|
|
func deleteIndent(indent string) string { return indent[:len(indent)-2] + "- " }
|
|
|
|
func updateIndent(indent string) string { return indent[:len(indent)-2] + "+-" }
|