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"
|
|
|
|
|
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
|
|
|
"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
|
|
|
|
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
|
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
|
|
|
var showReads bool
|
|
|
|
var showReplaceDeletes 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-06-21 19:31:06 +02:00
|
|
|
Destroy: false,
|
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
|
|
|
DryRun: true,
|
|
|
|
Analyzers: analyzers,
|
|
|
|
ShowConfig: showConfig,
|
|
|
|
ShowReads: showReads,
|
|
|
|
ShowReplaceDeletes: showReplaceDeletes,
|
|
|
|
ShowSames: showSames,
|
|
|
|
Summary: summary,
|
|
|
|
DOT: dotOutput,
|
2017-06-12 16:16:08 +02:00
|
|
|
}
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 04:45:07 +02:00
|
|
|
result, err := plan(cmd, info, opts)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if 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(
|
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
|
|
|
&showReads, "show-reads", false,
|
|
|
|
"Show resources that will be read, in addition to those that will be modified")
|
|
|
|
cmd.PersistentFlags().BoolVar(
|
|
|
|
&showReplaceDeletes, "show-replace-deletes", false,
|
2017-03-15 23:40:06 +01:00
|
|
|
"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.
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 04:45:07 +02:00
|
|
|
func plan(cmd *cobra.Command, info *envCmdInfo, opts deployOptions) (*planResult, error) {
|
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
|
|
|
|
2017-06-21 19:31:06 +02:00
|
|
|
// Create a context for plugins.
|
|
|
|
ctx, err := plugin.NewContext(cmdutil.Diag(), nil)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
// First, compile the package, in preparatin for interpreting it and creating resources.
|
|
|
|
result := compile(cmd, info.Args)
|
|
|
|
if result == nil {
|
|
|
|
return nil, nil
|
|
|
|
}
|
2017-05-26 01:19:13 +02:00
|
|
|
|
2017-06-21 19:31:06 +02:00
|
|
|
// If that succeded, create a new source that will perform interpretation of the compiled program.
|
|
|
|
// TODO[pulumi/lumi#88]: we are passing `nil` as the arguments map; we need to allow a way to pass these.
|
|
|
|
source := deploy.NewEvalSource(ctx, result.B.Ctx(), result.Pkg, nil, info.Target.Config, opts.Destroy)
|
2017-05-26 01:19:13 +02:00
|
|
|
|
2017-06-21 19:31:06 +02:00
|
|
|
// If there are any analyzers in the project file, add them.
|
|
|
|
var analyzers []tokens.QName
|
|
|
|
if as := result.Pkg.Node.Analyzers; as != nil {
|
|
|
|
for _, a := range *as {
|
|
|
|
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).
|
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,
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 04:45:07 +02:00
|
|
|
}, nil
|
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 {
|
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
|
|
|
return errors.Errorf("An error occurred while preparing the plan: %v", 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-21 19:31:06 +02:00
|
|
|
defer iter.Close()
|
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 {
|
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
|
|
|
return errors.Errorf("An error occurred while enumerating the plan: %v", 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 {
|
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
|
|
|
var err error
|
|
|
|
|
|
|
|
// Perform the pre-step.
|
|
|
|
if err = step.Pre(); err != nil {
|
|
|
|
return errors.Errorf("An error occurred preparing the plan: %v", err)
|
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`.
|
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
|
|
|
track := shouldTrack(step, opts)
|
|
|
|
if track {
|
2017-06-11 17:09:20 +02:00
|
|
|
printStep(&summary, step, opts.Summary, true, "")
|
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
|
|
|
empty = false
|
2017-06-11 17:09:20 +02:00
|
|
|
}
|
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.
|
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
|
|
|
if err = step.Skip(); err != nil {
|
|
|
|
return errors.Errorf("An error occurred while advancing the plan: %v", err)
|
|
|
|
}
|
2017-05-26 01:19:13 +02:00
|
|
|
|
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
|
|
|
if track {
|
|
|
|
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
|
|
|
if step, err = iter.Next(); err != nil {
|
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
|
|
|
return errors.Errorf("An error occurred while viewing the plan: %v", 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.
|
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
|
|
|
printSummary(&summary, counts, 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
|
|
|
}
|
|
|
|
|
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
|
|
|
// shouldTrack returns true if the step should be "tracked"; this affects two things: 1) whether the resource is shown
|
|
|
|
// in the planning phase and 2) whether the resource operation is tallied up and displayed in the final summary.
|
|
|
|
func shouldTrack(step deploy.Step, opts deployOptions) bool {
|
|
|
|
// For certain operations, whether they are tracked is controlled by flags (to cut down on superfluous output).
|
|
|
|
if _, isrd := step.(deploy.ReadStep); isrd {
|
|
|
|
return opts.ShowReads
|
|
|
|
} else if step.Op() == deploy.OpSame {
|
|
|
|
return opts.ShowSames
|
|
|
|
} else if step.Op() == deploy.OpDelete && step.(*deploy.DeleteStep).Replaced() {
|
|
|
|
return opts.ShowReplaceDeletes
|
|
|
|
}
|
|
|
|
// By default, however, steps are tracked.
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
func printSummary(b *bytes.Buffer, counts map[deploy.StepOp]int, plan bool) {
|
2017-05-26 01:19:13 +02:00
|
|
|
total := 0
|
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
|
|
|
for _, c := range counts {
|
2017-05-26 01:19:13 +02:00
|
|
|
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-05-26 01:19:13 +02:00
|
|
|
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
|
|
|
|
|
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
|
|
|
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())
|
|
|
|
|
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
|
|
|
// Next, print the resource type (since it is easy on the eyes and can be quickly identified).
|
|
|
|
printStepHeader(b, step)
|
2017-05-26 01:19:13 +02:00
|
|
|
b.WriteString(step.Op().Suffix())
|
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
|
|
|
|
|
|
|
// Next print the resource URN, properties, etc.
|
|
|
|
if mut, ismut := step.(deploy.MutatingStep); ismut {
|
|
|
|
var replaces []resource.PropertyKey
|
|
|
|
if step.Op() == deploy.OpReplace {
|
|
|
|
replaces = step.(*deploy.ReplaceStep).Reasons()
|
|
|
|
}
|
|
|
|
printResourceProperties(b,
|
|
|
|
mut.URN(), mut.Old(), mut.New(), mut.Inputs(), replaces, summary, planning, indent)
|
|
|
|
} else if rd, isrd := step.(deploy.ReadStep); isrd {
|
|
|
|
for _, res := range rd.Resources() {
|
|
|
|
printResourceProperties(b,
|
|
|
|
"", nil, res, res.CopyProperties(), nil, summary, planning, indent)
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
contract.Failf("Expected each step to either be mutating or read-only")
|
|
|
|
}
|
2017-05-26 01:19:13 +02:00
|
|
|
|
|
|
|
// Finally make sure to reset the color.
|
|
|
|
b.WriteString(colors.Reset)
|
|
|
|
}
|
|
|
|
|
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
|
|
|
func printStepHeader(b *bytes.Buffer, step deploy.Step) {
|
|
|
|
b.WriteString(fmt.Sprintf("%s:\n", string(step.Type())))
|
|
|
|
}
|
2017-05-26 01:19:13 +02:00
|
|
|
|
2017-06-15 02:00:13 +02:00
|
|
|
func printResourceProperties(b *bytes.Buffer, urn resource.URN, old *resource.State, new *resource.Object,
|
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
|
|
|
props 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)))
|
|
|
|
}
|
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
|
|
|
if urn != "" {
|
|
|
|
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 {
|
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
|
|
|
printObject(b, props, 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 {
|
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
|
|
|
contract.Assert(props != nil) // use computed properties for diffs.
|
|
|
|
printOldNewDiffs(b, old.Inputs(), props, 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.
|
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
|
|
|
func printResourceOutputProperties(b *bytes.Buffer, step deploy.Step, indent string) {
|
|
|
|
mut, ismut := step.(deploy.MutatingStep)
|
|
|
|
if !ismut {
|
|
|
|
// Only mutating steps have output properties associated with them.
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
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.
|
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
|
|
|
newins := mut.Inputs()
|
|
|
|
newouts := mut.Outputs()
|
2017-06-05 04:24:48 +02:00
|
|
|
var oldouts resource.PropertyMap
|
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
|
|
|
if old := mut.Old(); old != nil {
|
2017-06-05 04:24:48 +02:00
|
|
|
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())
|
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
|
|
|
titleFunc(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())
|
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
|
|
|
titleFunc(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] + "- " }
|