Re: [MirageOS-devel] command line arguments for unikernels

[Nicolas Ojeda Bar <no263@xxxxxxxxxxxxxxx>]

Hi list,

I have a working version of the `mirage configure` tool that allows the
individual CONFIGURABLEs to declare a list of parameter that it uses.
The set of all the
parameters used by the unikernel can then be set using Cmdliner terms and
they are shown in `mirage configure --help`.

Example:

The IPV4: CONFIGURABLE declares parameters "ip", "netmask", "gateways" then
one can set them as follows:

$ mirage configure --ip 10.0.0.2 --netmask 255.255.255.0 --gateways=10.0.0.1

It is also possible to use environment variables of the same name and
it will be possible to override the parameter values at run-time so
that one does not need to recompile the unikernel each time (this
might make the unikernel depend on Cmdliner, though).

I have a question regarding the best way to handle parameter names.
Obviously parameter names must be unique. But if one instantiates a
CONFIGURABLE more than once then those CONFIGURABLEs may be
instantiating parameters of the same name. For example one can imagine
instantiating IPV4 twice and then both of them will have a parameters
"ip", "netmask", etc.

One can of course, make the names unique by combining the name of the
parameter with the name of the CONFIGURABLE (currently
semi-algorithmically generated to keep them unique), but this does not
seem very user friendly.

Thoughts ?

Cheers,
Nicolas

PS: For those that want to look at the code (which is very rough)
and/or try it out, you can pin

opam pin add mirage https://github.com/nojb/mirage#better-params

and you can try it out by cloning
https://github.com/nojb/mirage-better-params-ex and running
`mirage configure --help`.

On Sun, Nov 30, 2014 at 10:49 PM, Richard Mortier
<Richard.Mortier@xxxxxxxxxxxxxxxx> wrote:
>
> On 30 Nov 2014, at 22:40, Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx> wrote:
>
>>
>>
>> Le dimanche, 30 novembre 2014 Ã 23:03, Richard Mortier a Ãcrit :
>>
>>> re 1-- i'm quite (indeed, very) happy to have this available to me, though 
>>> i don't think i'd agree with quite the strength of your statements about 
>>> exposing configuration options that aren't used ("misleading", "no point"). 
>>> i don't know the assemblage configuration format at all, but if there are 
>>> (as seems common with other formats) options that can override or interact 
>>> with each other, then seeing whatever are the default values provided for 
>>> those options when they're not explicitly used is rather useful. 
>>> (particularly if those defaults ever change.)
>>
>> Anything that eventually has an impact (either directly or indirectly) will 
>> be documented. Dependencies among configuration keys are tracked.
>
> ok, that sounds fair.
>
>>> re 2-- this seems more of a workflow thing (and remember, the user is 
>>> always right ;) -- compare the utility of "man bash" to "man make" when 
>>> writing shell scripts vs makefiles. (at least on all systems i've used 
>>> recently.) having to get hold of a browser, google for gnumake, find the 
>>> right gnu.org (http://gnu.org) page and then search through it is a royal 
>>> pain (even if the bash man page is hardly an exemplar of clarity or 
>>> organisation).
>> In this case since you are writing in OCaml against an OCaml API so you are 
>> less likely to look for information in a man page than in ocamldoc generated 
>> documentation (though strictly speaking ocamldoc has a, little used, man 
>> page backend). And no the user is not always right, you should certainly 
>> never blame it for its actions but that doesn't mean that he is always 
>> right, in fact he is often wrong especially in what he thinks he wants, 
>> that's the reason why we have designers.
>
> this is a philosophical discussion best had over a pint :)
> (happy for designers to design tools; but my workflows are -- generally -- my 
> own...)
>
> --
> Cheers,
>
> R.
>
> [ This address fails on Dec31. Use richard.mortier@xxxxxxxxxxxx subsequently. 
> ]
>
>
>

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