Hi Everyone, I just wanted to mention a learning while packing apex for bigtop (Something we can think about in future). We should probably have a mvn profile at top level pom which can called optionally be invoked and which will package the apex and all its dependency in a single tarball. This tarball can then just be extracted and one is readily use apex.
I don't know whether this is inline with ASF guidelines, but this I think this can be a nice addition. Something to think about in future. Thanks, Chinmay. On Wed, Feb 10, 2016 at 10:36 PM, Chinmay Kolhatkar <[email protected] > wrote: > Ok... Then make sense to use skeleton. > Let's wait for rest of the community as well to provide their opinion. > > - Chinmay. > On 10 Feb 2016 22:34, "Aniruddha Thombare" <[email protected]> > wrote: > >> AFI recall... >> >> Clirc >> Clirc history >> Etc >> >> Default site.xml and env can be kept too. >> >> >> >> >> Sent from handheld >> >> On Wed, 10 Feb 2016 10:25 pm Chinmay Kolhatkar <[email protected]> >> wrote: >> >> > Ok. Is there any content that we should add in .dt ? >> > On 10 Feb 2016 22:10, "Aniruddha Thombare" <[email protected]> >> > wrote: >> > >> > > Hi, >> > > >> > > .dt directory. >> > > In future, it may become .apex >> > > On 10 Feb 2016 9:53 pm, "Chinmay Kolhatkar" <[email protected]> >> > > wrote: >> > > >> > > > Hi Aniruddha, >> > > > >> > > > I like the idea of skeleton directory. But I don't see any use of >> it, >> > > > unless we've anything in default. >> > > > If you have something in your mind which should be default, can you >> > > please >> > > > share it? >> > > > >> > > > Thanks, >> > > > Chinmay. >> > > > >> > > > >> > > > On Wed, Feb 10, 2016 at 9:49 PM, Aniruddha Thombare < >> > > > [email protected]> wrote: >> > > > >> > > > > On point 2: >> > > > > Skeleton directory is for default home dir structure for future >> > users. >> > > > > By avoiding that, we can't inconvenience users and admins. >> > > > > Defaults in that configuration can be specified or evaluated at >> > > install. >> > > > > >> > > > > >> > > > > >> > > > > On Wed, 10 Feb 2016 9:37 pm Chinmay Kolhatkar < >> > [email protected] >> > > > >> > > > > wrote: >> > > > > >> > > > > > Really good points Pradeep and Aniruddha. >> > > > > > >> > > > > > 1. I believe we won't need to change the dtcli considering it >> works >> > > > with >> > > > > DT >> > > > > > Community edition. We can keep the directory structure similar >> to >> > > that. >> > > > > > dt-env.sh has variables which contains information required for >> > dtcli >> > > > to >> > > > > > launch. >> > > > > > >> > > > > > 2. Let me check with bigtop community that whether they >> facilitate >> > > the >> > > > > > installation of rpms/debs before user is created. In either >> case, >> > > > current >> > > > > > dtcli creates a .dt folder in home directory. Also before >> putting >> > > > > anything >> > > > > > in /etc/skel we need to define what are the default contents >> that >> > > > should >> > > > > go >> > > > > > to ~/.dt/ folder. If there is no defaults, probably we should >> not >> > > > > > explicitly add it in /etc/skel. >> > > > > > >> > > > > > 3. /etc/profile.d approach looks nice. This way contents of >> > > dt-env.sh >> > > > > are >> > > > > > present as env variables. But I see a catch there. Adding >> dt-env.sh >> > > to >> > > > > > /etc/profile.d would make all the variables available at runtime >> > all >> > > > the >> > > > > > time. I feel a little skeptical about that. Maybe a possible >> > > collision >> > > > > can >> > > > > > occur with other application vars. >> > > > > > Moreover, current dtcli does source "../conf/dt-env.sh" and >> > > > > > "~/.dt/dt-env.sh". So those variables are anyway available. >> > > > > > >> > > > > > @Aniruddha, the Jira and PR effort is happening at Bigtop >> > > > > Jira/repository. >> > > > > > Packaging related code usually goes there. (That's what all the >> > > > > components >> > > > > > in bigtop does). >> > > > > > Having said that, once a PR is created, I'll be sharing the >> link of >> > > PR >> > > > > > here, so that apex community as well can review it. >> > > > > > >> > > > > > Thanks, >> > > > > > Chinmay. >> > > > > > >> > > > > > >> > > > > > On Wed, Feb 10, 2016 at 7:57 PM, Aniruddha Thombare < >> > > > > > [email protected]> wrote: >> > > > > > >> > > > > > > +1 on suggestions and approach. >> > > > > > > We may need to iron out details about exact paths etc. >> > > > > > > Which can be done on jira / PR comments. >> > > > > > > Is that right @dev? >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > On Wed, 10 Feb 2016 7:53 pm Pradeep A. Dalvi < >> > > > [email protected]> >> > > > > > > wrote: >> > > > > > > >> > > > > > > > Inline comments... >> > > > > > > > >> > > > > > > > On Wed, Feb 10, 2016 at 2:51 PM, Chinmay Kolhatkar < >> > > > > > > > [email protected]> >> > > > > > > > wrote: >> > > > > > > > >> > > > > > > > > @Thomas, Not all the jar present in DT community edition >> will >> > > be >> > > > > > > included >> > > > > > > > > there. >> > > > > > > > > >> > > > > > > > > Here is the list of jars I found from common dependencies >> > > between >> > > > > of >> > > > > > > apex >> > > > > > > > > and DT Community edition: >> > > > > > > > > netlet-1.2.0.jar >> > > > > > > > > kryo-2.24.0.jar >> > > > > > > > > jackson-core-asl-1.9.2.jar >> > > > > > > > > jackson-mapper-asl-1.9.2.jar >> > > > > > > > > async-http-client-1.7.20.jar >> > > > > > > > > netty-3.6.6.Final.jar >> > > > > > > > > validation-api-1.1.0.Final.jar >> > > > > > > > > bval-jsr303-0.5.jar >> > > > > > > > > bval-core-0.5.jar >> > > > > > > > > commons-lang3-3.1.jar >> > > > > > > > > commons-beanutils-1.8.3.jar >> > > > > > > > > httpclient-4.3.5.jar >> > > > > > > > > commons-codec-1.10.jar >> > > > > > > > > zip4j-1.3.2.jar >> > > > > > > > > jetty-websocket-8.1.10.v20130312.jar >> > > > > > > > > xbean-asm5-shaded-4.3.jar >> > > > > > > > > jersey-apache-client4-1.9.jar >> > > > > > > > > jline-2.11.jar >> > > > > > > > > ant-1.9.2.jar >> > > > > > > > > ant-launcher-1.9.2.jar >> > > > > > > > > mbassador-1.1.9.jar >> > > > > > > > > jackson-jaxrs-1.9.2.jar >> > > > > > > > > jackson-xc-1.9.2.jar >> > > > > > > > > hadoop-common-2.2.0-tests.jar >> > > > > > > > > >> > > > > > > > > Ofcourse, I'll be running some tests do check that dtcli >> > works >> > > > > > properly >> > > > > > > > for >> > > > > > > > > launch+shutdown+kill of apps with only these libraries >> > present >> > > in >> > > > > > > > isolation >> > > > > > > > > without dependency on local m2. >> > > > > > > > > I'm believe that there are unwanted jars which are used >> for >> > > > compile >> > > > > > > time >> > > > > > > > > dependency and not runtime in above list which I can drop >> to >> > > keep >> > > > > > > package >> > > > > > > > > size minimal. >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > @Anniruddha, >> > > > > > > > > 1. dt-env.sh -> I'm not sure if all of the dt-env.sh is >> > > required. >> > > > > > Only >> > > > > > > > > required values I see in it are classpath. and dtcli is >> > capable >> > > > of >> > > > > > > > building >> > > > > > > > > it on the fly. >> > > > > > > > > >> > > > > > > > > 2. dt-site.xml -> Yes, we'll have to see how dtcli can >> find >> > the >> > > > jar >> > > > > > > path, >> > > > > > > > > dt-env.sh and all such conf files. If we need a change in >> > > dtcli, >> > > > > then >> > > > > > > > > community's opinion is required for whether dtcli should >> > change >> > > > in >> > > > > > our >> > > > > > > > repo >> > > > > > > > > or a copy of that with required changes exist in bigtop >> repo >> > > > until >> > > > > we >> > > > > > > > make >> > > > > > > > > the dtcli generic enough. >> > > > > > > > > >> > > > > > > > >> > > > > > > > Can we have these file paths set using environment variables >> > with >> > > > > some >> > > > > > > > default values in dtcli? >> > > > > > > > Then we can set such params in dt-env.sh. >> > > > > > > > >> > > > > > > > >> > > > > > > > > 3. dt-sited.xml -> How is this file different from >> > dt-site.xml? >> > > > Not >> > > > > > > sure >> > > > > > > > if >> > > > > > > > > adding in /etc/skel would help. Files & Dirs from >> /etc/skel >> > are >> > > > > > copied >> > > > > > > to >> > > > > > > > > home of new user when useradd program is called. But for >> > > existing >> > > > > > users >> > > > > > > > > this won't be of any use. Moreover, dtcli creates ~/.dt/ >> on >> > the >> > > > fly >> > > > > > if >> > > > > > > > not >> > > > > > > > > encountered for the first time. Again correct me if I'm >> > wrong. >> > > > > > > > > >> > > > > > > > >> > > > > > > > Yes, you are right. However this would probably be necessary >> > step >> > > > for >> > > > > > > > rpm/deb, as they may also get installed during OS install >> and >> > > > before >> > > > > > user >> > > > > > > > accounts were created. >> > > > > > > > >> > > > > > > > >> > > > > > > > > 4. Changing bashrc & bash_profile -> I'm not sure its the >> > best >> > > > > idea. >> > > > > > > > We'll >> > > > > > > > > anyway put dtcli in location which is by default present >> in >> > > path >> > > > > i.e. >> > > > > > > > > /usr/bin. >> > > > > > > > >> > > > > > > > For other env variables specific to apex, I'll prefer to use >> > > > > dt-env.sh >> > > > > > > and >> > > > > > > > > source it in dtcli rather than changing bashrc etc... >> > > > > > > > >> > > > > > > > >> > > > > > > > Instead, coping dt-env.sh to /etc/profile.d/ shall be the >> > cleaner >> > > > way >> > > > > > to >> > > > > > > > achieve the same. >> > > > > > > > >> > > > > > > > >> > > > > > > > > >> > > > > > > > Thanks, >> > > > > > > > > Chinmay. >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > On Wed, Feb 10, 2016 at 1:07 PM, Aniruddha Thombare < >> > > > > > > > > [email protected]> wrote: >> > > > > > > > > >> > > > > > > > > > Hi, >> > > > > > > > > > >> > > > > > > > > > @Chinmay, >> > > > > > > > > > >> > > > > > > > > > We need to consider following: >> > > > > > > > > > System wide default config files can be located at >> > following >> > > > > > > locations: >> > > > > > > > > > >> > > > > > > > > > /etc/apex/dt-env.sh (we may have to change dtcli >> behaviour >> > > on >> > > > > how >> > > > > > it >> > > > > > > > > finds >> > > > > > > > > > those locations) >> > > > > > > > > > /etc/apex/dt-site.xml (we may have to change dtcli >> > behaviour >> > > on >> > > > > how >> > > > > > > it >> > > > > > > > > > finds those locations) >> > > > > > > > > > /etc/skel/.dt/dt-sited.xml and other files (for new >> users >> > > that >> > > > > will >> > > > > > > be >> > > > > > > > > > created in system in future.) >> > > > > > > > > > >> > > > > > > > > > We may also have to modify bashrc / bashprofile for >> > > population >> > > > > any >> > > > > > > > > > variables that are required. >> > > > > > > > > > >> > > > > > > > > > @dev, please put in your comments / suggestion. >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > Thanks, >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > Aniruddha >> > > > > > > > > > >> > > > > > > > > > On Wed, Feb 10, 2016 at 1:16 AM, Thomas Weise < >> > > > > > > [email protected]> >> > > > > > > > > > wrote: >> > > > > > > > > > >> > > > > > > > > > > --> >> > > > > > > > > > > >> > > > > > > > > > > On Tue, Feb 9, 2016 at 9:05 AM, Chinmay Kolhatkar < >> > > > > > > > > > [email protected] >> > > > > > > > > > > > >> > > > > > > > > > > wrote: >> > > > > > > > > > > >> > > > > > > > > > > > Hello Everyone!! >> > > > > > > > > > > > >> > > > > > > > > > > > Continuing with packaging effort (rpm+deb) of apex, >> > here >> > > > are >> > > > > > some >> > > > > > > > > > > proposals >> > > > > > > > > > > > about package structure etc.. >> > > > > > > > > > > > Before posting it on bbigtop mailing list, I have >> some >> > > > > question >> > > > > > > for >> > > > > > > > > > apex >> > > > > > > > > > > > community. >> > > > > > > > > > > > >> > > > > > > > > > > > Proposed Directory structure of apex package for >> both >> > > deb & >> > > > > > rpm: >> > > > > > > > > > > > >> > > > > > > > > > > > /usr/lib/apex/bin/dtcli >> > > > > > > > > > > > /usr/lib/apex/lib/apex-api-<version>.jar >> > > > > > > > > > > > /usr/lib/apex/lib/apex-engine-<version>.jar >> > > > > > > > > > > > /usr/lib/apex/lib/apex-bufferserver-<version>.jar >> > > > > > > > > > > > /usr/lib/apex/lib/apex-common-<version>.jar >> > > > > > > > > > > > /usr/lib/apex/lib/<other dependent jars> >> > > > > > > > > > > >> > > > > > > > > > > /usr/bin/dtcli -> /usr/lib/apex/bin/dtcli >> > > > > > > > > > > > /usr/share/doc/man/man1/dtcli.1.gz >> > > > > > > > > > > > /usr/share/doc/apex/license/LICENSE.txt >> > > > > > > > > > > > /usr/share/doc/apex/license/<package>-LICENSE.txt >> > > > > > > > > > > > /usr/share/doc/apex/CHANGELOG >> > > > > > > > > > > > /usr/share/doc/apex/NOTICE >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > <version> = 3.3.0-incubating. >> > > > > > > > > > > > <other dependent jars> = All the 3rd party jars >> which >> > are >> > > > > > > required >> > > > > > > > > for >> > > > > > > > > > > apex >> > > > > > > > > > > > to run. Usually the dependencies are packaged as >> part >> > of >> > > > > > rpm/deb >> > > > > > > by >> > > > > > > > > any >> > > > > > > > > > > > software in bigtop. >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > Can you specify what those jars are in Bigtop context? >> > Same >> > > > as >> > > > > > > > shipped >> > > > > > > > > > with >> > > > > > > > > > > DT community addition under lib/ ? >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > > <package LICENSE> = Licenses of corresponding of 3rd >> > > party >> > > > > jars >> > > > > > > > which >> > > > > > > > > > > needs >> > > > > > > > > > > > to included while packaging. >> > > > > > > > > > > > >> > > > > > > > > > > > Questions related to this: >> > > > > > > > > > > > 1. Should we call the cli of apex as "apex" instead >> of >> > > > > "dtcli" >> > > > > > in >> > > > > > > > > > bigtop >> > > > > > > > > > > > package? >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > I think we should keep the name until we are able to >> > change >> > > > it >> > > > > in >> > > > > > > > Apex. >> > > > > > > > > > > Otherwise this may get confusing. >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > > 2. I see that all softwares in bigtop have man page >> for >> > > > their >> > > > > > > > > > > executables. >> > > > > > > > > > > > I think we should have it too for dtcli. Is there >> any >> > > > > > > documentation >> > > > > > > > > > > which I >> > > > > > > > > > > > can convert to man page? or can I use output of >> "dtcli >> > > > > --help"? >> > > > > > > > > > > > 3. Do we want to call version of apex in Bigtop as >> > 3.3.0 >> > > OR >> > > > > > > > > > > > 3.3.0-incubating? >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > Has to be -incubating >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > > 4. Is it ok for apex package of bigtop to depend on >> > 2.7.1 >> > > > > > > version >> > > > > > > > of >> > > > > > > > > > > > bigtop hadoop? Any problems that we see with this >> > > > dependency? >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > Should work without changed. I thought we certified >> > against >> > > > > > 2.7.0? >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > > 5. Following is the apache mirror from which bigtop >> > will >> > > > pick >> > > > > > the >> > > > > > > > > apex >> > > > > > > > > > > > source for compilation and packaging. Please >> correct if >> > > > > > > incorrect: >> > > > > > > > > > > > >> > > > > http://apache.osuosl.org/incubator/apex/v3.3.0-incubating/ >> > > > > > > > > > > > NOTE: apache.osuosl.org is the mirror used by >> all >> > > the >> > > > > > > > softwares >> > > > > > > > > in >> > > > > > > > > > > > bigtop. >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > Please share your opinion. >> > > > > > > > > > > > >> > > > > > > > > > > > Thanks, >> > > > > > > > > > > > Chinmay. >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > On Mon, Feb 8, 2016 at 11:19 AM, Chinmay Kolhatkar < >> > > > > > > > > > > > [email protected]> >> > > > > > > > > > > > wrote: >> > > > > > > > > > > > >> > > > > > > > > > > > > Yes.. Starting to work on the packaging. >> > > > > > > > > > > > > >> > > > > > > > > > > > > I've already started discussion on bigtop dev >> mailing >> > > > list >> > > > > > for >> > > > > > > > > > > > > integration. Also created a Jira for the same. For >> > this >> > > > > > > > communities >> > > > > > > > > > > > > reference, here is the bigtop Jira: BIGTOP-2313. >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > On Mon, Feb 8, 2016 at 1:13 AM, Thomas Weise < >> > > > > > > > > [email protected] >> > > > > > > > > > > >> > > > > > > > > > > > > wrote: >> > > > > > > > > > > > > >> > > > > > > > > > > > >> Chinmay, >> > > > > > > > > > > > >> >> > > > > > > > > > > > >> I don't see anything under prerequisites that >> would >> > > be a >> > > > > > > > problem. >> > > > > > > > > We >> > > > > > > > > > > > >> looked >> > > > > > > > > > > > >> at the ASF licencing compatibility as part of >> > becoming >> > > > an >> > > > > > > > > incubator >> > > > > > > > > > > > >> project. >> > > > > > > > > > > > >> >> > > > > > > > > > > > >> Please focus on the packaging during the next >> weeks. >> > > > Since >> > > > > > the >> > > > > > > > > work >> > > > > > > > > > > will >> > > > > > > > > > > > >> be >> > > > > > > > > > > > >> part of Bigtop, related discussions and JIRAs >> should >> > > > also >> > > > > be >> > > > > > > > > there. >> > > > > > > > > > > > >> >> > > > > > > > > > > > >> Would be good to have the packaging in place by >> end >> > > Feb. >> > > > > > > > > > > > >> >> > > > > > > > > > > > >> Thanks, >> > > > > > > > > > > > >> Thomas >> > > > > > > > > > > > >> >> > > > > > > > > > > > >> >> > > > > > > > > > > > >> On Thu, Feb 4, 2016 at 10:14 AM, Chinmay >> Kolhatkar < >> > > > > > > > > > > > >> [email protected]> >> > > > > > > > > > > > >> wrote: >> > > > > > > > > > > > >> >> > > > > > > > > > > > >> > Hi All, >> > > > > > > > > > > > >> > >> > > > > > > > > > > > >> > We're planning a work on adding Apache Apex as >> a >> > > > > component >> > > > > > > to >> > > > > > > > > > Apache >> > > > > > > > > > > > >> > Bigtop. >> > > > > > > > > > > > >> > Bigtop is the packaging system for the Apache >> big >> > > data >> > > > > > > > > ecosystem. >> > > > > > > > > > > > >> Several >> > > > > > > > > > > > >> > Hadoop distros use it, most recently EMR. >> > > > > > > > > > > > >> > >> > > > > > > > > > > > >> > Here is the tracking Jira task in APEXCORE for >> the >> > > > same: >> > > > > > > > > > > > >> > >> > https://issues.apache.org/jira/browse/APEXCORE-331 >> > > > > > > > > > > > >> > >> > > > > > > > > > > > >> > Proposed plan of execution is as follows: >> > > > > > > > > > > > >> > *Step 1) Handle prerequisites* >> > > > > > > > > > > > >> > Apache bigtop has some hard and soft >> expectation >> > for >> > > > new >> > > > > > > > > > components >> > > > > > > > > > > to >> > > > > > > > > > > > >> get >> > > > > > > > > > > > >> > integrated into Bigtop. >> > > > > > > > > > > > >> > Here is the list of it: >> > > > > > > > > > > > >> > >> > > > > > > > > > > > >> > >> > > > > > > > > > > > >> >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> https://cwiki.apache.org/confluence/display/BIGTOP/Requirement+for+adding+a+new+component+to+Bigtop+distribution >> > > > > > > > > > > > >> > >> > > > > > > > > > > > >> > Most of them seems to be standard ASF based >> > > > > requirements, >> > > > > > > but >> > > > > > > > > few >> > > > > > > > > > > need >> > > > > > > > > > > > >> to >> > > > > > > > > > > > >> > be checked for: >> > > > > > > > > > > > >> > 1. Software projects are expected to be >> Licensed >> > > under >> > > > > > > Apache >> > > > > > > > > > > License, >> > > > > > > > > > > > >> > Version 2.0 (and their dependencies are >> expected >> > to >> > > be >> > > > > > > > > compatible >> > > > > > > > > > > with >> > > > > > > > > > > > >> this >> > > > > > > > > > > > >> > license) >> > > > > > > > > > > > >> > - Apex is under ASL 2.0 but need to check >> if >> > > > > > > dependencies >> > > > > > > > of >> > > > > > > > > > > Apex >> > > > > > > > > > > > >> are >> > > > > > > > > > > > >> > compatible with ASL 2.0. This I guess would be >> a >> > > > > > > verification >> > > > > > > > > > check. >> > > > > > > > > > > > >> > 2. Software projects are expected to be >> compatible >> > > > with >> > > > > > all >> > > > > > > of >> > > > > > > > > the >> > > > > > > > > > > > >> > supported platforms that Bigtop distribution is >> > > > > targeting >> > > > > > > > > > > > >> > - This needs verifying whether our software >> > runs >> > > > > fine >> > > > > > in >> > > > > > > > > > > centos-6 >> > > > > > > > > > > > >> > centos-7 fedora-20 ubuntu-14.04 debian-8 >> > > > opensuse-13.2. >> > > > > > > > > > > > >> > 3. What smoke tests that should be added for >> > > > deployment. >> > > > > > > > > > > > >> > 4. Identifying the test artifacts which goes >> > beyond >> > > > > smoke >> > > > > > > test >> > > > > > > > > > > > >> > - These are basically the integration tests >> > for >> > > > > > > > verification >> > > > > > > > > > > after >> > > > > > > > > > > > >> the >> > > > > > > > > > > > >> > deployment. This is a soft requirement, but >> aim is >> > > to >> > > > > > > achieve >> > > > > > > > > this >> > > > > > > > > > > as >> > > > > > > > > > > > >> well >> > > > > > > > > > > > >> > or at least have explanation why not to >> include. >> > > > > > > > > > > > >> > >> > > > > > > > > > > > >> > If there are any from the link which explicitly >> > > needs >> > > > to >> > > > > > be >> > > > > > > > > > checked >> > > > > > > > > > > > >> other >> > > > > > > > > > > > >> > than above 4, please let us know. >> > > > > > > > > > > > >> > >> > > > > > > > > > > > >> > *Step 2) Adding Apex as component to Bigtop* >> > > > > > > > > > > > >> > From one of the mail archive of Bigtop, it was >> > > learnt >> > > > > that >> > > > > > > the >> > > > > > > > > > > bigtop >> > > > > > > > > > > > >> > community want to see the addition of new >> > components >> > > > in >> > > > > > > > phases. >> > > > > > > > > > Here >> > > > > > > > > > > > are >> > > > > > > > > > > > >> > the phases: >> > > > > > > > > > > > >> > 1. Packaging >> > > > > > > > > > > > >> > - This needs creating of package i.e. rpm & >> > deb >> > > > > files. >> > > > > > > > > > > > >> > - documentations/READMEs, LICENSE, >> DISCLAMER, >> > > > NOTES >> > > > > > etc >> > > > > > > if >> > > > > > > > > any >> > > > > > > > > > > > >> needed. >> > > > > > > > > > > > >> > - Any documentation that need to be added >> to >> > > > > > > distribution >> > > > > > > > of >> > > > > > > > > > our >> > > > > > > > > > > > >> > software. >> > > > > > > > > > > > >> > - Any license information of dependencies >> > > required >> > > > > to >> > > > > > be >> > > > > > > > > added >> > > > > > > > > > > to >> > > > > > > > > > > > >> > package >> > > > > > > > > > > > >> > 2. Smoke tests (at very least) >> > > > > > > > > > > > >> > - Adding smoke test for packaging. >> > > > > > > > > > > > >> > 3. Puppet recipes for automatic deployment and >> > > > > > configuration >> > > > > > > > > > > > >> > - Add puppet recipes for automatic >> deployment >> > > > > > > > > > > > >> > 4. Integration tests >> > > > > > > > > > > > >> > - For verification of deployments. >> > > > > > > > > > > > >> > 5. license clearance: >> > > > > > > > > > > > >> > Run 'gradle rat' to make sure all new >> stuff is >> > > > > > compliant >> > > > > > > > > with >> > > > > > > > > > > ASF >> > > > > > > > > > > > >> > license requirements. If you add code licenses >> > under >> > > > > > > different >> > > > > > > > > > > > licenses, >> > > > > > > > > > > > >> > those would need to be listed in the NOTICE. >> > > > > > > > > > > > >> > >> > > > > > > > > > > > >> > Please share your thoughts on the approach. >> > > > > > > > > > > > >> > We'll start corresponding communication on >> bigtop >> > > > > mailing >> > > > > > > list >> > > > > > > > > as >> > > > > > > > > > > > well. >> > > > > > > > > > > > >> > >> > > > > > > > > > > > >> > We have some specific questions/suggestions >> > related >> > > to >> > > > > > what >> > > > > > > > > should >> > > > > > > > > > > be >> > > > > > > > > > > > >> the >> > > > > > > > > > > > >> > content of the package and what should be the >> > smoke >> > > > > tests, >> > > > > > > but >> > > > > > > > > in >> > > > > > > > > > > the >> > > > > > > > > > > > >> > interest of not having too much content here, >> > we'll >> > > > put >> > > > > > the >> > > > > > > > > > > questions >> > > > > > > > > > > > >> as a >> > > > > > > > > > > > >> > separate mail in this mailthread. >> > > > > > > > > > > > >> > >> > > > > > > > > > > > >> > Thanks, >> > > > > > > > > > > > >> > Chinmay. >> > > > > > > > > > > > >> > >> > > > > > > > > > > > >> >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> >
