You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Sebastien Goasguen <ru...@gmail.com> on 2014/04/15 09:35:45 UTC
[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
Re: [ACS4.5] move from xen 2 xenserver
Posted by Tim Mackey <tm...@gmail.com>.
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
<St...@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
> > <St...@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
> > >
> >
> >
>
RE: [ACS4.5] move from xen 2 xenserver
Posted by Stephen Turner <St...@citrix.com>.
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 <ru...@gmail.com>wrote:
>
> On Apr 15, 2014, at 4:46 AM, Stephen Turner
> <St...@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
> >
>
>
Re: [ACS4.5] move from xen 2 xenserver
Posted by Tim Mackey <tm...@gmail.com>.
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 <ru...@gmail.com>wrote:
>
> On Apr 15, 2014, at 4:46 AM, Stephen Turner <St...@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=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
> >
>
>
Re: [ACS4.5] move from xen 2 xenserver
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Apr 15, 2014, at 4:46 AM, Stephen Turner <St...@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=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
>
RE: [ACS4.5] move from xen 2 xenserver
Posted by Stephen Turner <St...@citrix.com>.
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?
Also, are there any backwards compatibility implications for the API? Or did we already use "XenServer" instead of "Xen" there?
--
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=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