Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change ConfigMap's data field to weakly-typed JSON #74

Open
ari-becker opened this issue Jul 30, 2019 · 1 comment
Open

Change ConfigMap's data field to weakly-typed JSON #74

ari-becker opened this issue Jul 30, 2019 · 1 comment

Comments

@ari-becker
Copy link
Collaborator

Currently ConfigMap's data field's type is List { mapKey : Text , mapValue : Text }. This prevents ConfigMap from hosting nested object structures, which the domain permits.

Can we change the type to the new weakly-typed JSON.object?

@ari-becker ari-becker changed the title Change ConfigMap to weakly-typed JSON Change ConfigMap's data field to weakly-typed JSON Jul 30, 2019
@arianvp
Copy link
Member

arianvp commented Jul 30, 2019

Yes please! that sounds like a sane thing to do.

The more general feature request is:

map anything that has "type":" object" but lacks a "properties"
e.g. configmap is:

    "io.k8s.api.core.v1.ConfigMap": {
      "description": "ConfigMap holds configuration data for pods to consume.",
      "properties": {
        "apiVersion": {
          "description": "APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#resources",
          "type": "string"
        },
        "binaryData": {
          "additionalProperties": {
            "format": "byte",
            "type": "string"
          },
          "description": "BinaryData contains the binary data. Each key must consist of alphanumeric characters, '-', '_' or '.'. BinaryData can contain byte sequences that are not in the UTF-8 range. The keys stored in BinaryData must not overlap with the ones in the Data field, this is enforced during validation process. Using this field will require 1.10+ apiserver and kubelet.",
          "type": "object"
        },
        "data": {
          "additionalProperties": {
            "type": "string"
          },
          "description": "Data contains the configuration data. Each key must consist of alphanumeric characters, '-', '_' or '.'. Values with non-UTF-8 byte sequences must use the BinaryData field. The keys stored in Data must not overlap with the keys in the BinaryData field, this is enforced during validation process.",
          "type": "object"
        },
        "kind": {
          "description": "Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds",
          "type": "string"
        },
        "metadata": {
          "$ref": "#/definitions/io.k8s.apimachinery.pkg.apis.meta.v1.ObjectMeta",
          "description": "Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata"
        }
      },
      "type": "object",
      "x-kubernetes-group-version-kind": [
        {
          "group": "",
          "kind": "ConfigMap",
          "version": "v1"
        }
      ]
    },

Here additionalProperties forces the keys to be of type string (https://swagger.io/docs/specification/data-models/dictionaries/)

So, the most type-safe we can do here is:

List ({ mapKey : String,  mapValue: JSON.object})

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants