On 11 November 2015 at 01:55, Thomas Gazagnaire <[email protected]> wrote:
>> 2. I'd love to be able to get at the configuration options as data, in
>> an ideal world JSON, probably something like a generated JSON schema
>> (http://json-schema.org/)
>>
>> My rationale for the last part is integration with other tools.
>> Personally I'd love to be able to autogenerate Puppet types for a
>> resulting unikernel but any form of runtime configuration integration
>> would benefit from a machine readable format for the configuration.
>>
>> This might look something like this. (--help=json felt wrong somehow)
>>
>> OPTIONS
>>       --help[=FMT] (default=pager)
>>           Show this help in format FMT (pager, plain or groff).
>>       --parameters[=FMT] (default=json)
>>           List available unikernel parameters in a machine readable
>> format (json).
>
> That's a very good idea and relatively easy to do, depending on which kind of 
> syntax you want the parameter to be in. If that just strings, e.g. { "key": 
> "ip", "value": "10.0.0.1" } that's easy. If you want the values to be JSON 
> objects it'd be a bit harder / a bit more annoying / a bigger patch to 
> functoria. Do you already have a syntax in mind?
>

This is a bit off the top of my head but for achieving the basics:

{
  version: 0.1,
  parameters: {
    "gateways": { "default": "10.0.0.1", "description": "The gateway
of the unikernel."},
    "ip": { "default": "10.0.0.2", "description": "The IP address of
the unikernel."},
    "netmask": { "default": "255.255.255.255", "description": "The
netmask of the unikernel."},
    "network": { "default": "tap0", "description": "The network
interface listened by the unikernel."}
  }
}

https://gist.github.com/garethr/714c94bfc85e627b83b1#file-plain-json

Eventually (or even initially) I'd love to see that as a json schema.
http://json-schema.org/

{
  "title": "Network",
  "type": "object",
  "properties": {
    "gateways": {
      "description": "The gateway of the unikernel."
      "type": "string",
      "default": "10.0.0.1",
      "pattern": "^(?:[0-9]{1,3}\.){3}[0-9]{1,3}$"
    },
    "ip": {
      "description": "The IP address of the unikernel."
      "type": "string",
      "default": "10.0.0.2",
      "pattern": "^(?:[0-9]{1,3}\.){3}[0-9]{1,3}$"
    },
    "netmask": {
      "description": "The netmask of the unikernel."
      "type": "string",
      "default": "255.255.255.255",
      "pattern": "^(?:[0-9]{1,3}\.){3}[0-9]{1,3}$"
    },
    "network": {
      "description": "The network interface listened by the unikernel."
      "type": "string",
     "default": "tap0"
    }
  },
  "required": ["ip"]
}

https://gist.github.com/garethr/714c94bfc85e627b83b1#file-schema-variant-json

This would allow you to build on the above with support for type and
boundary checking and things like required parameters - all useful for
anyone integrating.

JSON like the above would at least allow people to start experimenting
with integrations. Maybe you want to put it behind a feature flag or
mark it experimental. The problem with APIs like this is they can be
formalised by virtue of popular integrations. The advantage of having
something now is that people can start hacking on those integrations.

I'd be happy to test this out or to catch up in Cambridge to hack
around on it a bit if useful.

Gareth

> Thomas
>
>
>>
>> Cheers
>>
>> Gareth
>>
>>> Enjoy,
>>> Thomas, on behalf on the merry MirageOS crew
>>>
>>>
>>> _______________________________________________
>>> MirageOS-devel mailing list
>>> [email protected]
>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>>
>>
>>
>> --
>> Gareth Rushgrove
>> @garethr
>>
>> devopsweekly.com
>> morethanseven.net
>> garethrushgrove.com
>



-- 
Gareth Rushgrove
@garethr

devopsweekly.com
morethanseven.net
garethrushgrove.com

_______________________________________________
MirageOS-devel mailing list
[email protected]
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

Reply via email to