Hi Martin, On Mon, Jun 11, 2018 at 5:56 PM, Martin Lucina <mar...@lucina.net> wrote:
> Hi Nikhil, > > On Monday, 11.06.2018 at 16:10, nikhil ap wrote: > > I'm not familiar with MirageOS. I need to look at how it works. > > Although, this implies that we need to change the tooling for every > > unikernel we support. > > That's correct. > > > For ex, MirageOS, IncludeOS, Rumprun etc. Also, whenever we need to add > > configuration parameters/resources > > to the manifest, we would have to change this everywhere to reflect this. > > Is it possible to have > > some kind of stand-alone tool which the other unikernels can trigger > during > > the configuration time > > to be able generate the binary with the manifest? > > Yes, obviously the goal would be to have easy to use tooling available to > assist the various guest unikernel build systems to generate the manifest. > Integrating it into the final unikernel binary should just be a case of > passing the resulting object to 'ld'. > > > > If we split the manifest and associated artefact, then this has several > > > disadvantages: > > > > > > 1) The user/operator now has to keep track of two files. Or we have to > ship > > > as a .tar/other container, in which case we may as well just embed the > > > manifest in the ELF binary. > > > > > > 2) The coupling is much looser, so the potential for messing things up > is > > > accordingly higher. > > > > > > If we combine the two in a single artefact, with the associated > build-time > > > runes on the libOS side being generated by the build system (i.e. the > > > developer does not create a manifest "manually") then these problems go > > > away. > > > > > > > I guess an advantage of using a separate configuration file would be that > > we > > can compile only the module that is required. > > I'm not sure what you mean. What selection of modules gets complied > in/enabled for a tender would be up to the operator of that tender to > determine as a policy decision. The tender would then, based on > interpreting the binary's manifest, determine whether or not it > "can/will/is allowed to" launch the (separately supplied) unikernel. > Ok. I had thought we would compile-in all the modules for the tender. You are suggesting that if the operator only requires the net module, he will configure the tender by running tender-configure net which will only compile-in the net module and will feed the unikernel image with the manifest to this tender. > > > > By the way, you mentioned JSON. JSON is absolutely unsuitable for this > > > purpose; given that the (untrusted) manifest needs to be interpreted by > > > e.g. a (trusted) tender, the format needs to be designed in a way that > > > > > .. a way that? Would like to know this ends :) > > ...that allows for secure deserialization of untrusted data? See here for > an (old) comparison of some formats: > https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-sbe.html > > Personally I'm very much in favour of minimalism, so there's also the > possibility of just inventing a custom binary format tailored to only the > information we need to store in the manifest. I don't yet know which > approach is best in the long term. > > Note that we should be able to version the manifest as a whole, so we could > start with a simple custom format and move to something more involved later > if there is a need. > > > > > I thought of Json because IncludeOS uses json to configure the > > resources and specify them to Qemu. > > > > An example: > > { > > "image": "test_router.img", > > "mem" : 320, > > "net" : [{"device" : "virtio"}, > > {"device" : "virtio"}], > > } > > > > So in order for us to be able to support IncludeOS we would have to have > > their > > build system (cmake) parse the json file and emit a tender binary with > the > > manifest. > > No, the manifest is part of the change to a run-time coupling with a > tender. I.e. the IncludeOS build system only has to produce a unikernel > with a manifest, not a tender binary. Those would be supplied separately by > downloading and building the "new" Solo5. > Ok, we could provide the tooling to create such a manifest. Also, I was thinking once you are done with the re-naming, we could have a call to discuss and conclude on a design? What can be done for an initial phase? What tooling can we provide taking into the account the unikernels we support, etc. Others could join as well and at the end we should be able to document the design. Thoughts? Another thing is since this is mostly a configuration based change, I can still come up with a proposal for multi-nic assuming we've loaded the manifest and determined how many NICs we need. I can do a write-up on what are the changes that are required for the tender-binding-application. Is this fine? I don't think there should be any conflicts with the configuration changes with multi-nic feature. I may be wrong. Let me know. > > -mato > -- Regards, Nikhil
