Re: [Xen-devel] 2016 Xen hackathon notes - xenstored
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
Re: [Xen-devel] 2016 Xen hackathon notes - xenstored
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: [Xen-devel] 2016 Xen hackathon notes - xenstored
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: [Xen-devel] 2016 Xen hackathon notes - xenstored
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. Rodriguezwrote: > > 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
[Xen-devel] 2016 Xen hackathon notes - xenstored
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