For as long as we support building components from GitHub repository by
SHA, we must support the local install steps in do-component-build scripts.
Otherwise the result cannot be transitively consistent.
We should not assume a Bigtop user will be building with a BOM full of
conveniently already
Echoing both Nate and Evans, I would not limit ourselves based on the
technology used for the build.
However, I am not sure to completely follow option 3. We are doing that
already for packages. For instance if package A depends on Apache
Zookeeper., then the package A does depend on Apache
I thnk it's not a problem that container is not stateless. No matter how we
should have CI jobs that builds all the artifacts and store them as
official repos.
You point out an important thing that is the mvn install is the key feature
to propergate self patched components around. If we disable
Echoing Evans, think we should not be worried about stateless vs non-stateless
containers.., seems core idea and need to is optimize the build process and
maximize re-use whether on host or container machines or build environments.
Added sub-task with Olaf’s idea to Evans umbrella CI task,
You can easily share the artifacts with a docker shared volume
in the container EXPORT M2_HOME=/container/m2/
follwed by
docker build -v ~/.m2/ /container/m2/
This will put the mvn jars into the host rather than the guest conatainer,
so that they persist.
On Thu, Jun 18, 2015 at
I personally like the idea of including mesos, docker stuff as
options we provided to users. No doubt that these solutions can gain more
eyeballs and attract new users/contributors to the bigtop family.
As mentioned above, the use case seems still not clear yet, but there might
be a chance that
Your right Bruno , I could, but I have no need of such a thing:)
And in any case --- this thread is just about sharing ideas, letting the whole
community speak up about their opinions on the future of bigtop. it's not about
driving a particular project direction.
Bigtop is a unique
thanks andy - i agree with most of your opinions around continuing to
build
standard packages.. but can you clarify what was offensive ? must be a
misinterpretation somewhere.
Sure.
A bit offensive.
gridgain or spark can do what 90% of the hadoop ecosystem already does,
supporting streams,
On 06/15/2015 09:22 AM, jay vyas wrote:
Hi folks. Every few months, i try to reboot the conversation about
the next generation of bigtop.
There are 3 things which i think we should consider : A backplane
(rather than deploy to machines, the meaning of the term ecosystem
in a post-spark
thanks andy - i agree with most of your opinions around continuing to build
standard packages.. but can you clarify what was offensive ? must be a
misinterpretation somewhere.
1) To be clear, i am 100% behind supporting standard hadoop build rpms that
we have now. Thats the core product and
Is it time for us to pick a resource manager?
Not if we want to be like a Debian for big data software. I'm not sure we
want to limit our reach by being overly opinionated. With my user's hat on,
if we don't package Hadoop and YARN, then I wouldn't have any use for
Bigtop.
Nowadays folks
On Mon, Jun 15, 2015 at 9:22 AM, jay vyas jayunit100.apa...@gmail.com wrote:
Hi folks. Every few months, i try to reboot the conversation about the
next generation of bigtop.
There are 3 things which i think we should consider : A backplane (rather
than deploy to machines, the meaning of
12 matches
Mail list logo
