Labels support

[tnozicka]

OpenCompose file should allow user to specify annotations and labels on his objects.

[concaf]

So,

• Labels are for identifying metadata and for identifying attributes of objects that are meaningful and relevant to users, but which do not directly imply semantics to the core system.
• Annotations are arbitrary non-identifying metadata which may be large, may be structured or unstructured, may include characters not permitted by labels, etc. Such information would not be used for object selection and therefore doesn’t belong in labels.

Both of these serve a different purpose.
IMO, we should implement labels in OpenCompose first, I don't see many uses of annotations right now, but I could be totally wrong.
How about the first step of implementing the top level directive of labels, and define rules for the same?
@surajssd @tnozicka @kadel

References:

• https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
• https://kubernetes.io/docs/user-guide/annotations/

[kadel]

Agreed, lets start with labels.

What do you mean by 'top level directive'?

[concaf]

@kadel yep, sorry about that, not a 'top level directive', but something like -

version: "0.1-dev"

services:
   name: foobar
   containers:
   - image: foo/bar:tag
     env:
     - foo=bar
     labels:
       "status": "shipit"
     command: ["/bin/foobar"]
     args: 
     - "-f"
     - "/tmp/foobar"
     ports:
     - port: 8080:80

[surajssd]

With top level what I understood is a label that is declared once and then that is applied to everything opencompose tool generates, as a way to identify this was auto-generated with opencompose.

[surajssd]

I am assuming that this issue is only addressing labels and am proposing something for that.

I noticed one thing in opencompose that we want user to do things in only one way, but how feasible is that?

What I mean here is that we ask user to mention labels in each and every service but what happens when a user wants to do it for the entire project? shouldnt we have root level labels?

We could have a root level label which is applied to each and everything we create in the project like deployments, pvc, etc.

This is similar to the what auto-generated artifacts in openshift look like.

So what I think here is that we should have few things that are root level and service level both. And it should be done in such a way that we don't need to implement it twice basically reuse the stuff.

[kadel]

OK, Lets focus on label right now.
We are talking about opencompose syntax, can you show on example how labels should look like?

[concaf]

@kadel @surajssd -

I agree, we should have both service and root level labels. Let's implement the service level labels first, and then the root level labels. We can abstract the methods accordingly.

[concaf]

Moreover, after discussions with @kadel and @surajssd, I don't think it makes sense to have container level labels, which is

version: 0.1-dev
services:
- name: helloworld
  containers:
  - image: tomaskral/nonroot-nginx
    ports:
    - port: 8080
    labels:
      status: shipit
      zone: public

This does not make sense because all the containers for that service will be in the same pod and it will not make sense to apply labels on a pod level, the labels should trickle down from deployment and service level.

---

So, what I am proposing for service level labels is something like this -

version: 0.1-dev
services:
- name: helloworld
  containers:
  - image: tomaskral/nonroot-nginx
    ports:
    - port: 8080
  labels:
    status: shipit
    zone: public

I have a WIP draft PR for this at #82, @kadel @tnozicka @surajssd PTAL for the approach and design.

TIA

[pradeepto]

@tnozicka @kadel @surajssd Can we please have a look at the initial stab from @containscafeine ? He can proceed with further development. Thanks.

[kadel]

Proposed syntax looks good to me.

[concaf]

@kadel how does #82 look?

[kadel]

@kadel how does #82 look?

don't know, haven't seen it yet 😇

[tnozicka]

syntax lgtm

[brainstorm]

@containscafeine, sorry if this is not the place to ask this question but I was taking a look at the issues and you mentioned that "Labels are for identifying metadata and for identifying attributes of objects that are meaningful and relevant to users, but which do not directly imply semantics to the core system."

Where can I go to if I want the semantic labels? Especifically Kubernetes ExternalIPs?

Context: I came to test out opencompose since I needed a way to assign an already existing domain/AWS Elastic IP to a service, which I tried to achieve with kompose.io before @kadel kindly redirected me here instead.

In other words, I have an existing AWS Elastic IP I do not want to change and I want OpenCompose to instantiate my services pointing to that EIP via a mechanism similar to kompose's service labels.

[kadel]

Hi @brainstorm,
thank you for you input!

In Kompose we had to use labels to add new stuff to file.
But here we have our own file spec, so we can add proper support for things like Service types and also ExternalIPs.

I've created new issue regarding ExternalIPs - #101
We can discuss design and implementation of this feature there.