cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Mackey <tmac...@gmail.com>
Subject Re: [ACS4.5] move from xen 2 xenserver
Date Wed, 16 Apr 2014 17:32:06 GMT
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.Turner@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:tmackey@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 <runseb@gmail.com
> >wrote:
>
> >
> > On Apr 15, 2014, at 4:46 AM, Stephen Turner
> > <Stephen.Turner@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:runseb@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
> > >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message