Stephen, I'm going to look into how to construct a test case for that, and here is the wiki page covering the feature: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Convert+Xen+usage+to+XenServer
Please feel free to suggest additional test cases, and I'll add them to the list. -tim On Wed, Apr 16, 2014 at 5:20 AM, Stephen Turner <stephen.tur...@citrix.com>wrote: > Thanks, Tim, that's helpful. My question about API backwards compatibility > was also whether any API arguments or return values are of the form "Xen" > currently and would become "XenServer" after this change, for example > because of changes in some parsing code. > > -- > Stephen Turner > > > -----Original Message----- > From: Tim Mackey [mailto:tmac...@gmail.com] > Sent: 16 April 2014 01:31 > To: dev@cloudstack.apache.org > Subject: Re: [ACS4.5] move from xen 2 xenserver > > This was a little more than a straight renaming, and I'll post all the > changes to the wiki for review in the morning. At a high level this patch > did the following: > > - Move the old plugins/hypervisors/xen to /plugins/hypervisors/xenserver > and change all namespaces to reflect the move (bulk of the work) > - Change any DDL/DML containing "xen"/"Xen" to become "XenServer" (took > care of both create and upgrade paths) > - Change any display areas containing "Xen" to become "XenServer" > > iirc there was one API change in the network label. It was > xennetworklabel, and I updated it to become xenservernetworklabel. Since I > don't want to break backwards compatibility either, I'm open to how best to > handle the situation. Also would like to understand a test case I can use > to validate. > > -tim > > > On Tue, Apr 15, 2014 at 6:27 AM, Sebastien Goasguen <run...@gmail.com > >wrote: > > > > > On Apr 15, 2014, at 4:46 AM, Stephen Turner > > <stephen.tur...@citrix.com> > > wrote: > > > > > As I said in the previous threaed, I'm +1 on the principle. It will > > avoid confusion between straight Xen and XenServer. It will also allow > > us to offer a non-XenServer Xen implementation. > > > > > > Sebastien, as all the filenames have changed, it's not clear from > > > the > > diff whether this is just a straight renaming with no other changes. > > Could you confirm that? > > > > > > > That's what it looks like, basically it creates a 'xenserver' plugin I > > know Tim has a prototype of Xen support as well, but it was not in > > this commit it seems. > > > > > > > Also, are there any backwards compatibility implications for the > > > API? Or > > did we already use "XenServer" instead of "Xen" there? > > > > > > > In the CloudStack API ? > > > > We are probably using Xen as value in several api calls…so we will > > need to check this carefully before any merge, we definitely don't > > want to break backward compatibility, or if we do we will need to move > > to 5.0 > > > > > -- > > > Stephen Turner > > > > > > > > > -----Original Message----- > > > From: Sebastien Goasguen [mailto:run...@gmail.com] > > > Sent: 15 April 2014 08:36 > > > To: dev@cloudstack.apache.org > > > Subject: [ACS4.5] move from xen 2 xenserver > > > > > > Folks, > > > > > > I just applied a patch from Tim Mackey: > > > > > > > > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=74 > > 8b575af8a66c58b0d52e7457e4d4e1e875231f > > > > > > commit: 748b575af8a66c58b0d52e7457e4d4e1e875231f > > > > > > This followed a [PROPOSAL] thread [1] > > > > > > This was pushed into a separate branch: xen2server > > > > > > This is a significant change that we should get consensus on and > > > merge > > to master relatively quickly to avoid any conflicts later on. > > > > > > Basically, we have been treating xen and xenserver the same so far, > > since the integration with Xen (i.e Xen Project) was/is done via xapi. > > > > > > There has been discussion to integrate with Xen using straight up > > libvirt, by creating a new Xen agent probably based on the KVM agent > > and there was some discussion to that effect in the Denver Hackathon. > > > > > > Making a clear split between Xen and Xenserver type of hypervisors > > > will > > help support different integration methods. > > > > > > I have asked Tim (in the review message) to create a wiki page, > > discussing all of this, but I wanted to give a heads up that this just > > hit the repo and that we should see a [MERGE] thread quickly. > > > > > > thoughts, flames ? > > > > > > > > > [1] http://markmail.org/thread/yrl3ii7gqlaaexij > > > > > > -Sebastien > > > > > > > >
