maxmustermann/pulumi
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
pulumi/cmd/husk_deploy.go

56 lines
2.1 KiB
Go
Raw Normal View History

Coconut!
2017-02-25 16:25:33 +01:00
// Copyright 2016 Pulumi, Inc. All rights reserved.
Repivot plan/apply commands; prepare for updates This change repivots the plan/apply commands slightly. This is largely in preparation for performing deletes and updates of existing environments. The old way was slightly confusing and made things appear more "magical" than they actually are. Namely, different things are needed for different kinds of deployment operations, and trying to present them each underneath a single pair of CLI commands just leads to weird modality and options. The new way is to offer three commands: create, update, and delete. Each does what it says on the tin: create provisions a new environment, update makes resource updates to an existing one, and delete tears down an existing one entirely. The arguments are what make this interesting: create demands a MuPackage to evaluate (producing the new desired state snapshot), update takes *both* an existing snapshot file plus a MuPackage to evaluate (producing the new desired state snapshot to diff against the existing one), and delete merely takes an existing snapshot file and no MuPackage, since all it must do is tear down an existing known environment. Replacing the plan functionality is the --dry-run (-n) flag that may be passed to any of the above commands. This will print out the plan without actually performing any opterations. All commands produce serializable resource files in the MuGL file format, and attempt to do smart things with respect to backups, etc., to support the intended "Git-oriented" workflow of the pure CLI dev experience.
2017-02-22 20:21:26 +01:00
package cmd
import (
"github.com/spf13/cobra"
)
Reorganize deployment commands As part of pulumi/coconut#94 -- adding targeting capabilities -- I've decided to (yet again) reorganize the deployment commands a bit. This makes targets ("husks") more of a first class thing. Namely, you must first initialize a husk before using it: $ coco husk init staging Coconut husk 'staging' initialized; ready for deployments Eventually, this is when you will be given a choice to configure it. Afterwards, you can perform deployments. The first one is like a create, but subsequent ones just figure out the right thing to do and do it: $ ... make some changes ... $ coco husk deploy staging ... standard deployment progress spew ... Finally, should you want to teardown an entire environment: $ coco husk destroy staging ... standard deletion progress spew for all resources ... Coconut husk 'staging' has been destroyed!
2017-02-26 20:20:14 +01:00
func newHuskDeployCmd() *cobra.Command {
Repivot plan/apply commands; prepare for updates This change repivots the plan/apply commands slightly. This is largely in preparation for performing deletes and updates of existing environments. The old way was slightly confusing and made things appear more "magical" than they actually are. Namely, different things are needed for different kinds of deployment operations, and trying to present them each underneath a single pair of CLI commands just leads to weird modality and options. The new way is to offer three commands: create, update, and delete. Each does what it says on the tin: create provisions a new environment, update makes resource updates to an existing one, and delete tears down an existing one entirely. The arguments are what make this interesting: create demands a MuPackage to evaluate (producing the new desired state snapshot), update takes *both* an existing snapshot file plus a MuPackage to evaluate (producing the new desired state snapshot to diff against the existing one), and delete merely takes an existing snapshot file and no MuPackage, since all it must do is tear down an existing known environment. Replacing the plan functionality is the --dry-run (-n) flag that may be passed to any of the above commands. This will print out the plan without actually performing any opterations. All commands produce serializable resource files in the MuGL file format, and attempt to do smart things with respect to backups, etc., to support the intended "Git-oriented" workflow of the pure CLI dev experience.
2017-02-22 20:21:26 +01:00
var dryRun bool
Rename --show-sames to --show-unchanged Per Eric's feedback.
2017-02-27 20:08:14 +01:00
var showUnchanged bool
Flip the summarization polarity This change shows detailed output -- resources, their properties, and a full articulation of plan steps -- and permits summarization with the --summary (or -s) flag.
2017-02-25 16:55:22 +01:00
var summary bool
Repivot plan/apply commands; prepare for updates This change repivots the plan/apply commands slightly. This is largely in preparation for performing deletes and updates of existing environments. The old way was slightly confusing and made things appear more "magical" than they actually are. Namely, different things are needed for different kinds of deployment operations, and trying to present them each underneath a single pair of CLI commands just leads to weird modality and options. The new way is to offer three commands: create, update, and delete. Each does what it says on the tin: create provisions a new environment, update makes resource updates to an existing one, and delete tears down an existing one entirely. The arguments are what make this interesting: create demands a MuPackage to evaluate (producing the new desired state snapshot), update takes *both* an existing snapshot file plus a MuPackage to evaluate (producing the new desired state snapshot to diff against the existing one), and delete merely takes an existing snapshot file and no MuPackage, since all it must do is tear down an existing known environment. Replacing the plan functionality is the --dry-run (-n) flag that may be passed to any of the above commands. This will print out the plan without actually performing any opterations. All commands produce serializable resource files in the MuGL file format, and attempt to do smart things with respect to backups, etc., to support the intended "Git-oriented" workflow of the pure CLI dev experience.
2017-02-22 20:21:26 +01:00
var output string
var cmd = &cobra.Command{
Reorganize deployment commands As part of pulumi/coconut#94 -- adding targeting capabilities -- I've decided to (yet again) reorganize the deployment commands a bit. This makes targets ("husks") more of a first class thing. Namely, you must first initialize a husk before using it: $ coco husk init staging Coconut husk 'staging' initialized; ready for deployments Eventually, this is when you will be given a choice to configure it. Afterwards, you can perform deployments. The first one is like a create, but subsequent ones just figure out the right thing to do and do it: $ ... make some changes ... $ coco husk deploy staging ... standard deployment progress spew ... Finally, should you want to teardown an entire environment: $ coco husk destroy staging ... standard deletion progress spew for all resources ... Coconut husk 'staging' has been destroyed!
2017-02-26 20:20:14 +01:00
Use: "deploy <husk> [<nut>] [-- [<args>]]",
Short: "Deploy resource updates, creations, and deletions to a husk",
Long: "Deploy resource updates, creations, and deletions to a husk\n" +
Repivot plan/apply commands; prepare for updates This change repivots the plan/apply commands slightly. This is largely in preparation for performing deletes and updates of existing environments. The old way was slightly confusing and made things appear more "magical" than they actually are. Namely, different things are needed for different kinds of deployment operations, and trying to present them each underneath a single pair of CLI commands just leads to weird modality and options. The new way is to offer three commands: create, update, and delete. Each does what it says on the tin: create provisions a new environment, update makes resource updates to an existing one, and delete tears down an existing one entirely. The arguments are what make this interesting: create demands a MuPackage to evaluate (producing the new desired state snapshot), update takes *both* an existing snapshot file plus a MuPackage to evaluate (producing the new desired state snapshot to diff against the existing one), and delete merely takes an existing snapshot file and no MuPackage, since all it must do is tear down an existing known environment. Replacing the plan functionality is the --dry-run (-n) flag that may be passed to any of the above commands. This will print out the plan without actually performing any opterations. All commands produce serializable resource files in the MuGL file format, and attempt to do smart things with respect to backups, etc., to support the intended "Git-oriented" workflow of the pure CLI dev experience.
2017-02-22 20:21:26 +01:00
"\n" +
Add basic targeting capability This change partially implements pulumi/coconut#94, by adding the ability to name targets during creation and reuse those names during deletion and update. This simplifies the management of deployment records, checkpoints, and snapshots. I've opted to call these things "husks" (perhaps going overboard with joy after our recent renaming). The basic idea is that for any executable Nut that will be deployed, you have a nutpack/ directory whose layout looks roughly as follows: nutpack/ bin/ Nutpack.json ... any other compiled artifacts ... husks/ ... one snapshot per husk ... For example, if we had a stage and prod husk, we would have: nutpack/ bin/... husks/ prod.json stage.json In the prod.json and stage.json files, we'd have the most recent deployment record for that environment. These would presumably get checked in and versioned along with the overall Nut, so that we can use Git history for rollbacks, etc. The create, update, and delete commands look in the right place for these files automatically, so you don't need to manually supply them.
2017-02-25 18:24:52 +01:00
"This command updates an existing husk environment whose state is represented by the\n" +
Repivot plan/apply commands; prepare for updates This change repivots the plan/apply commands slightly. This is largely in preparation for performing deletes and updates of existing environments. The old way was slightly confusing and made things appear more "magical" than they actually are. Namely, different things are needed for different kinds of deployment operations, and trying to present them each underneath a single pair of CLI commands just leads to weird modality and options. The new way is to offer three commands: create, update, and delete. Each does what it says on the tin: create provisions a new environment, update makes resource updates to an existing one, and delete tears down an existing one entirely. The arguments are what make this interesting: create demands a MuPackage to evaluate (producing the new desired state snapshot), update takes *both* an existing snapshot file plus a MuPackage to evaluate (producing the new desired state snapshot to diff against the existing one), and delete merely takes an existing snapshot file and no MuPackage, since all it must do is tear down an existing known environment. Replacing the plan functionality is the --dry-run (-n) flag that may be passed to any of the above commands. This will print out the plan without actually performing any opterations. All commands produce serializable resource files in the MuGL file format, and attempt to do smart things with respect to backups, etc., to support the intended "Git-oriented" workflow of the pure CLI dev experience.
2017-02-22 20:21:26 +01:00
"existing snapshot file. The new desired state is computed by compiling and evaluating\n" +
Add basic targeting capability This change partially implements pulumi/coconut#94, by adding the ability to name targets during creation and reuse those names during deletion and update. This simplifies the management of deployment records, checkpoints, and snapshots. I've opted to call these things "husks" (perhaps going overboard with joy after our recent renaming). The basic idea is that for any executable Nut that will be deployed, you have a nutpack/ directory whose layout looks roughly as follows: nutpack/ bin/ Nutpack.json ... any other compiled artifacts ... husks/ ... one snapshot per husk ... For example, if we had a stage and prod husk, we would have: nutpack/ bin/... husks/ prod.json stage.json In the prod.json and stage.json files, we'd have the most recent deployment record for that environment. These would presumably get checked in and versioned along with the overall Nut, so that we can use Git history for rollbacks, etc. The create, update, and delete commands look in the right place for these files automatically, so you don't need to manually supply them.
2017-02-25 18:24:52 +01:00
"an executable Nut, 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" +
Repivot plan/apply commands; prepare for updates This change repivots the plan/apply commands slightly. This is largely in preparation for performing deletes and updates of existing environments. The old way was slightly confusing and made things appear more "magical" than they actually are. Namely, different things are needed for different kinds of deployment operations, and trying to present them each underneath a single pair of CLI commands just leads to weird modality and options. The new way is to offer three commands: create, update, and delete. Each does what it says on the tin: create provisions a new environment, update makes resource updates to an existing one, and delete tears down an existing one entirely. The arguments are what make this interesting: create demands a MuPackage to evaluate (producing the new desired state snapshot), update takes *both* an existing snapshot file plus a MuPackage to evaluate (producing the new desired state snapshot to diff against the existing one), and delete merely takes an existing snapshot file and no MuPackage, since all it must do is tear down an existing known environment. Replacing the plan functionality is the --dry-run (-n) flag that may be passed to any of the above commands. This will print out the plan without actually performing any opterations. All commands produce serializable resource files in the MuGL file format, and attempt to do smart things with respect to backups, etc., to support the intended "Git-oriented" workflow of the pure CLI dev experience.
2017-02-22 20:21:26 +01:00
"place to achieve the desired state. This command results in a full snapshot of the\n" +
"environment's new resource state, so that it may be updated incrementally again later.\n" +
"\n" +
Add basic targeting capability This change partially implements pulumi/coconut#94, by adding the ability to name targets during creation and reuse those names during deletion and update. This simplifies the management of deployment records, checkpoints, and snapshots. I've opted to call these things "husks" (perhaps going overboard with joy after our recent renaming). The basic idea is that for any executable Nut that will be deployed, you have a nutpack/ directory whose layout looks roughly as follows: nutpack/ bin/ Nutpack.json ... any other compiled artifacts ... husks/ ... one snapshot per husk ... For example, if we had a stage and prod husk, we would have: nutpack/ bin/... husks/ prod.json stage.json In the prod.json and stage.json files, we'd have the most recent deployment record for that environment. These would presumably get checked in and versioned along with the overall Nut, so that we can use Git history for rollbacks, etc. The create, update, and delete commands look in the right place for these files automatically, so you don't need to manually supply them.
2017-02-25 18:24:52 +01:00
"By default, the Nut to execute is loaded from the current directory. Optionally, an\n" +
"explicit path can be provided using the [nut-file] argument.",
Repivot plan/apply commands; prepare for updates This change repivots the plan/apply commands slightly. This is largely in preparation for performing deletes and updates of existing environments. The old way was slightly confusing and made things appear more "magical" than they actually are. Namely, different things are needed for different kinds of deployment operations, and trying to present them each underneath a single pair of CLI commands just leads to weird modality and options. The new way is to offer three commands: create, update, and delete. Each does what it says on the tin: create provisions a new environment, update makes resource updates to an existing one, and delete tears down an existing one entirely. The arguments are what make this interesting: create demands a MuPackage to evaluate (producing the new desired state snapshot), update takes *both* an existing snapshot file plus a MuPackage to evaluate (producing the new desired state snapshot to diff against the existing one), and delete merely takes an existing snapshot file and no MuPackage, since all it must do is tear down an existing known environment. Replacing the plan functionality is the --dry-run (-n) flag that may be passed to any of the above commands. This will print out the plan without actually performing any opterations. All commands produce serializable resource files in the MuGL file format, and attempt to do smart things with respect to backups, etc., to support the intended "Git-oriented" workflow of the pure CLI dev experience.
2017-02-22 20:21:26 +01:00
Run: func(cmd *cobra.Command, args []string) {
Unify a bit of command logic, and hoist some failure modes
2017-02-27 23:13:27 +01:00
if info := initHuskCmd(cmd, args); info != nil {
apply(cmd, info, applyOptions{
Delete: false,
DryRun: dryRun,
ShowUnchanged: showUnchanged,
Summary: summary,
Output: output,
})
Add confirmation for destroy
2017-02-27 22:53:15 +01:00
}
Repivot plan/apply commands; prepare for updates This change repivots the plan/apply commands slightly. This is largely in preparation for performing deletes and updates of existing environments. The old way was slightly confusing and made things appear more "magical" than they actually are. Namely, different things are needed for different kinds of deployment operations, and trying to present them each underneath a single pair of CLI commands just leads to weird modality and options. The new way is to offer three commands: create, update, and delete. Each does what it says on the tin: create provisions a new environment, update makes resource updates to an existing one, and delete tears down an existing one entirely. The arguments are what make this interesting: create demands a MuPackage to evaluate (producing the new desired state snapshot), update takes *both* an existing snapshot file plus a MuPackage to evaluate (producing the new desired state snapshot to diff against the existing one), and delete merely takes an existing snapshot file and no MuPackage, since all it must do is tear down an existing known environment. Replacing the plan functionality is the --dry-run (-n) flag that may be passed to any of the above commands. This will print out the plan without actually performing any opterations. All commands produce serializable resource files in the MuGL file format, and attempt to do smart things with respect to backups, etc., to support the intended "Git-oriented" workflow of the pure CLI dev experience.
2017-02-22 20:21:26 +01:00
},
}
cmd.PersistentFlags().BoolVarP(
&dryRun, "dry-run", "n", false,
"Don't actually update resources; just print out the planned updates")
Add a --show-sames flag This change adds a --show-sames flag to `coco husk deploy`. This is useful as I'm working on updates, to show what resources haven't changed during a deployment.
2017-02-27 19:58:24 +01:00
cmd.PersistentFlags().BoolVar(
Rename --show-sames to --show-unchanged Per Eric's feedback.
2017-02-27 20:08:14 +01:00
&showUnchanged, "show-unchanged", false,
"Show resources that needn't be updated because they haven't changed, alongside those that do")
Flip the summarization polarity This change shows detailed output -- resources, their properties, and a full articulation of plan steps -- and permits summarization with the --summary (or -s) flag.
2017-02-25 16:55:22 +01:00
cmd.PersistentFlags().BoolVarP(
&summary, "summary", "s", false,
"Only display summarization of resources and plan operations")
Repivot plan/apply commands; prepare for updates This change repivots the plan/apply commands slightly. This is largely in preparation for performing deletes and updates of existing environments. The old way was slightly confusing and made things appear more "magical" than they actually are. Namely, different things are needed for different kinds of deployment operations, and trying to present them each underneath a single pair of CLI commands just leads to weird modality and options. The new way is to offer three commands: create, update, and delete. Each does what it says on the tin: create provisions a new environment, update makes resource updates to an existing one, and delete tears down an existing one entirely. The arguments are what make this interesting: create demands a MuPackage to evaluate (producing the new desired state snapshot), update takes *both* an existing snapshot file plus a MuPackage to evaluate (producing the new desired state snapshot to diff against the existing one), and delete merely takes an existing snapshot file and no MuPackage, since all it must do is tear down an existing known environment. Replacing the plan functionality is the --dry-run (-n) flag that may be passed to any of the above commands. This will print out the plan without actually performing any opterations. All commands produce serializable resource files in the MuGL file format, and attempt to do smart things with respect to backups, etc., to support the intended "Git-oriented" workflow of the pure CLI dev experience.
2017-02-22 20:21:26 +01:00
cmd.PersistentFlags().StringVarP(
&output, "output", "o", "",
Add basic targeting capability This change partially implements pulumi/coconut#94, by adding the ability to name targets during creation and reuse those names during deletion and update. This simplifies the management of deployment records, checkpoints, and snapshots. I've opted to call these things "husks" (perhaps going overboard with joy after our recent renaming). The basic idea is that for any executable Nut that will be deployed, you have a nutpack/ directory whose layout looks roughly as follows: nutpack/ bin/ Nutpack.json ... any other compiled artifacts ... husks/ ... one snapshot per husk ... For example, if we had a stage and prod husk, we would have: nutpack/ bin/... husks/ prod.json stage.json In the prod.json and stage.json files, we'd have the most recent deployment record for that environment. These would presumably get checked in and versioned along with the overall Nut, so that we can use Git history for rollbacks, etc. The create, update, and delete commands look in the right place for these files automatically, so you don't need to manually supply them.
2017-02-25 18:24:52 +01:00
"Serialize the resulting husk snapshot to a specific file, instead of overwriting the existing one")
Repivot plan/apply commands; prepare for updates This change repivots the plan/apply commands slightly. This is largely in preparation for performing deletes and updates of existing environments. The old way was slightly confusing and made things appear more "magical" than they actually are. Namely, different things are needed for different kinds of deployment operations, and trying to present them each underneath a single pair of CLI commands just leads to weird modality and options. The new way is to offer three commands: create, update, and delete. Each does what it says on the tin: create provisions a new environment, update makes resource updates to an existing one, and delete tears down an existing one entirely. The arguments are what make this interesting: create demands a MuPackage to evaluate (producing the new desired state snapshot), update takes *both* an existing snapshot file plus a MuPackage to evaluate (producing the new desired state snapshot to diff against the existing one), and delete merely takes an existing snapshot file and no MuPackage, since all it must do is tear down an existing known environment. Replacing the plan functionality is the --dry-run (-n) flag that may be passed to any of the above commands. This will print out the plan without actually performing any opterations. All commands produce serializable resource files in the MuGL file format, and attempt to do smart things with respect to backups, etc., to support the intended "Git-oriented" workflow of the pure CLI dev experience.
2017-02-22 20:21:26 +01:00
return cmd
}
Reference in a new issue Copy permalink