As a follow up activity to the open sourcing of XenServer, Citrix is pleased to announce the open sourcing of its automated test platform, XenRT. XenRT ("Xen Regression Test") is a test automation framework, written in Python, providing abstractions for the various components under test (pool, host, VM, storage, network etc). The library code which makes up these abstractions simplifies the process of writing tests, allowing quite complex operations to be performed in a single method call. In a full deployment, XenRT handles all aspects of the testing process - it will schedule a test job onto a host, bootstrap it (via DHCP/PXE), install the build to be tested, carry out the testing, and collect all necessary logs for troubleshooting, without any user interaction required. In addition to basic functional, regression, and stress testing, XenRT has suites of tests that are used for testing performance, scalability, and interoperability. Within Citrix, XenRT is used with a distributed lab comprised of an extremely wide range of hardware, and is developed and maintained by a team of some 25 developers. Tests are also written and executed directly by the wider XenServer engineering team, in a true "Test-as-a-Service" platform - see http://blogs.citrix.com/2013/08/30/xenserver-automated-testing-and-lab-orchestration-introducing-xenrt/ for more information. XenRT has been open sourced to leverage Citrix''s experience and resources in test automation to help improve the quality of open source Xen and XenServer releases, to benefit the entire community. To get started with XenRT, follow the links below to the code and a README document (which contains getting started instructions - further documentation will follow in the near future). For discussion a mailing list has been created - information about this can be found at https://lists.xenserver.org/sympa/info/xenrt-users README document: http://downloadns.citrix.com.edgesuite.net/akdlm/8169/README Main XenRT tarball: http://downloadns.citrix.com.edgesuite.net/akdlm/8168/xenrt.tgz Third party test resource tarball: http://downloadns.citrix.com.edgesuite.net/akdlm/8169/tests.tgz Source for third party resources (not required for normal operation): http://downloadns.citrix.com.edgesuite.net/akdlm/8169/tests-source.tgz Kind Regards, Alex Brett
Hi all, I wanted to add some extra context to this announcement. Citrix making available the code of XenRT is also an important step for the Xen Project (with it, in effect phase 1/3 of creating a more comprehensive framework for the Xen Project is complete). At the last Advisory Board meeting, the following AB members agreed to form a Test Framework Committee to look at next steps on how we can make this happen. The companies which so far agreed to be on the committee are AMD, Amazon Web Services, CA, Calxeda, Citrix, Intel and Oracle. For more details, see http://wiki.xen.org/wiki/AB_Meeting/August_2013_Minutes#.231_Open_Source_testing_framework The basic idea is to create a test-as-a-service framework for the Xen Project which is hosted at a vendor neutral location. The framework would be open to the community to extend. It will still take some time to complete this work (probably Q1 next year). This does mean, that the project will not have an alternative to OSS test for some time. I am planning to schedule a BoF and/or session at the Xen Developer Meeting to get more community input. I expect that members of the still to be formed Test Framework Committee will work with the wider development community. Best Regards Lars On Mon, Sep 2, 2013 at 1:51 PM, Alex Brett <Alex.Brett@citrix.com> wrote:> As a follow up activity to the open sourcing of XenServer, Citrix is > pleased to announce the open sourcing of its automated test platform, XenRT. > > XenRT ("Xen Regression Test") is a test automation framework, written in > Python, providing abstractions for the various components under test (pool, > host, VM, storage, network etc). The library code which makes up these > abstractions simplifies the process of writing tests, allowing quite > complex operations to be performed in a single method call. > > In a full deployment, XenRT handles all aspects of the testing process - > it will schedule a test job onto a host, bootstrap it (via DHCP/PXE), > install the build to be tested, carry out the testing, and collect all > necessary logs for troubleshooting, without any user interaction required. > > In addition to basic functional, regression, and stress testing, XenRT has > suites of tests that are used for testing performance, scalability, and > interoperability. > > Within Citrix, XenRT is used with a distributed lab comprised of an > extremely wide range of hardware, and is developed and maintained by a team > of some 25 developers. Tests are also written and executed directly by the > wider XenServer engineering team, in a true "Test-as-a-Service" platform - > see > http://blogs.citrix.com/2013/08/30/xenserver-automated-testing-and-lab-orchestration-introducing-xenrt/for more information. > > XenRT has been open sourced to leverage Citrix''s experience and resources > in test automation to help improve the quality of open source Xen and > XenServer releases, to benefit the entire community. > > To get started with XenRT, follow the links below to the code and a README > document (which contains getting started instructions - further > documentation will follow in the near future). For discussion a mailing > list has been created - information about this can be found at > https://lists.xenserver.org/sympa/info/xenrt-users > > > README document: > http://downloadns.citrix.com.edgesuite.net/akdlm/8169/README > > Main XenRT tarball: > http://downloadns.citrix.com.edgesuite.net/akdlm/8168/xenrt.tgz > > Third party test resource tarball: > http://downloadns.citrix.com.edgesuite.net/akdlm/8169/tests.tgz > > Source for third party resources (not required for normal operation): > http://downloadns.citrix.com.edgesuite.net/akdlm/8169/tests-source.tgz > > Kind Regards, > Alex Brett > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Dear all, I have a question about this XenRT. Is it possible to use it on Xen ARM? If not, I wonder there is any plan for this. Best Regards, ChanJu Park ------- Original Message ------- Sender : Lars Kurth<lars.kurth.xen@gmail.com> Date : 2013-09-03 00:06 (GMT+09:00) Title : Re: [Xen-devel] Introducing Open Source XenRT Hi all, I wanted to add some extra context to this announcement. Citrix making available the code of XenRT is also an important step for the Xen Project (with it, in effect phase 1/3 of creating a more comprehensive framework for the Xen Project is complete). At the last Advisory Board meeting, the following AB members agreed to form a Test Framework Committee to look at next steps on how we can make this happen. The companies which so far agreed to be on the committee are AMD, Amazon Web Services, CA, Calxeda, Citrix, Intel and Oracle. For more details, see http://wiki.xen.org/wiki/AB_Meeting/August_2013_Minutes#.231_Open_Source_testing_framework The basic idea is to create a test-as-a-service framework for the Xen Project which is hosted at a vendor neutral location. The framework would be open to the community to extend. It will still take some time to complete this work (probably Q1 next year). This does mean, that the project will not have an alternative to OSS test for some time. I am planning to schedule a BoF and/or session at the Xen Developer Meeting to get more community input. I expect that members of the still to be formed Test Framework Committee will work with the wider development community. Best Regards Lars On Mon, Sep 2, 2013 at 1:51 PM, Alex Brett <Alex.Brett@citrix.com> wrote: As a follow up activity to the open sourcing of XenServer, Citrix is pleased to announce the open sourcing of its automated test platform, XenRT. XenRT ("Xen Regression Test") is a test automation framework, written in Python, providing abstractions for the various components under test (pool, host, VM, storage, network etc). The library code which makes up these abstractions simplifies the process of writing tests, allowing quite complex operations to be performed in a single method call. In a full deployment, XenRT handles all aspects of the testing process - it will schedule a test job onto a host, bootstrap it (via DHCP/PXE), install the build to be tested, carry out the testing, and collect all necessary logs for troubleshooting, without any user interaction required. In addition to basic functional, regression, and stress testing, XenRT has suites of tests that are used for testing performance, scalability, and interoperability. Within Citrix, XenRT is used with a distributed lab comprised of an extremely wide range of hardware, and is developed and maintained by a team of some 25 developers. Tests are also written and executed directly by the wider XenServer engineering team, in a true "Test-as-a-Service" platform - see http://blogs.citrix.com/2013/08/30/xenserver-automated-testing-and-lab-orchestration-introducing-xenrt/ for more information. XenRT has been open sourced to leverage Citrix''s experience and resources in test automation to help improve the quality of open source Xen and XenServer releases, to benefit the entire community. To get started with XenRT, follow the links below to the code and a README document (which contains getting started instructions - further documentation will follow in the near future). For discussion a mailing list has been created - information about this can be found at https://lists.xenserver.org/sympa/info/xenrt-users README document: http://downloadns.citrix.com.edgesuite.net/akdlm/8169/README Main XenRT tarball: http://downloadns.citrix.com.edgesuite.net/akdlm/8168/xenrt.tgz Third party test resource tarball: http://downloadns.citrix.com.edgesuite.net/akdlm/8169/tests.tgz Source for third party resources (not required for normal operation): http://downloadns.citrix.com.edgesuite.net/akdlm/8169/tests-source.tgz Kind Regards, Alex Brett _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
ChanJu, On Tue, Sep 3, 2013 at 3:33 AM, ChanJu Park <bestworld@samsung.com> wrote:> > > I have a question about this XenRT. > Is it possible to use it on Xen ARM? > If not, I wonder there is any plan for this. >Unless something has recently changed, XenRT does not currently work on ARM. But as far as I know, there are no architectural reasons why this could not be made to work. Alex, should be able to elaborate. I would assume that for ARM the challenging part is to provision Xen and Linux onto an ARM environment (I guess it depends on which environment we are talking about). Everything else should in theory be straightforward. There are no detailed plans for XenRT at this stage: it will be up to the Test Framework Committee to drive the strategy and plans. Given that Calxeda is on Test Framework Committee, I would expect that ARM support will be on the roadmap. Also, Samsung is on the Xen Project Advisory Board, but has not yet nominated a representative for the Test Framework Committee. I will send you a separate e-mail such that you can follow up within Samsung. Best Regards Lars _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
> I have a question about this XenRT. > Is it possible to use it on Xen ARM? > If not, I wonder there is any plan for this.Hi ChanJu, At the moment XenRT is primarily focused around XenServer, so the simple answer is no. Having said that, due to the way abstraction has been used, extending it to make it do so would not be particularly difficult, it would just need an appropriate implementation of the host/guest models that can configure an ARM host, i.e. to talk to whatever toolstack is in use appropriately. As an example of this flexibility, the XenServer performance team are currently working on an implementation that can use libvirt, in order to do comparative tests against other hypervisors etc. As Lars has mentioned, the hardest part if a total integration is wanted would I suspect be the provisioning side of things - XenServer / native linux is installed by PXE booting a typical x86 host, which is relatively straightforward, but I presume most ARM platforms are going to be a bit more complicated than that... Regards, Alex Brett
Hi Alex,> As Lars has mentioned, the hardest part if a total integration is wanted would I suspect be the provisioning side of things - XenServer / native linux is installed by PXE booting a typical x86 host, which is relatively straightforward, but I presume most ARM platforms are going to be a bit more complicated than that...Yes, I agree with you. I''d like to use this with the support of PXE booting in Xen ARM, but it seems not so simple. And I''m trying to find out a way to make support this via the Advisory Board. Thank you for your kind answer. Regards, ChanJu Park ------- Original Message ------- Sender : Alex Brett<Alex.Brett@citrix.com> Date : 2013-09-03 18:27 (GMT+09:00) Title : RE: [Xen-devel] Introducing Open Source XenRT> I have a question about this XenRT. > Is it possible to use it on Xen ARM? > If not, I wonder there is any plan for this.Hi ChanJu, At the moment XenRT is primarily focused around XenServer, so the simple answer is no. Having said that, due to the way abstraction has been used, extending it to make it do so would not be particularly difficult, it would just need an appropriate implementation of the host/guest models that can configure an ARM host, i.e. to talk to whatever toolstack is in use appropriately. As an example of this flexibility, the XenServer performance team are currently working on an implementation that can use libvirt, in order to do comparative tests against other hypervisors etc. As Lars has mentioned, the hardest part if a total integration is wanted would I suspect be the provisioning side of things - XenServer / native linux is installed by PXE booting a typical x86 host, which is relatively straightforward, but I presume most ARM platforms are going to be a bit more complicated than that... Regards, Alex Brett