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

Reply via email to