spinnaker
spinnaker copied to clipboard
'List' based Kubernetes Manifests Not Supported
Issue Summary:
Missing required field 'metadata' on manifest reported for k8s '*List' manifests.
Cloud Provider(s):
GKE (Kubernetes v2)
Environment:
Any
Feature Area:
Pipelines
Description:
Using a helm
chart which produces resources such as "ConfigMapList", "RoleList". "RoleBindingList" etc and try to deploy baked images will result in "Missing required field 'metadata' on manifest" error which is not part of the Spec for these resources.
Steps to Reproduce:
Try to deploy a baked chart with these resources. i.e.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBindingList
items:
- apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: prometheus-operator-prometheus
labels:
app: prometheus-operator-prometheus
...
Additional Details:
https://github.com/spinnaker/spinnaker/issues/4534 is the same issue but it's closed as a workaround was performed. This doesn't address the issue that Spinnaker cannot determine these resources do not require metadata fields.
Please delete the instructions below this line prior to submitting
Instructions:
- An issue is not a place to ask questions. Please use Slack or Stack Overflow.
- Before you open an issue, please check if a similar issue already exists or has been closed before.
- Make sure you have read through the Spinnaker FAQ and Halyard FAQ to provide as much information as possible.
Descriptions:
- Issue Summary: A brief description of what you're seeing.
- Cloud Provider: AWS, GCP, Kubernetes, Azure, Cloud Foundry, etc. Please assign a label from the right so your issue can be properly sorted.
- Environment: As much information about your Spinnaker environment and configuration that might be relevant to the issue. For example: "I am running Spinnaker using the Amazon images to deploy into AWS and GCP."
- Feature Area: Notifications, Pipelines, UI, Jenkins, etc. Please assign a label from the right so your issue can be properly sorted.
- Description: The behavior you expect to see, and the actual behavior.
- Steps to reproduce: Ideally, an isolated way to reproduce the behavior (example: GitHub repository with code isolated to the issue that anyone can clone to observe the problem). If not possible, as much information as possible to see this behavior.
- Additional Details: Additional information such as screenshots and exception logs.
What version of spinnaker are you using? Perhaps 1.15.x fixes this via https://github.com/spinnaker/clouddriver/pull/3716?
Version 1.16.4
Also that commit is for "List" not "*List" as the failure is for those in the OP.
Aaah, thanks for pointing that out.
This issue hasn't been updated in 45 days, so we are tagging it as 'stale'. If you want to remove this label, comment:
@spinnakerbot remove-label stale
@spinnakerbot remove-label stale
We have just hit this on 1.17.6 with a NetworkPolicy
list:
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicyList
items:
- apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
labels:
<snip>
We also have some Endpoint
lists.
We are going to try change some to kind: List
per this PR: https://github.com/spinnaker/clouddriver/pull/3716.
It looks like Spinnaker treats metadata
as a required field in Kubernetes v2 here: https://github.com/spinnaker/clouddriver/blob/master/clouddriver-kubernetes-v2/src/main/java/com/netflix/spinnaker/clouddriver/kubernetes/v2/description/manifest/KubernetesManifest.java#L102
Kubernetes spec says for Lists
:
Every list or simple kind SHOULD have the following metadata https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#lists-and-simple-kinds
Contrast with Objects
:
Every object kind MUST have the following metadata https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#metadata
We have been applying a *List
without a metadata
field via kubectl apply -f mylist.yaml
for some time and are trying to move this job into Spinnaker.
This issue hasn't been updated in 45 days, so we are tagging it as 'stale'. If you want to remove this label, comment:
@spinnakerbot remove-label stale
@spinnakerbot remove-label stale
This issue hasn't been updated in 45 days, so we are tagging it as 'stale'. If you want to remove this label, comment:
@spinnakerbot remove-label stale
@spinnakerbot remove-label stale
This issue hasn't been updated in 45 days, so we are tagging it as 'stale'. If you want to remove this label, comment:
@spinnakerbot remove-label stale
@spinnakerbot remove-label stale
This issue hasn't been updated in 45 days, so we are tagging it as 'stale'. If you want to remove this label, comment:
@spinnakerbot remove-label stale
@spinnakerbot remove-label stale
This issue hasn't been updated in 45 days, so we are tagging it as 'stale'. If you want to remove this label, comment:
@spinnakerbot remove-label stale
@spinnakerbot remove-label stale
This issue hasn't been updated in 45 days, so we are tagging it as 'stale'. If you want to remove this label, comment:
@spinnakerbot remove-label stale
@spinnakerbot remove-label stale
This issue hasn't been updated in 46 days, so we are tagging it as 'stale'. If you want to remove this label, comment:
@spinnakerbot remove-label stale
@spinnakerbot remove-label stale
This issue hasn't been updated in 45 days, so we are tagging it as 'stale'. If you want to remove this label, comment:
@spinnakerbot remove-label stale
@spinnakerbot remove-label stale
This issue hasn't been updated in 45 days, so we are tagging it as 'stale'. If you want to remove this label, comment:
@spinnakerbot remove-label stale
@spinnakerbot remove-label stale
This issue hasn't been updated in 45 days, so we are tagging it as 'stale'. If you want to remove this label, comment:
@spinnakerbot remove-label stale
@spinnakerbot remove-label stale
This issue hasn't been updated in 45 days, so we are tagging it as 'stale'. If you want to remove this label, comment:
@spinnakerbot remove-label stale
@spinnakerbot remove-label stale