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=748b575af8a66c58b0d52e7457e4d4e1e875231f > > > > 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 > > > >