Support JSON schema definitions and references

[petar-cvit]

Is your feature request related to a problem? Please describe. Cyclops engine for rendering forms does not support JSON schema definitions and references, but those are often used to make creating schemas simpler.

More information on JSON schema docs

[yuvarajrece]

Can I work on this?

[cwrau]

We've run into this as well trying to deploy https://github.com/teutonet/teutonet-helm-charts/tree/main/charts/t8s-cluster, it fails with the following;

helm.Property.Properties: helm.Property.Properties: helm.Property.Type: ReadString: expects " or n, but found [, error found in #10 byte of ...| "type": [
         |..., bigger context ...|
        "availabilityZone": {
          "type": [
            "null",
            "string"
        |...
readObjectStart: expect { or n, but found 4, error found in #1 byte of ...|404 page no|..., bigger context ...|404 page not found
|...

[petar-cvit]

Will assign this to myself and post updates here

[petar-cvit]

@cwrau I looked into your chart, and the error you are getting is because the type of a property is defined as an array, and currently Cyclops supports only a single string as type. That's because Cyclops needs to know how to render a field, and if there are multiple types, we can't be sure what type to render.

Also, your chart has a private dependency. We have a solution for fetching private charts but still need to publish the documentation. Let me know if this is a blocker for you, and we can give docs a higher priority.

[cwrau]

@cwrau I looked into your chart, and the error you are getting is because the type of a property is defined as an array, and currently Cyclops supports only a single string as type. That's because Cyclops needs to know how to render a field, and if there are multiple types, we can't be sure what type to render.

Oh, ok, how do you handle types that could be multiple? Like int / string for resources for example.

But I guess for some of the fields we can remove the default null in the values.

Also, your chart has a private dependency.

Do you mean the image? 🤔

[petar-cvit]

Oh, ok, how do you handle types that could be multiple? Like int / string for resources for example.

Unfortunately, we currently don't. If you put ["string", "object"], which would you expect to render on the UI? If needed, we can implement the logic for it and document it so users can have a clear image of what to expect.

But I guess for some of the fields we can remove the default null in the values.

Yeah, this should solve the issue :)

Also, your chart has a private dependency.

Sorry my bad it's not private, but Im getting 404 when fetching this dependency. Could you check if its available?

[cwrau]

Oh, ok, how do you handle types that could be multiple? Like int / string for resources for example.

Unfortunately, we currently don't. If you put ["string", "object"], which would you expect to render on the UI? If needed, we can implement the logic for it and document it so users can have a clear image of what to expect.

Maybe a kind of select? So the user can choose between the types? How did you implement oneOf and such? Kinda the same way

Also, your chart has a private dependency.

Sorry my bad it's not private, but Im getting 404 when fetching this dependency. Could you check if its available?

I tried that, inside a container to be sure; podman run --rm -i -t ananace/skopeo inspect --raw docker://ghcr.io/teutonet/teutonet-helm-charts/common:1.0.0

[petar-cvit]

Maybe a kind of select? So the user can choose between the types? How did you implement oneOf and such? Kinda the same way We could add a UI component that would let you decide which type it is. Will try to draw something up, but if you have any ideas let me know

I tried that, inside a container to be sure Will give it another shot and let you know

[petar-cvit]

Hey @cwrau, found the issue for the common chart I mentioned. It was on our end and how we authenticate fetch OCI charts. When requesting a token from dockerhub, we get an object that contains the token under the access_token, but ghcr (were your chart is stored) returns it under the token key.

In the meantime we also fixed supported fields in json schema that have the type ["string", "null"] so I was able to import the teutonet helm chart. Will open a proper PR for it.