Re: [MirageOS-devel] Really fascinating

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 17 Oct 2014, at 11:08, Brian Brietzke <bbrietzke@xxxxxxxxx> wrote:

Thank you for the reply. 

No problem -- please keep the list CCed.  It's also often better to create a separate thread for different questions to keep track of things.  "Really fascinating" is not a useful mailing list subject ;-)

I created https://github.com/mirage/mirage-skeleton/issues/53 for the issues that I am seeing with mirage-skeleton.

With regard to the configuration question: Imagine if you wanted to build an personalized email client that talks to different providers.  One person may use only gmail, while another would use both gmail and hotmail.  When deploy the xen image, each person will have their own personalized URI that they will talk to.

Prior to actually creating the image, would you build a personalized config.ml with personalized oauth keys ( for instance ) or other tokens specific to the image that your are building or is there another way to handle that situation?  I know it's possible to customize the config.xl ( for MAC or IP address ), so you would follow a similar idea for the application image specific things?

Another example would be a generic worker process that handles messages from an AMPQ server.  You will have a different AMQP server in production and a different one in dev/QA.  How would you handle the differences in configuration, while keeping the application logic the same?

You would just run different config.ml logic.  If the key in question is genuinely dynamic, you can just make the unikernel do a dynamic lookup so the config stays the same.  For example, see the xen/ subdirectory in mirage-skeleton for a website that looks up its IP address from XenStore, so it can have the same config.ml even if it doesnt do DHCP.

As for cohttp, are there an worked examples of having parameterized resource URIs?

Not sure -- Thomas (Leonard) may have one as he worked on his blog.

Just thinking out loud, has anyone tried loading an image onto a Raspberry PI?  I have one at home that I may try a quick test on just for giggles.

Sure, it works fine in Unix mode. 

-anil

Thank you for the help

On Fri, Oct 17, 2014 at 2:20 AM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:

On 16 Oct 2014, at 11:10, Brian Brietzke <bbrietzke@xxxxxxxxx> wrote:

I was told about the project from a friend and I must say that I agree with him: wow!  I'm truly impressed with what is going on and the potential of what is happening.  Just, wow.

I would love to being exploring some of these ideas and concepts, along with learning OCaml, so I've picked a few books, setup a sandbox that I can play with ( both Xen and dev side ), but have run into some things that I would like to get a little clarification on.

Forgive me if this is the wrong place to ask these questions.  If you will let me know the correct place, I'll send them there.

I notice that both the Xen page and the open mirage site says that 2.0 is available, but I can only see 1.2 in the OPAM repositories that are installed by default.  Is there a different repository that I should be connecting to in order to get the lastest and greatest?

We're just about to release the 2.0 series as a stable branch; in the meanwhile, there's an opam remote:

opam remote add mirage git://github.com/mirage/mirage-dev

that will get you the mirage 2.0 series of repositories.  There may be some teething troubles in the next couple of days as we rearrange things for release into stable OPAM, but it should settle down quickly.

One of the easier scenario's for bringing these ideas into my workplace is setting a small REST or REST/SPA application as a proof of concept ( our CTO loves POCs ), but I don't find much in the way of documentation.  The article at http://roscidus.com/blog/blog/2014/07/28/my-first-unikernel/, which is incredibly helpful by the way, only shows how to handle requests with non-parameterized URLs.  Using cohttp, can we do parameterized URLs such as /resource/{id} or /blog/{articleId}/comments?

Yes; that's all independent of Mirage - the Cohttp library can do that sort of thing.  It's often easier to prototype the web logic using Cohttp_lwt_unix and then swap the same code over to Cohttp_mirage.

Using the https://github.com/mirage/mirage-skeleton as a point of exploration, the static_website fails to build with an error in the config.ml on line 41 ( conduit_direct ).  Is there a package missing or something else that will resolve the build failure? Or is it related to having the 1.2 packages instead of the 2.0 packages?

If you do have a build failure, we'd appreciate seeing the build logs, as it's hard to answer the question without seeing more details.  You can file them on https://github.com/mirage/mirage/issues

How do you handle configuration?  For instance, you build an application that generates one xen image per person, would you copy over the specific user information prior to the build, or is there a better way?  I can see that https://github.com/MagnusS/jitsu would be the way to start the application on demand and also clean it up when it is no longer being used.

I don't quite understand the question -- are you asking about how to launch the unikernel? 

I notice that there is a lot of talk of using the cubieboards for running the images.  How do you handle talking with the hardware components such as the GPIOs or I2C?

Our use of the Cubieboard2 doesn't require any use of GPIO or I2C; we just use the network and block interfaces.  If necessary, this is handled via a Xen/Linux dom0 device driver in the same way as network or block storage.

-anil

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