Introduce bndl --with-defaults argument

markusjura commented 7 years ago

The new bndl --with-defaults argument can be used to declare bundle configuration defaults if these properties are not present as bndl arguments or as input. This argument is especially handy when creating a bundle or bundle configuration from scratch, e.g.

bndl --format bundle --with-defaults generic --start-command '["bin/start]"' -o my-bundle.zip

The --with-defaults arguments take an application type as a value. Depending on the application type, different defaults are used. The following application types are currently available:

akka
generic
lagom
play

This PR is also changing and fixing:

Bundle validation: We now check if properties are empty or not. If a property is not allowed to be empty, e.g. components but is empty, then a validation error is thrown. We do not perform the empty checks for the properties components.endpoints and components.endpoints.start-command because in ConductR 2.0 and below the need to be specified. Otherwise, an exception during conduct load is thrown. conductr-cli has been changed so that we always declare an empty endpoints property for a component, if no endpoints have been specified
Detecting a component name has been improved. Prior to this commit it was necessary to always specify the --component argument for each component argument, e.g. --start-command '["bin'start"]' --component my-component. Now, if no component exists in the bundle.conf we then use the name of the bundle.conf as the component name. This logic was also applied in sbt-conductr. Therefore, the user doesn't need to specify the --component arguments as long as the given bundle.conf input does not contain several components.
The components.endpoints.file-system-type is now derived from the --format argument

markusjura commented 7 years ago

Manual tests

Creating bundles

New bundle from scratch - simple

Without any input, the --format argument needs to be specified because we cannot auto-detect the format. The --start-command needs to be specified as well because it is a required property inside a component and a component is also required.

Note that we do not declare the --component argument. As a result, the component name is derived from the bundle name.

$ bndl --format bundle --with-defaults akka --start-command '["bin/start"]' -o /tmp/my-bundle.zip

$ unzip -c /tmp/my-bundle.zip bundle/bundle.conf | cat
Archive:  /tmp/my-bundle.zip
 extracting: bundle/bundle.conf
annotations {}
compatibilityVersion = "0"
components {
  bundle {
    start-command = [
      "bin/start"
    ]
    description = ""
    file-system-type = "universal"
  }
}
diskSpace = 1073741824
memory = 402653184
name = "bundle"
nrOfCpus = 0.1
roles = [
  "web"
]
system = "bundle"
systemVersion = "0"
tags = [
  "0.0.1"
]
version = "1"

New bundle from scratch - complex

$ bndl --format bundle --with-defaults generic --start-command '["bin/start"]' --check \$MY_BUNDLE_HOST --endpoint web --bind-protocol http --service-name web --acl http:/subpath --memory 702653184 --tag 1.0.0 -o /tmp/my-bundle.zip

$ unzip -c /tmp/my-bundle.zip bundle/bundle.conf | cat
Archive:  /tmp/my-bundle.zip
 extracting: bundle/bundle.conf
annotations {}
components {
  bundle-status {
    description = "Status check for the bundle component"
    file-system-type = "universal"
    start-command = [
      "check"
      "$MY_BUNDLE_HOST"
    ]
    endpoints {}
  }
  bundle {
    endpoints {
      web {
        bind-protocol = "http"
        bind-port = 0
        service-name = "web"
        acls = [
          {
            http {
              requests = [
                {
                  path = "/subpath"
                }
              ]
            }
          }
        ]
      }
    }
    start-command = [
      "bin/start"
    ]
    description = ""
    file-system-type = "universal"
  }
}
compatibilityVersion = "0"
diskSpace = 1073741824
memory = 702653184
name = "bundle"
nrOfCpus = 0.1
roles = [
  "web"
]
system = "bundle"
systemVersion = "0"
tags = [
  "1.0.0"
]
version = "1"

Validation handling

Emptiness property check

Given the following bundle.conf:

$ cat ~/.conductr/cache/bundle/visualizer/bundle.conf
version = "1"
name = ""
compatibilityVersion = ""
system = "visualizer"
systemVersion = "2"
nrOfCpus = 0.1
memory = 402653184
diskSpace = 200000000
roles = [
  "web"
]
components {}

$ bndl ~/.conductr/cache/bundle/visualizer/bundle.conf --format configuration -o my-bundle-conf.zip
Error: bndl: bundle.conf validation errors:
  The following properties are not allowed to be empty: name, compatibilityVersion, components

markusjura commented 7 years ago

Also, this is a tangent but I wonder if it makes sense to be able to add a component to an existing bundle some day using bndl or if that should be done "out of band" by unzipping, modifying bundle.conf, adding the component and then running bndl or shazar on the directory.

Yes, the bndl command should provide this ability as well. An easy way to achieve that is to provide a --config argument at which you can specify either a hocon string or hocon file. This source will be then used to overwrite the bndl input. So the user can choose if they either use arguments such as --endpoint, --start-command, etc. to overwrite an input or they can use the --config argument to overwrite an input. The latter use case might be favored on CI, staging and production scenarios at which a bundle.conf per environment is created.

typesafehub / conductr-cli