You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Edison Su <Ed...@citrix.com> on 2012/07/26 03:00:15 UTC
KVM code will be moved to plugin folder
As kvm code depends on libvirt-java, which is incompatible with Apache license. I want to move it to plugin folder as we already did for other hypervisors, and add a compile option to turn on/off KVM compilation. By default, it's turned off.
If you have any patches against agent/kvm code, please check them in ASAP. I want to start the moving in Friday.
Any comments?
Re: KVM code will be moved to plugin folder
Posted by Wido den Hollander <wi...@widodh.nl>.
On 07/26/2012 07:30 PM, Edison Su wrote:
>
>
>> -----Original Message-----
>> From: Wido den Hollander [mailto:wido@widodh.nl]
>> Sent: Thursday, July 26, 2012 8:55 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: KVM code will be moved to plugin folder
>>
>>
>> ----- Oorspronkelijk bericht -----
>>>
>>>
>>> On 07/26/2012 03:00 AM, Edison Su wrote:
>>>> As kvm code depends on libvirt-java, which is incompatible with
>> Apache
>>>> license. I want to move it to plugin folder as we already did for
>>>> other hypervisors, and add a compile option to turn on/off KVM
>>>> compilation. By default, it's turned off. If you have any patches
>>>> against agent/kvm code, please check them in ASAP. I want to start
>> the
>>>> moving in Friday. Any comments?
>>>
>>
>> I forgot one thing. My RBD code contains a couple of changes in the KVM
>> code.
>
> That's my main concern about move KVM code around, I don't want to break your stuff without any notice.
>
>>
>> The RBD stuff works, so we could merge it in so that it can move to the
>> plugins directory?
>
> Yes, just merge into master right now!:)
Done, and pushed! It builds with build-all.
I don't have any other code lying around for the agent/KVM.
Wido
>
>>
>> Any further refinement can be done until the 4.0 release.
>>
>> Would that work? Otherwise I have some manual rebasing to do which will
>> take some time.
>>
>> Wido
>>
>>> No comments, but great work!
>>>
>>> I'll check again with Red Hat to get the package building with
>>> libvirt-java for Debian in so we can add that as a build dependency
>> for
>>> the Debian packages as well.
>>>
>>> Wido
>>>
>
RE: KVM code will be moved to plugin folder
Posted by Edison Su <Ed...@citrix.com>.
> -----Original Message-----
> From: Wido den Hollander [mailto:wido@widodh.nl]
> Sent: Thursday, July 26, 2012 8:55 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: KVM code will be moved to plugin folder
>
>
> ----- Oorspronkelijk bericht -----
> >
> >
> > On 07/26/2012 03:00 AM, Edison Su wrote:
> > > As kvm code depends on libvirt-java, which is incompatible with
> Apache
> > > license. I want to move it to plugin folder as we already did for
> > > other hypervisors, and add a compile option to turn on/off KVM
> > > compilation. By default, it's turned off. If you have any patches
> > > against agent/kvm code, please check them in ASAP. I want to start
> the
> > > moving in Friday. Any comments?
> >
>
> I forgot one thing. My RBD code contains a couple of changes in the KVM
> code.
That's my main concern about move KVM code around, I don't want to break your stuff without any notice.
>
> The RBD stuff works, so we could merge it in so that it can move to the
> plugins directory?
Yes, just merge into master right now!:)
>
> Any further refinement can be done until the 4.0 release.
>
> Would that work? Otherwise I have some manual rebasing to do which will
> take some time.
>
> Wido
>
> > No comments, but great work!
> >
> > I'll check again with Red Hat to get the package building with
> > libvirt-java for Debian in so we can add that as a build dependency
> for
> > the Debian packages as well.
> >
> > Wido
> >
Re: KVM code will be moved to plugin folder
Posted by David Nalley <da...@gnsa.us>.
On Thu, Jul 26, 2012 at 11:54 AM, Wido den Hollander <wi...@widodh.nl> wrote:
>
> ----- Oorspronkelijk bericht -----
>>
>>
>> On 07/26/2012 03:00 AM, Edison Su wrote:
>> > As kvm code depends on libvirt-java, which is incompatible with Apache
>> > license. I want to move it to plugin folder as we already did for
>> > other hypervisors, and add a compile option to turn on/off KVM
>> > compilation. By default, it's turned off. If you have any patches
>> > against agent/kvm code, please check them in ASAP. I want to start the
>> > moving in Friday. Any comments?
>>
>
> I forgot one thing. My RBD code contains a couple of changes in the KVM code.
>
> The RBD stuff works, so we could merge it in so that it can move to the plugins directory?
>
> Any further refinement can be done until the 4.0 release.
>
> Would that work? Otherwise I have some manual rebasing to do which will take some time.
>
> Wido
I see no reason not to merge your RBD stuff into master - might start
a separate thread on it though, just to make sure folks see it.
--David
Re: KVM code will be moved to plugin folder
Posted by Wido den Hollander <wi...@widodh.nl>.
----- Oorspronkelijk bericht -----
>
>
> On 07/26/2012 03:00 AM, Edison Su wrote:
> > As kvm code depends on libvirt-java, which is incompatible with Apache
> > license. I want to move it to plugin folder as we already did for
> > other hypervisors, and add a compile option to turn on/off KVM
> > compilation. By default, it's turned off. If you have any patches
> > against agent/kvm code, please check them in ASAP. I want to start the
> > moving in Friday. Any comments?
>
I forgot one thing. My RBD code contains a couple of changes in the KVM code.
The RBD stuff works, so we could merge it in so that it can move to the plugins directory?
Any further refinement can be done until the 4.0 release.
Would that work? Otherwise I have some manual rebasing to do which will take some time.
Wido
> No comments, but great work!
>
> I'll check again with Red Hat to get the package building with
> libvirt-java for Debian in so we can add that as a build dependency for
> the Debian packages as well.
>
> Wido
>
Re: KVM code will be moved to plugin folder
Posted by Wido den Hollander <wi...@widodh.nl>.
On 07/26/2012 03:00 AM, Edison Su wrote:
> As kvm code depends on libvirt-java, which is incompatible with Apache license. I want to move it to plugin folder as we already did for other hypervisors, and add a compile option to turn on/off KVM compilation. By default, it's turned off.
> If you have any patches against agent/kvm code, please check them in ASAP. I want to start the moving in Friday.
> Any comments?
No comments, but great work!
I'll check again with Red Hat to get the package building with
libvirt-java for Debian in so we can add that as a build dependency for
the Debian packages as well.
Wido
RE: KVM code will be moved to plugin folder
Posted by Alex Huang <Al...@citrix.com>.
+1
> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Tuesday, July 31, 2012 6:06 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: KVM code will be moved to plugin folder
>
> On Tue, Jul 31, 2012 at 5:40 AM, Wido den Hollander <wi...@widodh.nl>
> wrote:
> >
> >
> > On 07/31/2012 12:03 AM, Edison Su wrote:
> >>
> >> KVM code is moved to plugins/hypervisor/kvm, a new jar, cloud-kvm.jar
> >> is created for all the java classes used by kvm code.
> >
> >
> > Why cloud-kvm.jar? As KVM is also a plugin shouldn't it be named
> > consistently like cloud-plugin-netapp.jar, cloud-plugin-f5.jar and
> > cloud-plugin-netscaler.jar?
> >
> > Something like:
> > * cloud-plugin-kvm.jar
> > * cloud-plugin-hypervisor-kvm.jar
> >
> > I think the second name could be a bit long, but since most of the
> > stuff goes automated for building classpaths I wouldn't mind.
> >
> > Wido
>
> +1 for the name change. I'd prefer "cloud-plugin-hypervisor-kvm.jar",
> because that correctly namespaces it as a HV plugin.
>
> -chip
Re: KVM code will be moved to plugin folder
Posted by Chip Childers <ch...@sungard.com>.
On Tue, Jul 31, 2012 at 5:40 AM, Wido den Hollander <wi...@widodh.nl> wrote:
>
>
> On 07/31/2012 12:03 AM, Edison Su wrote:
>>
>> KVM code is moved to plugins/hypervisor/kvm, a new jar, cloud-kvm.jar is
>> created for all the java classes used by kvm code.
>
>
> Why cloud-kvm.jar? As KVM is also a plugin shouldn't it be named
> consistently like cloud-plugin-netapp.jar, cloud-plugin-f5.jar and
> cloud-plugin-netscaler.jar?
>
> Something like:
> * cloud-plugin-kvm.jar
> * cloud-plugin-hypervisor-kvm.jar
>
> I think the second name could be a bit long, but since most of the stuff
> goes automated for building classpaths I wouldn't mind.
>
> Wido
+1 for the name change. I'd prefer "cloud-plugin-hypervisor-kvm.jar",
because that correctly namespaces it as a HV plugin.
-chip
Re: KVM code will be moved to plugin folder
Posted by Wido den Hollander <wi...@widodh.nl>.
On 07/31/2012 12:03 AM, Edison Su wrote:
> KVM code is moved to plugins/hypervisor/kvm, a new jar, cloud-kvm.jar is created for all the java classes used by kvm code.
Why cloud-kvm.jar? As KVM is also a plugin shouldn't it be named
consistently like cloud-plugin-netapp.jar, cloud-plugin-f5.jar and
cloud-plugin-netscaler.jar?
Something like:
* cloud-plugin-kvm.jar
* cloud-plugin-hypervisor-kvm.jar
I think the second name could be a bit long, but since most of the stuff
goes automated for building classpaths I wouldn't mind.
Wido
>
>> -----Original Message-----
>> From: Edison Su [mailto:Edison.su@citrix.com]
>> Sent: Wednesday, July 25, 2012 6:00 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: KVM code will be moved to plugin folder
>>
>> As kvm code depends on libvirt-java, which is incompatible with Apache
>> license. I want to move it to plugin folder as we already did for other
>> hypervisors, and add a compile option to turn on/off KVM compilation.
>> By default, it's turned off.
>> If you have any patches against agent/kvm code, please check them in
>> ASAP. I want to start the moving in Friday.
>> Any comments?
Re: KVM code will be moved to plugin folder
Posted by Tomoe Sugihara <to...@midokura.com>.
Thanks, now working fine.
On Tue, Jul 31, 2012 at 8:01 AM, Edison Su <Ed...@citrix.com> wrote:
> Sorry, forget to check in some files.
> Checkout out the latest master, will be fixed.
>
>> -----Original Message-----
>> From: tomoe@midokura.jp [mailto:tomoe@midokura.jp] On Behalf Of Tomoe
>> Sugihara
>> Sent: Monday, July 30, 2012 3:45 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: KVM code will be moved to plugin folder
>>
>> Hi Edison,
>>
>> You may already know this but, now compile-server is broken:
>>
>>
>> On Tue, Jul 31, 2012 at 7:03 AM, Edisocompile-server:
>> [mkdir] Created dir:
>> /home/tomoe/code/incubator-cloudstack/target/classes/cloud-server.jar
>> [echo] Compiling /home/tomoe/code/incubator-cloudstack/server/src
>> [javac] Compiling 738 source files to
>> /home/tomoe/code/incubator-cloudstack/target/classes/cloud-server.jar
>> [javac] /home/tomoe/code/incubator-
>> cloudstack/server/src/com/cloud/agent/manager/AgentManagerImpl.java:91:
>> package com.cloud.hypervisor.kvm.discover does not exist
>> [javac] import
>> com.cloud.hypervisor.kvm.discover.KvmDummyResourceBase;
>> [javac] ^
>> [javac] /home/tomoe/code/incubator-
>> cloudstack/server/src/com/cloud/resource/ResourceManagerImpl.java:101:
>> package com.cloud.hypervisor.kvm.discover does not exist
>> [javac] import
>> com.cloud.hypervisor.kvm.discover.KvmDummyResourceBase;
>> [javac] ^
>> [javac] /home/tomoe/code/incubator-
>> cloudstack/server/src/com/cloud/agent/manager/AgentManagerImpl.java:789:
>> cannot find symbol
>> [javac] symbol : class KvmDummyResourceBase
>> [javac] location: class com.cloud.agent.manager.AgentManagerImpl
>> [javac] if (resource instanceof
>> DummySecondaryStorageResource || resource instanceof
>> KvmDummyResourceBase) {
>> [javac]
>> ^
>> [javac] /home/tomoe/code/incubator-
>> cloudstack/server/src/com/cloud/resource/ResourceManagerImpl.java:701:
>> cannot find symbol
>> [javac] symbol : class KvmDummyResourceBase
>> [javac] location: class com.cloud.resource.ResourceManagerImpl
>> [javac] if (resource instanceof
>> KvmDummyResourceBase) {
>> [javac] ^
>>
>> n Su <Ed...@citrix.com> wrote:
>> > KVM code is moved to plugins/hypervisor/kvm, a new jar, cloud-kvm.jar
>> is created for all the java classes used by kvm code.
>> >
>> >> -----Original Message-----
>> >> From: Edison Su [mailto:Edison.su@citrix.com]
>> >> Sent: Wednesday, July 25, 2012 6:00 PM
>> >> To: cloudstack-dev@incubator.apache.org
>> >> Subject: KVM code will be moved to plugin folder
>> >>
>> >> As kvm code depends on libvirt-java, which is incompatible with
>> Apache
>> >> license. I want to move it to plugin folder as we already did for
>> other
>> >> hypervisors, and add a compile option to turn on/off KVM compilation.
>> >> By default, it's turned off.
>> >> If you have any patches against agent/kvm code, please check them in
>> >> ASAP. I want to start the moving in Friday.
>> >> Any comments?
RE: KVM code will be moved to plugin folder
Posted by Edison Su <Ed...@citrix.com>.
Sorry, forget to check in some files.
Checkout out the latest master, will be fixed.
> -----Original Message-----
> From: tomoe@midokura.jp [mailto:tomoe@midokura.jp] On Behalf Of Tomoe
> Sugihara
> Sent: Monday, July 30, 2012 3:45 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: KVM code will be moved to plugin folder
>
> Hi Edison,
>
> You may already know this but, now compile-server is broken:
>
>
> On Tue, Jul 31, 2012 at 7:03 AM, Edisocompile-server:
> [mkdir] Created dir:
> /home/tomoe/code/incubator-cloudstack/target/classes/cloud-server.jar
> [echo] Compiling /home/tomoe/code/incubator-cloudstack/server/src
> [javac] Compiling 738 source files to
> /home/tomoe/code/incubator-cloudstack/target/classes/cloud-server.jar
> [javac] /home/tomoe/code/incubator-
> cloudstack/server/src/com/cloud/agent/manager/AgentManagerImpl.java:91:
> package com.cloud.hypervisor.kvm.discover does not exist
> [javac] import
> com.cloud.hypervisor.kvm.discover.KvmDummyResourceBase;
> [javac] ^
> [javac] /home/tomoe/code/incubator-
> cloudstack/server/src/com/cloud/resource/ResourceManagerImpl.java:101:
> package com.cloud.hypervisor.kvm.discover does not exist
> [javac] import
> com.cloud.hypervisor.kvm.discover.KvmDummyResourceBase;
> [javac] ^
> [javac] /home/tomoe/code/incubator-
> cloudstack/server/src/com/cloud/agent/manager/AgentManagerImpl.java:789:
> cannot find symbol
> [javac] symbol : class KvmDummyResourceBase
> [javac] location: class com.cloud.agent.manager.AgentManagerImpl
> [javac] if (resource instanceof
> DummySecondaryStorageResource || resource instanceof
> KvmDummyResourceBase) {
> [javac]
> ^
> [javac] /home/tomoe/code/incubator-
> cloudstack/server/src/com/cloud/resource/ResourceManagerImpl.java:701:
> cannot find symbol
> [javac] symbol : class KvmDummyResourceBase
> [javac] location: class com.cloud.resource.ResourceManagerImpl
> [javac] if (resource instanceof
> KvmDummyResourceBase) {
> [javac] ^
>
> n Su <Ed...@citrix.com> wrote:
> > KVM code is moved to plugins/hypervisor/kvm, a new jar, cloud-kvm.jar
> is created for all the java classes used by kvm code.
> >
> >> -----Original Message-----
> >> From: Edison Su [mailto:Edison.su@citrix.com]
> >> Sent: Wednesday, July 25, 2012 6:00 PM
> >> To: cloudstack-dev@incubator.apache.org
> >> Subject: KVM code will be moved to plugin folder
> >>
> >> As kvm code depends on libvirt-java, which is incompatible with
> Apache
> >> license. I want to move it to plugin folder as we already did for
> other
> >> hypervisors, and add a compile option to turn on/off KVM compilation.
> >> By default, it's turned off.
> >> If you have any patches against agent/kvm code, please check them in
> >> ASAP. I want to start the moving in Friday.
> >> Any comments?
Re: KVM code will be moved to plugin folder
Posted by Tomoe Sugihara <to...@midokura.com>.
Hi Edison,
You may already know this but, now compile-server is broken:
On Tue, Jul 31, 2012 at 7:03 AM, Edisocompile-server:
[mkdir] Created dir:
/home/tomoe/code/incubator-cloudstack/target/classes/cloud-server.jar
[echo] Compiling /home/tomoe/code/incubator-cloudstack/server/src
[javac] Compiling 738 source files to
/home/tomoe/code/incubator-cloudstack/target/classes/cloud-server.jar
[javac] /home/tomoe/code/incubator-cloudstack/server/src/com/cloud/agent/manager/AgentManagerImpl.java:91:
package com.cloud.hypervisor.kvm.discover does not exist
[javac] import com.cloud.hypervisor.kvm.discover.KvmDummyResourceBase;
[javac] ^
[javac] /home/tomoe/code/incubator-cloudstack/server/src/com/cloud/resource/ResourceManagerImpl.java:101:
package com.cloud.hypervisor.kvm.discover does not exist
[javac] import com.cloud.hypervisor.kvm.discover.KvmDummyResourceBase;
[javac] ^
[javac] /home/tomoe/code/incubator-cloudstack/server/src/com/cloud/agent/manager/AgentManagerImpl.java:789:
cannot find symbol
[javac] symbol : class KvmDummyResourceBase
[javac] location: class com.cloud.agent.manager.AgentManagerImpl
[javac] if (resource instanceof
DummySecondaryStorageResource || resource instanceof
KvmDummyResourceBase) {
[javac]
^
[javac] /home/tomoe/code/incubator-cloudstack/server/src/com/cloud/resource/ResourceManagerImpl.java:701:
cannot find symbol
[javac] symbol : class KvmDummyResourceBase
[javac] location: class com.cloud.resource.ResourceManagerImpl
[javac] if (resource instanceof KvmDummyResourceBase) {
[javac] ^
n Su <Ed...@citrix.com> wrote:
> KVM code is moved to plugins/hypervisor/kvm, a new jar, cloud-kvm.jar is created for all the java classes used by kvm code.
>
>> -----Original Message-----
>> From: Edison Su [mailto:Edison.su@citrix.com]
>> Sent: Wednesday, July 25, 2012 6:00 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: KVM code will be moved to plugin folder
>>
>> As kvm code depends on libvirt-java, which is incompatible with Apache
>> license. I want to move it to plugin folder as we already did for other
>> hypervisors, and add a compile option to turn on/off KVM compilation.
>> By default, it's turned off.
>> If you have any patches against agent/kvm code, please check them in
>> ASAP. I want to start the moving in Friday.
>> Any comments?
RE: KVM code will be moved to plugin folder
Posted by Edison Su <Ed...@citrix.com>.
KVM code is moved to plugins/hypervisor/kvm, a new jar, cloud-kvm.jar is created for all the java classes used by kvm code.
> -----Original Message-----
> From: Edison Su [mailto:Edison.su@citrix.com]
> Sent: Wednesday, July 25, 2012 6:00 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: KVM code will be moved to plugin folder
>
> As kvm code depends on libvirt-java, which is incompatible with Apache
> license. I want to move it to plugin folder as we already did for other
> hypervisors, and add a compile option to turn on/off KVM compilation.
> By default, it's turned off.
> If you have any patches against agent/kvm code, please check them in
> ASAP. I want to start the moving in Friday.
> Any comments?
Re: KVM code will be moved to plugin folder
Posted by Murali Reddy <Mu...@citrix.com>.
On 26/07/12 8:43 PM, "David Nalley" <da...@gnsa.us> wrote:
>On Wed, Jul 25, 2012 at 9:00 PM, Edison Su <Ed...@citrix.com> wrote:
>> As kvm code depends on libvirt-java, which is incompatible with Apache
>>license. I want to move it to plugin folder as we already did for other
>>hypervisors, and add a compile option to turn on/off KVM compilation. By
>>default, it's turned off.
>> If you have any patches against agent/kvm code, please check them in
>>ASAP. I want to start the moving in Friday.
>> Any comments?
>
>A couple of questions:
>
>Are the other hypervisors moving to the plugin model as well?
Yes, Ovm, Vmware, Xen already moved into plug-ins model.
>
>Why do this instead of just making KVM/agent build not part of
>build-all (e.g. not built by default?)
>
>--David
>
Re: KVM code will be moved to plugin folder
Posted by David Nalley <da...@gnsa.us>.
On Wed, Jul 25, 2012 at 9:00 PM, Edison Su <Ed...@citrix.com> wrote:
> As kvm code depends on libvirt-java, which is incompatible with Apache license. I want to move it to plugin folder as we already did for other hypervisors, and add a compile option to turn on/off KVM compilation. By default, it's turned off.
> If you have any patches against agent/kvm code, please check them in ASAP. I want to start the moving in Friday.
> Any comments?
A couple of questions:
Are the other hypervisors moving to the plugin model as well?
Why do this instead of just making KVM/agent build not part of
build-all (e.g. not built by default?)
--David
Re: KVM code will be moved to plugin folder
Posted by David Nalley <da...@gnsa.us>.
On Thu, Jul 26, 2012 at 10:46 AM, John Kinsella <jl...@stratosec.co> wrote:
> So basically for a good portion of CloudStack users, we're removing functionality that they're currently using.
>
> Do we have any idea what percentage of CS users compile from source vs use packaged versions? How many users of the packaged product will decide to switch to a different platform where they don't have to jump through hoops to get it to work?
>
> If we go this route, and some third party happens to be packaging CS builds with kvm support enabled, would/could the Apache CloudStack download page provide a link to that?
>
> I know this has been discussed from a legal/engineering POV, but I'm envisioning some amount of teeth gnashing, just wondering the best way to handle it…I don't want to see headlines "CloudStack removes support for KVM" which is what the more dramatic will say.
>
As Kevin noted, this is effectively just setting the default build to
not build KVM (e.g. what is the build-all target right now)
It appears, based on our conversations, that CloudStack can ship
convenience binaries (see my comments below about releases) that have
items that would be prohibited in releases. I.e., we could ask for an
exception to ship convenience binaries of CloudStack with libvirt-java
in place, or we could build the binaries with a dependency on
libvirt-java - either would keep KVM support present for users.
So the difference is what the ASF considers a release. Only source
releases are 'releases' under the ASF's definition. Binary artifacts
are merely built for the user's convenience. I also was concerned that
there would be much wailing and gnashing of teeth, please see the
discussion we had at OSCON, about this matter [0]. I am convinced that
much of that drama can be avoided now - though, VMware-support might
be an issue.
[0] http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201207.mbox/%3CCAKprHVa5feNc1eZicahsqwPKdn6Uezeh_So%2BpRBQtyEDxC2nWw%40mail.gmail.com%3E
RE: KVM code will be moved to plugin folder
Posted by Ewan Mellor <Ew...@eu.citrix.com>.
We're not going to remove the libvirt code -- we're just making it possible to turn off in the build, so that people can have a GPL-free build if they want one. The source code release will have all the KVM code there still -- it'll just be a build flag for you to turn it on. And (subject to approval) we'll have "convenience builds" with KVM support turned on too.
Cheers,
Ewan.
> -----Original Message-----
> From: Kelceydamage@bbits [mailto:kelcey@bbits.ca]
> Sent: Thursday, July 26, 2012 8:51 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: KVM code will be moved to plugin folder
>
> Well I for one am going to need to find or make an RPM building system,
> as our company likes clean production servers without 'from source'
> builds, so the Sys-Admins can cleanly manage the farm.
>
> I do understand the decision to remove the libvirt code, however I too
> hope we can put together good documentation or something, that enables
> a smoother transition for KVM users.
>
> Sent from my iPhone
>
> On Jul 26, 2012, at 7:46 AM, John Kinsella <jl...@stratosec.co> wrote:
>
> > So basically for a good portion of CloudStack users, we're removing
> functionality that they're currently using.
> >
> > Do we have any idea what percentage of CS users compile from source
> vs use packaged versions? How many users of the packaged product will
> decide to switch to a different platform where they don't have to jump
> through hoops to get it to work?
> >
> > If we go this route, and some third party happens to be packaging CS
> builds with kvm support enabled, would/could the Apache CloudStack
> download page provide a link to that?
> >
> > I know this has been discussed from a legal/engineering POV, but I'm
> envisioning some amount of teeth gnashing, just wondering the best way
> to handle it…I don't want to see headlines "CloudStack removes support
> for KVM" which is what the more dramatic will say.
> >
> > John
> >
> > On Jul 25, 2012, at 6:00 PM, Edison Su wrote:
> >
> >> As kvm code depends on libvirt-java, which is incompatible with
> Apache license. I want to move it to plugin folder as we already did
> for other hypervisors, and add a compile option to turn on/off KVM
> compilation. By default, it's turned off.
> >> If you have any patches against agent/kvm code, please check them in
> ASAP. I want to start the moving in Friday.
> >> Any comments?
> >>
> >
> >
Re: KVM code will be moved to plugin folder
Posted by "Kelceydamage@bbits" <ke...@bbits.ca>.
Well I for one am going to need to find or make an RPM building system, as our company likes clean production servers without 'from source' builds, so the Sys-Admins can cleanly manage the farm.
I do understand the decision to remove the libvirt code, however I too hope we can put together good documentation or something, that enables a smoother transition for KVM users.
Sent from my iPhone
On Jul 26, 2012, at 7:46 AM, John Kinsella <jl...@stratosec.co> wrote:
> So basically for a good portion of CloudStack users, we're removing functionality that they're currently using.
>
> Do we have any idea what percentage of CS users compile from source vs use packaged versions? How many users of the packaged product will decide to switch to a different platform where they don't have to jump through hoops to get it to work?
>
> If we go this route, and some third party happens to be packaging CS builds with kvm support enabled, would/could the Apache CloudStack download page provide a link to that?
>
> I know this has been discussed from a legal/engineering POV, but I'm envisioning some amount of teeth gnashing, just wondering the best way to handle it…I don't want to see headlines "CloudStack removes support for KVM" which is what the more dramatic will say.
>
> John
>
> On Jul 25, 2012, at 6:00 PM, Edison Su wrote:
>
>> As kvm code depends on libvirt-java, which is incompatible with Apache license. I want to move it to plugin folder as we already did for other hypervisors, and add a compile option to turn on/off KVM compilation. By default, it's turned off.
>> If you have any patches against agent/kvm code, please check them in ASAP. I want to start the moving in Friday.
>> Any comments?
>>
>
>
Re: KVM code will be moved to plugin folder
Posted by "Kelceydamage@bbits" <ke...@bbits.ca>.
I get it now too.
Thanks for the clarification
Sent from my iPhone
On Jul 26, 2012, at 9:17 AM, John Kinsella <jl...@stratosec.co> wrote:
> Got it, my bad…I saw the previous comments about "convenience builds" but didn't' fully gather the ramifications.
>
> On Jul 26, 2012, at 8:06 AM, Kevin Kluge wrote:
>
> My understanding is that the "convenience builds" can include KVM support enabled. The source release will include the code with the build option off. So most users won't notice any changes.
>
> -kevin
>
> -----Original Message-----
> From: John Kinsella [mailto:jlk@stratosec.co]
> Sent: Thursday, July 26, 2012 7:46 AM
> To: <cl...@incubator.apache.org>>
> Subject: Re: KVM code will be moved to plugin folder
>
> So basically for a good portion of CloudStack users, we're removing
> functionality that they're currently using.
>
> Do we have any idea what percentage of CS users compile from source vs
> use packaged versions? How many users of the packaged product will decide
> to switch to a different platform where they don't have to jump through
> hoops to get it to work?
>
> If we go this route, and some third party happens to be packaging CS builds
> with kvm support enabled, would/could the Apache CloudStack download
> page provide a link to that?
>
> I know this has been discussed from a legal/engineering POV, but I'm
> envisioning some amount of teeth gnashing, just wondering the best way to
> handle it...I don't want to see headlines "CloudStack removes support for
> KVM" which is what the more dramatic will say.
>
> John
>
> On Jul 25, 2012, at 6:00 PM, Edison Su wrote:
>
> As kvm code depends on libvirt-java, which is incompatible with Apache
> license. I want to move it to plugin folder as we already did for other
> hypervisors, and add a compile option to turn on/off KVM compilation. By
> default, it's turned off.
> If you have any patches against agent/kvm code, please check them in
> ASAP. I want to start the moving in Friday.
> Any comments?
>
>
>
>
>
> Stratosec<http://stratosec.co> - Secure Infrastructure as a Service
> o: 415.315.9385
> @johnlkinsella<http://twitter.com/johnlkinsella>
>
Re: KVM code will be moved to plugin folder
Posted by John Kinsella <jl...@stratosec.co>.
Got it, my bad…I saw the previous comments about "convenience builds" but didn't' fully gather the ramifications.
On Jul 26, 2012, at 8:06 AM, Kevin Kluge wrote:
My understanding is that the "convenience builds" can include KVM support enabled. The source release will include the code with the build option off. So most users won't notice any changes.
-kevin
-----Original Message-----
From: John Kinsella [mailto:jlk@stratosec.co]
Sent: Thursday, July 26, 2012 7:46 AM
To: <cl...@incubator.apache.org>>
Subject: Re: KVM code will be moved to plugin folder
So basically for a good portion of CloudStack users, we're removing
functionality that they're currently using.
Do we have any idea what percentage of CS users compile from source vs
use packaged versions? How many users of the packaged product will decide
to switch to a different platform where they don't have to jump through
hoops to get it to work?
If we go this route, and some third party happens to be packaging CS builds
with kvm support enabled, would/could the Apache CloudStack download
page provide a link to that?
I know this has been discussed from a legal/engineering POV, but I'm
envisioning some amount of teeth gnashing, just wondering the best way to
handle it...I don't want to see headlines "CloudStack removes support for
KVM" which is what the more dramatic will say.
John
On Jul 25, 2012, at 6:00 PM, Edison Su wrote:
As kvm code depends on libvirt-java, which is incompatible with Apache
license. I want to move it to plugin folder as we already did for other
hypervisors, and add a compile option to turn on/off KVM compilation. By
default, it's turned off.
If you have any patches against agent/kvm code, please check them in
ASAP. I want to start the moving in Friday.
Any comments?
Stratosec<http://stratosec.co> - Secure Infrastructure as a Service
o: 415.315.9385
@johnlkinsella<http://twitter.com/johnlkinsella>
RE: KVM code will be moved to plugin folder
Posted by Kevin Kluge <Ke...@citrix.com>.
My understanding is that the "convenience builds" can include KVM support enabled. The source release will include the code with the build option off. So most users won't notice any changes.
-kevin
> -----Original Message-----
> From: John Kinsella [mailto:jlk@stratosec.co]
> Sent: Thursday, July 26, 2012 7:46 AM
> To: <cl...@incubator.apache.org>
> Subject: Re: KVM code will be moved to plugin folder
>
> So basically for a good portion of CloudStack users, we're removing
> functionality that they're currently using.
>
> Do we have any idea what percentage of CS users compile from source vs
> use packaged versions? How many users of the packaged product will decide
> to switch to a different platform where they don't have to jump through
> hoops to get it to work?
>
> If we go this route, and some third party happens to be packaging CS builds
> with kvm support enabled, would/could the Apache CloudStack download
> page provide a link to that?
>
> I know this has been discussed from a legal/engineering POV, but I'm
> envisioning some amount of teeth gnashing, just wondering the best way to
> handle it...I don't want to see headlines "CloudStack removes support for
> KVM" which is what the more dramatic will say.
>
> John
>
> On Jul 25, 2012, at 6:00 PM, Edison Su wrote:
>
> > As kvm code depends on libvirt-java, which is incompatible with Apache
> license. I want to move it to plugin folder as we already did for other
> hypervisors, and add a compile option to turn on/off KVM compilation. By
> default, it's turned off.
> > If you have any patches against agent/kvm code, please check them in
> ASAP. I want to start the moving in Friday.
> > Any comments?
> >
>
Re: KVM code will be moved to plugin folder
Posted by John Kinsella <jl...@stratosec.co>.
So basically for a good portion of CloudStack users, we're removing functionality that they're currently using.
Do we have any idea what percentage of CS users compile from source vs use packaged versions? How many users of the packaged product will decide to switch to a different platform where they don't have to jump through hoops to get it to work?
If we go this route, and some third party happens to be packaging CS builds with kvm support enabled, would/could the Apache CloudStack download page provide a link to that?
I know this has been discussed from a legal/engineering POV, but I'm envisioning some amount of teeth gnashing, just wondering the best way to handle it…I don't want to see headlines "CloudStack removes support for KVM" which is what the more dramatic will say.
John
On Jul 25, 2012, at 6:00 PM, Edison Su wrote:
> As kvm code depends on libvirt-java, which is incompatible with Apache license. I want to move it to plugin folder as we already did for other hypervisors, and add a compile option to turn on/off KVM compilation. By default, it's turned off.
> If you have any patches against agent/kvm code, please check them in ASAP. I want to start the moving in Friday.
> Any comments?
>