[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • From: Drup <drupyog+caml@xxxxxxxx>
  • Date: Wed, 11 Nov 2015 17:14:24 +0100
  • Cc: mirageos-devel <mirageos-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 11 Nov 2015 16:15:53 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=subject:references:cc:from:message-id:date:user-agent:mime-version:in-reply-to:content-type; b=IZnxUjRu7MkMRXYoCFSGu9+NR+i6GGOXuK9VWZ69P+7F7KTy6K7L7rSNgpLC/E0CNHnFSwa+7KpI Jj12Q2XH4YWM2LW9vfmB5O9C7cQFOML7YoWvSG17xtp3UbU6vPrk
  • List-id: Developer list for MirageOS <mirageos-devel.lists.xenproject.org>

@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

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)

       --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": "" } 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": "", "description": "The gateway
of the unikernel."},
     "ip": { "default": "", "description": "The IP address of
the unikernel."},
     "netmask": { "default": "", "description": "The
netmask of the unikernel."},
     "network": { "default": "tap0", "description": "The network
interface listened by the unikernel."}


Eventually (or even initially) I'd love to see that as a json schema.

   "title": "Network",
   "type": "object",
   "properties": {
     "gateways": {
       "description": "The gateway of the unikernel."
       "type": "string",
       "default": "",
       "pattern": "^(?:[0-9]{1,3}\.){3}[0-9]{1,3}$"
     "ip": {
       "description": "The IP address of the unikernel."
       "type": "string",
       "default": "",
       "pattern": "^(?:[0-9]{1,3}\.){3}[0-9]{1,3}$"
     "netmask": {
       "description": "The netmask of the unikernel."
       "type": "string",
       "default": "",
       "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"]


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.





Thomas, on behalf on the merry MirageOS crew

MirageOS-devel mailing list

Gareth Rushgrove


MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.