Services defined in OpenCompose should be extendable by Kubernetes YAML snippets

[concaf]

We should make the OpenCompose spec in a way that it can be made extensible by valid Kubernetes object definitions which are not supported by OpenCompose.

The spec should be able to merge Kubernetes objects in some way.

Let's discuss more on this issue.

---

Writing out loud here, does something like this make sense -

version: '0.1-dev'

services:
- name: database
  containers:
  - image: mariadb:10
    env:
    - MYSQL_ROOT_PASSWORD=rootpasswd
    - MYSQL_DATABASE=wordpress
    - MYSQL_USER=wordpress
    - MYSQL_PASSWORD=wordpress
    ports:
    - port: 3306
    merge:
      file:
      - database-service.patch
      field:
      - pods.spec.containers[1].env[2].name=MYSQL_DB
      spec:
      - kind: Service
        spec:
          ports:
            - protocol: TCP
              port: 82
              targetPort: 9376
              name: port-82
    mounts:
    - volumeName: database
      mountPath: /var/lib/mysql

[kadel]

@containscafeine Why do you need field? What it does? Shouldn't be file just enough?

[kadel]

More and more I'm thinking about this one thing worries me a bit.

We will merge something that gets generated from opencompose with something that user created. Creating patches for this will be hard, as a user will have to understand what primitives are generated and how they look like. But can't think of better solution right now :-(

[concaf]

Why do you need field? What it does? Shouldn't be file just enough?

@kadel - field should help when we simply want to change one field, so we can easily refer to it using how we refer to as YAML fields, and change it without writing a full blown indented YAML.

[kadel]

OpenCompose extensions

This is the way how to extend OpenCompose format to something that is not implemented in base OpenCompose language.

Extensions (files describing how to extend generated objects) describing which object should be extended/patched and how.

For describing how to patch object we can use Kubernetes Strategic Merge Patch

Example:

opencompose.yaml

version: 0.1-dev
services:
- name: helloworld
  containers:
  - image: tomaskral/nonroot-nginx
    ports:
    - port: 8080

extensions.yaml

# PATCH deployment/wordpress
spec:
    tempalte:
        spec:
            containers:
            - resources:
                requests:
                    memory: "64Mi"
                    cpu: "250m"
                limits:
                    memory: "128Mi"
                    cpu: "500m"

The first line in patch file is defining what object should be patched (Kind/name)

Extensions are passed to command-line tool.

opencompose convert -f opencompose.yml --patch extension.yaml

---

All this is just theory, I've been having some issues to actually test Strategic merge patching with kubectl patch :-(

[surajssd]

Kubernetes also allows you to extend pod spec on the fly now using something called PodPreset.

You can use a podpreset object to inject certain information into pods at creation time. This information can include secrets, volumes, volume mounts, and environment variables.

Injecting Information into Pods Using a PodPreset

[kadel]

OpenCompose tool should be able to combine multiple opencompose files. Example: I have OpenCompose file for some service (like db) with secrets defined. I have another OpenCompose file with my application that is using that service and needs secrets that are defined with that service. OpenCompose tool should be able to combine those two opencompose files and generate valid output.