Migration - What's changed? V1 -> V2

[PhillypHenning]

This discussion will be used to capture any changes that will need to be noted in the migration documentation.

[PhillypHenning]

BitOps core 🧵

[PhillypHenning]

Bitops is no longer using the ENVIRONMENT value, it instead uses; BITOPS_ENVIRONMENT

Easiest migration solution;
Update startup command to read as followed;

docker run \
-e BITOPS_ENVIRONMENT=$ENVIRONMENT   \    <-- If the ENVIRONMENT variable is being used. This is a simple approach. 
-v /path/to/ops_repo:/opt/bitops_deployment    \
bitovi/bitops:latest

[PhillypHenning]

BitOps core exported environment variables now have a prefix of BITOPS_

BitOps plugins (tool specific) environment variable exports are prefixed with; BITOPS_<PLUGIN NAME>

Examples
BITOPS_TERRAFORM_ENV_VAR
BITOPS_ANSIBLE_ENV_VAR

[PhillypHenning]

Value add

ENVIRONMENT is a contentious variable name so to avoid unnecessary conflict we've decided to prefix it with BITOPS_.

This is also a pattern we use for exported environment variables.

[PhillypHenning]

OpsRepo 🧵

[PhillypHenning]

ops_repo level bitops.config.yaml have had one important update; The cli attribute "stack-action" has been added. This attribute is used to tell the bitops plugin which method it is invoking.

For example, the terraform plugin, has 3 stack-actions;

• apply
• plan
• destroy

Old method

terraform:
    cli: {}
    options:
        command: apply

New method

terraform:
  cli:
    stack-action: apply

Reasoning for the change
This pattern is used by BitOps to standardize how a plugin specifies an action

[mickmcgrath13]

@PhillypHenning @shyamrayaprolu should it be:

terraform:
  options:
    stack-action: apply

the reason being ${tool}.cli should be reserved for the paramegers the cli tool itself uses, and ${tool}.options should be for what bitops uses to control the cli tool itself.

thoughts?

[PhillypHenning]

Personally I'd like to keep it in the CLI section as;

• It does directly related to what the CLI is about to act on

As well, it's not optional, and though 'options' doesn't necessarily mean optional, I do see them as somewhat related. (There will be circumstance when that isn't the case.

[PhillypHenning]

Value add

As we move into the world of plugins, we needed a way to consolidate the "actions" that a plugin can take. The stack-action attribute creates a clear pattern for plugins to follow and for BitOps to process.

[PhillypHenning]

Plugin 🧵

[PhillypHenning]

@shyamrayaprolu please add a "stack actions" section where relevant to the top of the plugin READMEs

[PhillypHenning]

Ansible
changed attributes

depreciated attributes

• ansible.cli.vault_id
• ansible.cli.vault_password
• ansible.options.verbosity

new attributes

---

Terraform
changed attributes

depreciated attributes

new attributes

• ansible.options.init-upgrade

---

Helm
changed attributes

• helm.options.uninstall-charts --> Changed to --> helm.options.uninstall
• helm.option.kubeconfig.fetch.enabled --> Changed to --> helm.option.kubeconfig.fetch.fetch_kubeconfig

depreciated attributes

new attributes

• helm.options.default-root-dir
• helm.options.default-dir-flag
• helm.options.default-sub-dir

---

Cloudformation
changed attributes

• cloudformation.options.cfn-files.parameters.enabled --> Changed to --> cloudformation.options.cfn-files.parameters.template-param-flag
• cloudformation.options.cfn-files.parameters.template-file --> Changed to --> cloudformation.options.cfn-files.parameters.template-param-file

depreciated attributes

new attributes

• cloudformation.options.s3bucket
• cloudformation.options.s3prefix

[PhillypHenning]

Value add

misc.

A few new options were added, some were modified to use new patterns, and a very few were depreciated.

(Phil note) I don't foresee this being an issue)

[PhillypHenning]

Docs have been added capturing this

[mickmcgrath13]

https://bitovi.github.io/bitops/migration/2.0.0-migration/