2016 Xen hackathon notes - xenstored

2016 Xen hackathon notes - xenstored

[Luis R. Rodriguez]

At the 2016 Xen Hackathon I raised the topic of the default xenstored
used. Here are my notes with some new additions and supported
documentation. It would seem we're moving to oxenstored as the default
on Linux distributions and FreeBSD now, if you have issues or concerns
with this please let us know.

Notes:
=====

Although we have had oxenstored be the the default *iff* you have
ocaml dev libs installled when compiling Xen from source both Linux
distributions (Debian, SUSE*, Gentoo) and FreeBSD were still using the
C xenstored as the default. This begged the question of why not make
the switch given Citrix has already been using oxensotred in
production for years with these known gains [0]:

  * 1/5th the size in terms of line of code in comparison to the C xenstored
  * better performance increasing support for the number of guests, it
    supports 3 times number of guests for an upper limit of 160 guests

At the 2014 summit Anil's presented work on a Xenstore 2.0 which
hinted also towards the future ability to provide git-like
capabilities for the xenstore, all still written in Ocaml [1]. There
are others who have worked on a C++ replacement lixs (Lightweight
XenStore) as well [2], such work revealed oxenstored had the CPU
pegged after just a few dozen guests. Such work hinted that the
oxenstored that should be considered for more serious work was the
Mirage OS xenstore [3], but that the C++ lixs was also performing
better than the current oxenstored.

Although there are questions about the future of the Xenestore we know
oxenstored performs better than cxenstored and since we are building
and using it by default already it begged the question why haven't
distributions made the switch to use it by default. Since Mirage OS
work seems promising we agreed to just set oxenstored as the default
in distributions and in the future hope that Mirage's work or other
contending efforts make it upstream to consider them as alternatives.

Given Mirage Xenstore would still require ocaml, it would be a good
stepping stone now to just use oxenstored by default more widely on
Linux distributions and FreeBSD. A concern was raised about expertise
over Ocaml, however it would seem that we will have no option but to
rely on the community / folks supporting upstream oxenstored for this.

[0] http://www.do-not-panic.com/2014/04/summary-of-gains-of-xen-oxenstored.html
[1] http://decks.openmirage.org/xendevsummit14#/
[2] http://events.linuxfoundation.org/sites/events/files/slides/xendevsummit14_0.pdf
[3] https://github.com/mirage/ocaml-xenstore

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: 2016 Xen hackathon notes - xenstored

[Anil Madhavapeddy]

Please do get in touch if you have any packaging problems concerning OCaml.  It's pretty good on modern Linux and FreeBSD though, and oxenstored works on most modern releases.

We've not got a set of patches that are suitable for upstreaming for the Xenstored/Irmin tree that we demonstrated at XenSummit, so please don't block waiting for that.

Anil

> On 28 Apr 2016, at 19:34, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> 
> At the 2016 Xen Hackathon I raised the topic of the default xenstored
> used. Here are my notes with some new additions and supported
> documentation. It would seem we're moving to oxenstored as the default
> on Linux distributions and FreeBSD now, if you have issues or concerns
> with this please let us know.
> 
> Notes:
> =====
> 
> Although we have had oxenstored be the the default *iff* you have
> ocaml dev libs installled when compiling Xen from source both Linux
> distributions (Debian, SUSE*, Gentoo) and FreeBSD were still using the
> C xenstored as the default. This begged the question of why not make
> the switch given Citrix has already been using oxensotred in
> production for years with these known gains [0]:
> 
>  * 1/5th the size in terms of line of code in comparison to the C xenstored
>  * better performance increasing support for the number of guests, it
>    supports 3 times number of guests for an upper limit of 160 guests
> 
> At the 2014 summit Anil's presented work on a Xenstore 2.0 which
> hinted also towards the future ability to provide git-like
> capabilities for the xenstore, all still written in Ocaml [1]. There
> are others who have worked on a C++ replacement lixs (Lightweight
> XenStore) as well [2], such work revealed oxenstored had the CPU
> pegged after just a few dozen guests. Such work hinted that the
> oxenstored that should be considered for more serious work was the
> Mirage OS xenstore [3], but that the C++ lixs was also performing
> better than the current oxenstored.
> 
> Although there are questions about the future of the Xenestore we know
> oxenstored performs better than cxenstored and since we are building
> and using it by default already it begged the question why haven't
> distributions made the switch to use it by default. Since Mirage OS
> work seems promising we agreed to just set oxenstored as the default
> in distributions and in the future hope that Mirage's work or other
> contending efforts make it upstream to consider them as alternatives.
> 
> Given Mirage Xenstore would still require ocaml, it would be a good
> stepping stone now to just use oxenstored by default more widely on
> Linux distributions and FreeBSD. A concern was raised about expertise
> over Ocaml, however it would seem that we will have no option but to
> rely on the community / folks supporting upstream oxenstored for this.
> 
> [0] http://www.do-not-panic.com/2014/04/summary-of-gains-of-xen-oxenstored.html
> [1] http://decks.openmirage.org/xendevsummit14#/
> [2] http://events.linuxfoundation.org/sites/events/files/slides/xendevsummit14_0.pdf
> [3] https://github.com/mirage/ocaml-xenstore
> 
>  Luis
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: 2016 Xen hackathon notes - xenstored

[Filipe Manco]

Hi

Regarding LiXS, our goal is to make it one of the upstream xenstore 
alternatives. For that I already started getting internal approvals to 
release the code open source, which should happen somewhere around next 
month. I also need to fix some bugs and would like to do some 
performance testing before the release.

