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 > > > >
