Pulumi: Add `version` to checkpoint file schema

Created on 6 Feb 2018  路  5Comments  路  Source: pulumi/pulumi

To ensure that checkpoint files can be upgraded from one version of the CLI to the next (when working with local stacks), add a version field to the schema.

@pgavlin Please let me know if this is already tracked elsewhere.

prioritP0

Most helpful comment

I think we should just have a top level version property in the checkpoint which is the version of the checkpoint file format. I expect this stays at 1 for a while, but if we need to break the shape of the format we bump it to 2 and continue with our lives. Things that read checkpoint files should know to first look at the version string and if it鈥檚 not in range they understand, abort.

I like this more then trying to reuse engine versions inside a manifest section because that version isn鈥檛 strictly related to the format of the checkpoint file (since checkpoint management is done outside the engine) and having something that revs at the exact cadence we want and is easy to get to feels cleaner.

All 5 comments

I believe we already encode this information, in the Checkpoint 's Manifest's Version field. Is that what you were after? And the work to support the scenario described is simply adding a hook to confirm that the Version string is "supported" or too old to use?

https://github.com/pulumi/pulumi/blob/master/pkg/resource/stack/deployment.go#L28

// Manifest captures meta-information about this checkpoint file, such as versions of binaries, etc.
type Manifest struct {
    Time    time.Time    `json:"time" yaml:"time"`                           // the time of the deploy.
    Magic   string       `json:"magic" yaml:"magic"`                         // a magic cookie.
    Version string       `json:"version" yaml:"version"`                     // the version of the Pulumi CLI.
    Plugins []PluginInfo `json:"plugins,omitempty" yaml:"plugins,omitempty"` // the plugin binary versions.
}

I think we should just have a top level version property in the checkpoint which is the version of the checkpoint file format. I expect this stays at 1 for a while, but if we need to break the shape of the format we bump it to 2 and continue with our lives. Things that read checkpoint files should know to first look at the version string and if it鈥檚 not in range they understand, abort.

I like this more then trying to reuse engine versions inside a manifest section because that version isn鈥檛 strictly related to the format of the checkpoint file (since checkpoint management is done outside the engine) and having something that revs at the exact cadence we want and is easy to get to feels cleaner.

I concur with @ellismg. This could make our lives a bit easier by allowing us to deserialize checkpoints into something like

type versionedCheckpoint struct {
    Version string `json:"version"`
    Contents json.RawMessage `json:"contents"`
}

Rather than writing more complicated parsing logic using decoders, etc.

@ellismg in the interest of load balancing, do you have available cycles to take over on this?

@ellismg in the interest of load balancing, do you have available cycles to take over on this?

Sure.

Was this page helpful?
0 / 5 - 0 ratings