Once it is released, it would be nice to get some comments from the 
community on the implementation, specifically about how to make it 
upstreamable; I’ll let you know when the code is available.

Does this plan sound reasonable?

Best regards
Filipe Manco

P.S. The code will be released under a BSD License

On 28-04-2016 20:34, Luis R. Rodriguez wrote:
> At the 2016 Xen Hackathon I raised the topic of the default xenstored
> used. Here are my notes with some new additions and supported
> documentation. It would seem we're moving to oxenstored as the default
> on Linux distributions and FreeBSD now, if you have issues or concerns
> with this please let us know.
>
> Notes:
> =====
>
> Although we have had oxenstored be the the default *iff* you have
> ocaml dev libs installled when compiling Xen from source both Linux
> distributions (Debian, SUSE*, Gentoo) and FreeBSD were still using the
> C xenstored as the default. This begged the question of why not make
> the switch given Citrix has already been using oxensotred in
> production for years with these known gains [0]:
>
>    * 1/5th the size in terms of line of code in comparison to the C xenstored
>    * better performance increasing support for the number of guests, it
>      supports 3 times number of guests for an upper limit of 160 guests
>
> At the 2014 summit Anil's presented work on a Xenstore 2.0 which
> hinted also towards the future ability to provide git-like
> capabilities for the xenstore, all still written in Ocaml [1]. There
> are others who have worked on a C++ replacement lixs (Lightweight
> XenStore) as well [2], such work revealed oxenstored had the CPU
> pegged after just a few dozen guests. Such work hinted that the
> oxenstored that should be considered for more serious work was the
> Mirage OS xenstore [3], but that the C++ lixs was also performing
> better than the current oxenstored.
>
> Although there are questions about the future of the Xenestore we know
> oxenstored performs better than cxenstored and since we are building
> and using it by default already it begged the question why haven't
> distributions made the switch to use it by default. Since Mirage OS
> work seems promising we agreed to just set oxenstored as the default
> in distributions and in the future hope that Mirage's work or other
> contending efforts make it upstream to consider them as alternatives.
>
> Given Mirage Xenstore would still require ocaml, it would be a good
> stepping stone now to just use oxenstored by default more widely on
> Linux distributions and FreeBSD. A concern was raised about expertise
> over Ocaml, however it would seem that we will have no option but to
> rely on the community / folks supporting upstream oxenstored for this.
>
> [0] http://www.do-not-panic.com/2014/04/summary-of-gains-of-xen-oxenstored.html
> [1] http://decks.openmirage.org/xendevsummit14#/
> [2] http://events.linuxfoundation.org/sites/events/files/slides/xendevsummit14_0.pdf
> [3] https://github.com/mirage/ocaml-xenstore
>
>    Luis


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: 2016 Xen hackathon notes - xenstored

[Luis R. Rodriguez]

On Fri, Apr 29, 2016 at 04:33:31PM +0200, Filipe Manco wrote:
> Hi
> 
> Regarding LiXS, our goal is to make it one of the upstream xenstore
> alternatives. For that I already started getting internal approvals
> to release the code open source, which should happen somewhere
> around next month. I also need to fix some bugs and would like to do
> some performance testing before the release.
> 
> Once it is released, it would be nice to get some comments from the
> community on the implementation, specifically about how to make it
> upstreamable; I’ll let you know when the code is available.
> 
> Does this plan sound reasonable?

I have no say in the Xen community, but to me this sounds reasonable,
you should have competing solutions and let people win, its the
same principle that was applied to Linux Security Modules, for
instance, and that philosophy tends to enable all viable options
to compete while upstream. For Xen, there are already 2 xenstores,
having another IMHO should just require commitment for a maintainer
to upkeep it. Without that it should make no sense.

You also require C++ though ? That's a new requirement AFAICT, so
that would need to be addressed.

If it were up to me, I'd recommend to consider extending Kconfig
onto tools, and then having the xenstore be a Kconfig option.

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: 2016 Xen hackathon notes - xenstored

[Wei Liu]

Luis, thanks for starting this thread.

On Fri, Apr 29, 2016 at 08:55:04PM +0200, Luis R. Rodriguez wrote:
> On Fri, Apr 29, 2016 at 04:33:31PM +0200, Filipe Manco wrote:
> > Hi
> > 
> > Regarding LiXS, our goal is to make it one of the upstream xenstore
> > alternatives. For that I already started getting internal approvals
> > to release the code open source, which should happen somewhere
> > around next month. I also need to fix some bugs and would like to do
> > some performance testing before the release.
> > 
> > Once it is released, it would be nice to get some comments from the
> > community on the implementation, specifically about how to make it
> > upstreamable; I’ll let you know when the code is available.
> > 
> > Does this plan sound reasonable?
> 
> I have no say in the Xen community, but to me this sounds reasonable,
> you should have competing solutions and let people win, its the
> same principle that was applied to Linux Security Modules, for
> instance, and that philosophy tends to enable all viable options
> to compete while upstream. For Xen, there are already 2 xenstores,
> having another IMHO should just require commitment for a maintainer
> to upkeep it. Without that it should make no sense.
> 

I think the best way forward is to post design doc and / or code to
xen-devel to decide what next step is.  We shall discuss things based on
their merits.

> You also require C++ though ? That's a new requirement AFAICT, so
> that would need to be addressed.
> 

IIRC we already need g++ to build QEMU (it doesn't get along with gcc
last time I checked), so that wouldn't be a big issue IMHO.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel