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

[Drup <drupyog+caml@xxxxxxxx>]

@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.
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