ConfigMap page, if there's no JsonSchema should we create a form anyway for each data field by default?

[jstrachan]

I noticed a few ConfigMap's don't have any JSON Schema annotation (e.g. exposecontroller) - it might be nice to just make a form for each value?

[gashcrumb]

That strikes me as being something that could be easily breakable. Why not
just make json schema for stuff that we want forms for?

On Sep 7, 2016 1:27 AM, "James Strachan" [email protected] wrote:

I noticed a few ConfigMap's don't have any JSON Schema annotation (e.g.
exposecontroller) - it might be nice to just make a form for each value?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#213, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AAVdrKlDkqQdINu0IRRT3DBvT9uVxYrSks5qnks4gaJpZM4J2i_H
.

[jstrachan]

data is a String key and a String value. I'm guessing lots of users are gonna create ConfigMaps and not get around to adding a JSON Schema.

e.g. we've got one already - the exposecontroller ;).

I figured if there's no actual validation, default value or custom type information; is it really required?

I wasn't sure how assuming the values are strings would be easily breakable?

[gashcrumb]

Yeah, my concern is mainly we'll then see issues like 'the order of my
config items isn't right' or 'this value is a string but I want a number
field', or 'I've embedded some json in the string, can I have a text
field', the answer to all of those is create a json schema to fix it, but
then, why not just use a json schema in the first place, you get a nicer
form anyways and the code's in place now to support that :-)

On Wed, Sep 7, 2016 at 6:57 AM, James Strachan [email protected]
wrote:

data is a String key and a String value. I'm guessing lots of users are
gonna create ConfigMaps and not get around to adding a JSON Schema.

e.g. we've got one already - the exposecontroller ;).

I figured if there's no actual validation, default value or custom type
information; is it really required?

I wasn't sure how assuming the values are strings would be easily
breakable?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#213 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAVdrLIo-fCHd0KkABWpEJ_KVDFaF0Wcks5qnpiRgaJpZM4J2i_H
.

[jstrachan]

I agree that we should always try to add a json schema everywhere. I'll try fix the f-m-p to always add one for apps fabric8 generate btw!

The main thing I was thinking of was for users who just hack YAML by hand; embedding JSON Schema docs inside YAML isn't fun and if folks don't mind about order or customising the form at all do we care? e.g. if its just a couple of strings; forcing users to edit YAML due to lack of json schema doesn't sound awesome.

BTW I can imagine another common ConfigMap case (e.g. Spring Boot folks storing files in the ConfigMap) would be using mostly 1 entry mapping to a file like this one:
https://github.com/fabric8io/traefik/blob/master/src/main/fabric8/cm.yml#L4

I wonder if we need a simple annotation to denote an entry as being a 'file' so that its basically a syntax highlighted text editor in its own tab (which usually there's only 1). This is more as an alternative to the JSON Schema form stuff.

e.g. a Spring Boot config map could be something like:

metadata:
  name: my-spring-config
data:
  config.properties |
    foo.bar = 123
    whatnot.cheese = zzz

or

metadata:
  name: my-spring-config
data:
  config.yml |
    foo:
      cheese:
        name: Whoo
     blah: 123

Then for entries which look like files (maybe we need an annotation to list file entries?) we could generate tabs for each file with a little text area and syntax highlighted based on the extension name?

Then in the above examples the UI would show...

foo.bar = 123
whatnot.cheese = zzz

or this:

foo:
  cheese:
    name: Whoo
  blah: 123

i.e. just the application's config file (and there's usually only 1 of them) rather than all the kubernetes resource wrapper stuff

[jstrachan]

I raised a separate issue of supporting YAML encoded json schema which will help folks hand-craft JSON Schema into ConfigMap files.
hawtio/hawtio-kubernetes#131

I still like the 'generated form with no fancy validation' option if there's no json schema annotation though! :) Reminds me a bit of customising hawti-forms; generate it from the data you have and only require markup if you wanna change things (e.g. hide fields, change type of some fields, force a few fields to be shown first etc)

[gashcrumb]

So couple limitations that I've spotted that'd need work before I'd really be comfortable doing this:

1. Can't use . in property names, this gets interpreted in expressions as a child item of a javascript object
2. Can't use - in property names, angularjs seems to interpret this in some funny way which throws lots of errors
3. You can totally just stick objects into the 'data' field there, we do it in fabric8-environments
4. We've no 'textarea' form control, so you can't really embed .properties files and the like in a config map and make a nice form around it currently.