Re: [MirageOS-devel] Testing the next release of mirage

[Gareth Rushgrove <gareth@xxxxxxxxxxxxxxxxx>]

On 11 November 2015 at 16:14, Drup <drupyog+caml@xxxxxxxx> wrote:
> @mindy, jeremy, gareth: Sweet, don't hesitate to ask questions !
>
> For the json export, that should be quite easy, all those informations are
> already gathered in two data structures ("Info.t" and the graph).
>
> You won't be able to export what you call the "pattern" easily though,
> because the parser/printers are captured by closures, which are opaque. We
> could change that, but I'm a bit wary of having multiple descriptions of the
> same thing. Also, it can check more complicated things than "matches a
> regexp" which you would not be able to capture in json.
>

:) Yup, absolutely. Providing some type information would be great,
but I'd definitely leave it until a v2 or what not. Providing the
basics of the JSON schema for v1 would be great.

Gareth

> Is there a standardized way to describe graphs (or at least DAGs) in json ?
>
>
> Le 11/11/2015 10:46, Gareth Rushgrove a Ãcrit :
>>
>> On 11 November 2015 at 01:55, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>
>> 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
>>>>> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
>>>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>>>>
>>>>
>>>>
>>>> --
>>>> Gareth Rushgrove
>>>> @garethr
>>>>
>>>> devopsweekly.com
>>>> morethanseven.net
>>>> garethrushgrove.com
>>
>>
>>
>
>
>
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel



-- 
Gareth Rushgrove
@garethr

devopsweekly.com
morethanseven.net
garethrushgrove.com

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel