Skip to content
This repository has been archived by the owner on Nov 15, 2022. It is now read-only.

Top level name is not propagated to single service #33

Closed
kadel opened this issue Jun 19, 2017 · 1 comment
Closed

Top level name is not propagated to single service #33

kadel opened this issue Jun 19, 2017 · 1 comment

Comments

@kadel
Copy link
Member

kadel commented Jun 19, 2017

name: test

containers:
 - image: quay.io/tomkral/nonroot-nginx

services:
  - ports:
    - port: 8080

the result is invalid service:

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: test
spec:
  ports:
  - port: 8080
    targetPort: 0
  selector:
    app: test
status:
  loadBalancer: {}

what I expected is Service named 'test'

@kadel kadel added the kind/bug label Jun 19, 2017
@kadel
Copy link
Member Author

kadel commented Jun 19, 2017

same for persistentVolumes
Basically everytime there is a name required and only single instance is defined, top level name should be used

@concaf concaf assigned concaf and unassigned concaf Jun 19, 2017
concaf added a commit to concaf/kedge that referenced this issue Jun 19, 2017
If only one root level service is defined, then the resulting
Kubernetes service will have the name populated as the root level
name field.

The same is being done in case of root level persistent volume.

Also, tests have been added for this behavior.

Fixes kedgeproject#33
concaf added a commit to concaf/kedge that referenced this issue Jun 20, 2017
If only one root level service is defined, then the resulting
Kubernetes service will have the name populated as the root level
name field.

The same is being done in case of root level persistent volume.

Also, tests have been added for this behavior.

Fixes kedgeproject#33
concaf added a commit to concaf/kedge that referenced this issue Jun 21, 2017
If only one root level service is defined, then the resulting
Kubernetes service will have the name populated as the root level
name field.

The same is being done in case of root level persistent volume.

Also, tests have been added for this behavior.

Fixes kedgeproject#33
concaf added a commit to concaf/kedge that referenced this issue Jun 21, 2017
If only one root level service is defined, then the resulting
Kubernetes service will have the name populated as the root level
name field.

The same is being done in case of root level persistent volume.

Also, tests have been added for this behavior.

Fixes kedgeproject#33
concaf added a commit to concaf/kedge that referenced this issue Jun 21, 2017
If only one root level service is defined, then the resulting
Kubernetes service will have the name populated as the root level
name field.

The same is being done in case of root level persistent volume.

Also, tests have been added for this behavior.

Fixes kedgeproject#33
concaf added a commit to concaf/kedge that referenced this issue Jun 22, 2017
If only one root level service is defined, then the resulting
Kubernetes service will have the name populated as the root level
name field.

The same is being done in case of root level persistent volume.

Also, tests have been added for this behavior.

Fixes kedgeproject#33
@kadel kadel closed this as completed in b35245d Jun 23, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants