Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of rohit.yadav@citrix.com
 designates 203.166.19.134 as permitted sender)
From: Rohit Yadav <rohit.yadav@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Thu, 4 Oct 2012 16:56:46 +0530
Subject: Re: [ASFCS40][DISCUSS] Binary packaging - another round of
 discussions that I'd like us to come to a conclusion on.
Thread-Topic: [ASFCS40][DISCUSS] Binary packaging - another round of
 discussions that I'd like us to come to a conclusion on.
Thread-Index: Ac2iIyOcNd43iwU2QJiBd7xtsmXArA==
Message-ID: <B31259A3-A7F2-481B-89E8-F3A330E8996D@citrix.com>
References: 
 <CA+96GG4KU=Zzwf2dbzMfpi5DKAu3GZrxmVMP2r6=7sn_BiXPRg@mail.gmail.com>
 <CA+Y+445YJOtQBOLP+PT_MrHLHBGZoGBUoYhBx82O5tYK3xVGBA@mail.gmail.com>
 <0BCCCE152323764BB7FD6AE6D7A1D906FE11C32D4F@BANPMAILBOX01.citrite.net>
 <CA+Y+445Zm83v5UJZKq4MgjyS3KsYPgciPK67FVnXk_EHGj3-KA@mail.gmail.com>
 <899B590B-3DBA-45D6-BF8B-7F92584A1E58@citrix.com>
 <CA+Y+44575nfqArr90+uraM-+2ESdUwm=swuBwaL_gtP+4oMu9Q@mail.gmail.com>
 <C3AEE292-7D8D-447B-B576-ADCD3471562A@citrix.com>
 <CA+Y+447PnrQ4j55JeNYdUFBg8wJ8M+VPHwOwgTJOZ3NTUs0FQw@mail.gmail.com>
In-Reply-To: 
 <CA+Y+447PnrQ4j55JeNYdUFBg8wJ8M+VPHwOwgTJOZ3NTUs0FQw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


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

> Comments inline.
>=20
> On Thu, Oct 4, 2012 at 11:08 AM, Rohit Yadav <rohit.yadav@citrix.com> wro=
te:
>=20
>>=20
>> On 04-Oct-2012, at 2:45 PM, Noah Slater <nslater@tumbolia.org> wrote:
>>=20
>>> Can you outline your plan for both the source release and the binary
>>> packages?
>>=20
>> This is just for binary release. For source release, all the code that
>> needs to be shipped is already in the repository.
>=20
>=20
> 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?

>=20
>=20
>>> Will the source release contain the source for all the plugins? (My bes=
t
>>> guess is yes, and this sounds fine.)
>>=20
>> Yes, it already does, in plugins/ directory.
>=20
>=20
> Okay, cool.
>=20
>=20
>>> If you were providing a binary package, why separate out the plugins?
>>=20
>> 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.
>=20
>=20
> 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 nos=
s) with the binary releases.
So, for example plugin-kvm can depend of cloud-agent etc.

>=20
> 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 packa=
ging:
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" de=
b,

This is open for discussion, if we want a monolithic package or few monolit=
hic 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 actuall=
y
> use the netapp plugin, they would install manageontap locally.
>=20
>=20
>>> Sounds like a binary package should contain all of the plugins we ship,
>>> just like a source release.
>>=20
>> Yes, the non-asf/nonoss plugins won't work unless user install the libs
>> mentioned in 1.
>=20
>=20
> 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 t=
hey're separate out of the core logic
deps/libs: used interchangeably, these are dependencies used by various clo=
udstack artifacts (jars, wars etc.) to reuse classes, evoke library functio=
ns 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/targ=
et/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-scrip=
ts_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-use=
r-concentrated-pod_4.0.0+SNAPSHOT.deb
./deployment-planners/user-dispersing/target/cloud-plugin-planner-user-disp=
ersing_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+SN=
APSHOT.deb
./hypervisors/ovm/target/cloud-plugin-hypervisor-ovm_4.0.0+SNAPSHOT.deb
./hypervisors/vmware/target/cloud-plugin-hypervisor-vmware_4.0.0+SNAPSHOT.d=
eb
./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+SNAPSH=
OT.deb
./network-elements/netscaler/target/cloud-plugin-network-netscaler_4.0.0+SN=
APSHOT.deb
./network-elements/nicira-nvp/target/cloud-plugin-network-nvp_4.0.0+SNAPSHO=
T.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-pla=
intext_4.0.0+SNAPSHOT.deb

>=20
>=20
>>> 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.
>>=20
>> 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.
>=20
>=20
> 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.


>=20
> Thanks,
>=20
> --=20
> NS