|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: mirari updates
On 05/03/2013 20:54, Anil Madhavapeddy wrote: On 5 Mar 2013, at 17:56, Vincent Bernardoff <vb@xxxxxxxxxxxxxx> wrote:On 27/02/2013 21:52, Anil Madhavapeddy wrote:- In the UNIX backend, in mirage-platform/unix/runtime/tap_stubs_*.c, we currently hardcode an `ifconfig 10.0.0.1` to give the tap device a static IP address. This has made it easy so far to get networking up and running, but the tap device setup really ought to be done by Mirari-run instead of the Mirage-platform libraries (which should just open a tun passed to them).I don’t think mirari (and obviously even less Netif) should setup the tap since it requires root access. Mirari should give instructions on how to do so, but not issue root commands itself.It doesn't necessarily need root: there are a bunch of platform-specific ways. For example, on Linux, you can set CAP_NET_ADMIN to the Mirari binary to gain access to tunctl. There's a good summary of all the ways in the Erlang tuntap bindings here: https://github.com/msantos/tunctl (it might be worth creating a robust ocaml-tuntap that wraps these mechanisms) Ok. I’ve read about the CAP_NET_ADMIN but thought at first that it was not a very practical possiblity. It would work well with Mirari on Linux, Mirari would have to have that cap and it could create tun/tap interfaces. For other OS, it seems that sudo is needed. But this looks really feasible indeed. And an ocaml-tuntap library is probably the best way to implement those functions, as they will probably be needed by other ocaml programs in the future. As everybody seems to agree on that I’ll do my best to write such small library, if we were going to port mirage-platform code into Mirari, it should not be much more work to put it into such library instead. The other possibility is to _not_ bother to setup tun/tap with mirari, but let the use issue the right commands instead (ip tuntap ... or whatever command on other unixes). This is probably a bit less convenient for the user, but it removes some complexity from mirage/mirari, and it makes the user more aware of what is under the hood. My opinion on that is that automatic setup is better ONLY if it works perfectly for everybody. If implementing it properly for all platforms is too tricky such that it does not work equally well for everyone and frustrates users, then it is seems better to me to explain users that they have to setup a tuntap interface, and how to do it. Just tell me what you think about that. About the Xen backend, we should decide on a standard way to execute kernels (as Anil said). At the moment, I only tested the xl create -c config.cfg kernel.xen method, which works well. If I understand well, it is better to use libvirt as it is a library that could be better integrated with mirari. I did not test it yet, but plan to do it asap.Great. I know Dave has been experimenting with libvirt recently, but he's travelling this week. Jon, Mike, do you have any opinions about this? A (very) simple first start would be to just generate the minimal .conf file (as mir-run does at the moment) and directly call 'xl/xm create -c'. Finally I think this is a better first solution (and maybe a better last solution as well). Because it does not require the dependency to libvirt, and that will always work. I’ll definitely implement that first, and I’ll have a look at libvirt later if needed. The more interesting second backend is automating Amazon EC2, for which bindings exist on Github (but I haven't tried). This requires signing the Xen kernel as an AKI image, and calling the right HTTP calls to upload it and register it, before spinning it up. I can give you delegate access to my Amazon account, Vincent, if you don't have access to an EC2 account within Citrix. Agree that it is very cool.So, basically, here is what I’m going to do for mirari run, in order (if everyones agree): 1. mirari run for UNIX backend: Basically figure out / fix the tuntap business, and just run the executable. 2. mirari run for Xen: Create a xl config file, then run the kernel (using xl exe/ (or libxl if available ?) 3. mirari run for EC2: Implement the automation of sending kernels on EC2.As for making mirari do the opam switch itself (and thus specify the desired backend in mirari config file), I have no opinion about it. To me personally I don’t perceive that as very important (I don’t mind opam switching manually, because I don’t think it is required to do it often). But I can certainly implement it if needed (as you explained in former emails). Good evening, Vincent
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |