On 04-Oct-2012, at 3:59 PM, Noah Slater <nsla...@tumbolia.org> wrote:
> Comments inline. > > On Thu, Oct 4, 2012 at 11:08 AM, Rohit Yadav <rohit.ya...@citrix.com> wrote: > >> >> On 04-Oct-2012, at 2:45 PM, Noah Slater <nsla...@tumbolia.org> wrote: >> >>> Can you outline your plan for both the source release and the binary >>> packages? >> >> This is just for binary release. For source release, all the code that >> needs to be shipped is already in the repository. > > > We need to be clear that we are not making binary "releases". I understand that we're making source releases now, I think I mentioned on IRC that I'm proposing this for post 4.0. Sometimes in future we will be doing releases right? > > >>> Will the source release contain the source for all the plugins? (My best >>> guess is yes, and this sounds fine.) >> >> Yes, it already does, in plugins/ directory. > > > Okay, cool. > > >>> If you were providing a binary package, why separate out the plugins? >> >> If all plugins artifacts are in separate deb/rpm packages, user has more >> power to decide which plugin she wants and which she does not. >> So, if I'm using only xen, I may not want to install kvm, ovm etc. > > > I guess my confusion here stems from my time packaging for Debian proper. > You would never bundle a dependancy in a package. You would just build a > package for the dependancy, have your main package Depends on it, and let > APT handle it. That is correct, that's why we're hoping not to bundle any deps (oss or noss) with the binary releases. So, for example plugin-kvm can depend of cloud-agent etc. > > Can you clarify for me what your plan is in this regard? No plan, just proposal. And a proof of concept using a plugin for deb packaging: https://github.com/bhaisaab/incubator-cloudstack/tree/debs-maven > A sample list of > package names would probably be illustrative. Do you plan to have a main > deb package for "cloudstack" and then have a package for > "cloudstack-netapp" which actually bundles manageontap? The way I was > originally imagining it is that we would provide a single "cloudstack" deb, This is open for discussion, if we want a monolithic package or few monolithic packages or bundle everything in separate pkgs. For the list of debs and exactly what pkgs I'm proposing see below; > which includes all of the plugins, and then if the user wanted to actually > use the netapp plugin, they would install manageontap locally. > > >>> Sounds like a binary package should contain all of the plugins we ship, >>> just like a source release. >> >> Yes, the non-asf/nonoss plugins won't work unless user install the libs >> mentioned in 1. > > > I'm confused, because you seem to be agreeing, but in your previous > paragraph you seem to be suggesting that the plugins are bundled up along > with dependancies in separate packages. Please correct me if I am wrong! Let me define some terms; artifact: any jar, war or target created by maven submodule: a subproject, like api, agent plugins: they are sub projects and part of the cloudstack source code but they're separate out of the core logic deps/libs: used interchangeably, these are dependencies used by various cloudstack artifacts (jars, wars etc.) to reuse classes, evoke library functions and methods nonoss libs: such as icontrol, netscaler, vmware jars etc. Right now, these are the different packages built by the maven jdeb plugin; Cloudstack pkgs; ./agent/target/cloud-agent_4.0.0+SNAPSHOT.deb ./api/target/cloud-api_4.0.0+SNAPSHOT.deb ./client/target/cloud-client-ui-4.1.0-SNAPSHOT/target/cloud-client-ui_4.0.0+SNAPSHOT.deb ./client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/scripts/target/cloud-scripts_4.0.0+SNAPSHOT.deb ./client/target/generated-webapp/target/cloud-client-ui_4.0.0+SNAPSHOT.deb ./client/target/generated-webapp/WEB-INF/classes/scripts/target/cloud-scripts_4.0.0+SNAPSHOT.deb ./core/target/cloud-core_4.0.0+SNAPSHOT.deb ./scripts/target/cloud-scripts_4.0.0+SNAPSHOT.deb ./server/target/cloud-server_4.0.0+SNAPSHOT.deb ./setup/target/cloud-client-ui_4.0.0+SNAPSHOT.deb ./target/scripts/target/cloud-scripts_4.0.0+SNAPSHOT.deb ./target/ui/target/cloud-client-ui_4.0.0+SNAPSHOT.deb ./ui/target/cloud-client-ui_4.0.0+SNAPSHOT.deb Deps, not available on a distr.'s repository bundled here (for example gson.jar is not available on ubuntu etc.): ./deps/target/cloud-deps_4.0.0+SNAPSHOT.deb Plugins, in plugins/ directory; ./deployment-planners/user-concentrated-pod/target/cloud-plugin-planner-user-concentrated-pod_4.0.0+SNAPSHOT.deb ./deployment-planners/user-dispersing/target/cloud-plugin-planner-user-dispersing_4.0.0+SNAPSHOT.deb ./file-systems/netapp/target/cloud-plugin-netapp_4.0.0+SNAPSHOT.deb ./host-allocators/random/target/cloud-plugin-host-allocator-random_4.0.0+SNAPSHOT.deb ./hypervisors/ovm/target/cloud-plugin-hypervisor-ovm_4.0.0+SNAPSHOT.deb ./hypervisors/vmware/target/cloud-plugin-hypervisor-vmware_4.0.0+SNAPSHOT.deb ./hypervisors/xen/target/cloud-plugin-hypervisor-xen_4.0.0+SNAPSHOT.deb ./network-elements/elastic-loadbalancer/target/cloud-plugin-network-elb_4.0.0+SNAPSHOT.deb ./network-elements/f5/target/cloud-plugin-network-f5_4.0.0+SNAPSHOT.deb ./network-elements/juniper-srx/target/cloud-plugin-network-srx_4.0.0+SNAPSHOT.deb ./network-elements/netscaler/target/cloud-plugin-network-netscaler_4.0.0+SNAPSHOT.deb ./network-elements/nicira-nvp/target/cloud-plugin-network-nvp_4.0.0+SNAPSHOT.deb ./network-elements/ovs/target/cloud-plugin-network-ovs_4.0.0+SNAPSHOT.deb ./storage-allocators/random/target/cloud-plugin-storage-allocator-random_4.0.0+SNAPSHOT.deb ./user-authenticators/ldap/target/cloud-plugin-user-authenticator-ldap_4.0.0+SNAPSHOT.deb ./user-authenticators/md5/target/cloud-plugin-user-authenticator-md5_4.0.0+SNAPSHOT.deb ./user-authenticators/plain-text/target/cloud-plugin-user-authenticator-plaintext_4.0.0+SNAPSHOT.deb > > >>> This confuses me in the context of the above paragraph. In the above >>> paragraph, I understand you to be talking about separating out the >> plugins >>> for for DEBs and RPMs. But here you seem to be talking about a setup >> where >>> build.apache.org is fetching 3rd party non-OS software, so that it can >>> prepare a binary build that contains all the plugins and is properly >> linked. >> >> You understand correct, my question is, will ASF allow such a process. >> It's just like installing gcc and libs and building code and removing >> gcc/libs; not that we use gcc or its libs. > > > We need to ask legal-discuss and infra. I have done that now. Thanks. On second though, what I'm proposing may become very complex to handle. So, I'm dropping the idea. (to be picked up by someone else :) Regards. > > Thanks, > > -- > NS
