cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <rohit.ya...@citrix.com>
Subject Re: [ASFCS40][DISCUSS] Binary packaging - another round of discussions that I'd like us to come to a conclusion on.
Date Thu, 04 Oct 2012 11:26:46 GMT

On 04-Oct-2012, at 3:59 PM, Noah Slater <nslater@tumbolia.org> wrote:

> Comments inline.
> 
> On Thu, Oct 4, 2012 at 11:08 AM, Rohit Yadav <rohit.yadav@citrix.com> wrote:
> 
>> 
>> On 04-Oct-2012, at 2:45 PM, Noah Slater <nslater@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


Mime
View raw message