v0.4

Breaking changes

• Please update your Dockerfile's FROM line. The deployer base images moved from gcr.io/google-marketplace-tools/k8s/deployer_helm to gcr.io/cloud-marketplace-tools/k8s/deployer_helm. See example.

Fixes

• Fixes for Mac OS compatibility issues. Command make app/verify now works correctly on Mac OS.

New features

• Base deployer images are now available for direct pulls at gcr.io/cloud-marketplace-tools/k8s

v0.3

Breaking changes

Scripts

Start.sh

Script start.sh doesn't have --test_parameters anymore. The parameters for testing should be specified in --parameters.

Script start_test.sh is deprecated. Verification should use 'start.sh' with with --entrypoint set to 'deploy_with_tests.sh'

Complete example here.

Stop.sh

Script stop.sh now requires extra parameters:

• --namespace: to specify the kubernetes namespace
• --name: to specify the name of the application

Example here.

Driver.sh

Script driver.sh now requires --parameters, the same way start.sh does. Example here.

Features

Schema file

Supporting Service Account and Storage Class as dependency resources

Some dependency resources can be now be specified through schema files. If the resource does not exist yet, a new resource will be provisioned according to the specifications required for that resource (examples are based on the different type of resources). For now, we support Service Account and Storage Class.

Service account

In schema.yaml:

properties:
  operatorServiceAccount:
    type: string
    x-google-marketplace:
      type: SERVICE_ACCOUNT
      serviceAccount:
        roles:
        # You can list one or more roles following the examples below.
        - type: ClusterRole        # This is a cluster-wide ClusterRole
          rulesType: PREDEFINED
          rulesFromRoleName: edit  # Use predefined role named "edit"
        - type: Role               # This is a namespaced Role
          rulesType: CUSTOM        # We specify our own custom RBAC rules
          rules:
          - apiGroups: ['apps.kubernetes.io/v1alpha1']
            resources: ['Application']
            verbs: ['*']
        - type: ClusterRole
          rulesType: CUSTOM
          rules:
          - apiGroups: ['etcd.database.coreos.com/v1beta2']
            resources: ['EtcdCluster']	
            verbs: ['*']

The resulting ServiceAccount (as well as Roles and RoleBindings) will be created in the same namespace as the application.

This is a real usage example from spark operator app.

SSD storage class

In schema.yaml:

properties:
  storageClass:
    type: string
    x-google-marketplace:
      type: STORAGE_CLASS
      storageClass:
        type: SSD

Dependency resources can be referenced by its property name in manifests, just like any other property defined in schema.yaml.

v0.2

Updating Application resource

componentKinds field

The group field in componentKind list in the Application resource is now required. In the past, the examples skipped this field for core types. This list should now look like:

componentKinds:
  - group: apps/v1
    kind: Deployment
  - group: batch/v1
    kind: Job
  - group: v1
    kind: PersistentVolumeClaim

...instead of:

componentKinds:
  - kind: Deployment
  - kind: Job
  - kind: PersistentVolumeClaim

Updated helm deployer

We have made efforts to make it easier importing an existing helm chart into Marketplace. While we're still restricted to client-side only installation (i.e. no helm hooks), as long as the images are parameterized, the helm chart can be imported with zero to few changes

values.yaml.template

This file has been removed in favor of the new hierarchical support in schema.yaml.

Hierarchical support in schema.yaml properties

Suppose you have the following in your values.yaml file:

core:
  replicas: 3

You can expose this as a parameter in schema.yaml file as followed:

properties:
  core.replicas:
    type: int
    default: 3

Deployer Dockerfile

Update your deployer's Dockerfile to remove ARG MARKETPLACE_REGISTRY and use the following FROM:

FROM gcr.io/google-marketplace-tools/k8s/deployer_helm

Note: The base deployer container above is not yet available for pulling. It still has to be built locally from source for the time being. This can be achieved via .build/marketplace/deployer/helm target in the new Makefile.

We also recommend you parameterize schema.yaml to easily switch the final docker registry to push to. Your Dockerfile can take in 2 arguments, REGISTRY and TAG. All default image values are based on these 2 parameters.

Note: We require that the default values of image properties in the published deployer have matching docker registry and tag. While you can also hardcode these values, parameterizing makes things easier to change.

See wordpress dockerfile.

Breaking changes in Makefile

If you use our Makefile system, please update your Makefile to the latest example at wordpress makefile.

Summary of the changes:

• Reducing the number of Makefile variables to make it more straightforward to use the helper scripts outside of make. Making more explicit and modularizing Makefile templates so that they are easier to follow and can be used more independently.
• The following variables are required for app/install:
  • APP_DEPLOYER_IMAGE
  • APP_PARAMETERS
• The following variable is additionally required for running verification tests:
  • APP_TEST_PARAMETERS
• You do not need to declare environment variables in your shell for make if your Makefile includes gcloud.Makefile. This automatically derives from your gcloud and kubectl setup.

Helm Hooks/Testing

• Annotation "helm.sh/hook" == "test-success" is supported as a way to define tests for helm charts.
• The hook "helm.sh/hook" == "test-failure" is unsupported by design. All tests should be defined as test-success.
• No other helm hook is currently supported (e. g. pre-install, post-install).

Testing non-helm apps

• Test resources should be annotated with "marketplace.cloud.google.com/verification" == "test".

Please refer to the onboarding guide for more details about testing, in "Functional Tests" session.

EAP

Testing the release feature in github

Features:

• We can list features here.

Fixes:

• We can list bug fixes here.