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