Thanks for all the points, Keith and Mike. This was very helpful to me.
I assumed formerly-known-as-Zetten was more about deploying Fluo itself,
but it seems it is more about the prerequisites for Fluo. I was just
assuming a bit too much it seems :)
While it might be a little premature before there is an official
release, I think instructions on the website for how a user
installs/configures Fluo would be great and help attract new users.
Mike Walch wrote:
Just to clarify things..
If you want to run Fluo, you need set up dependencies (Hadoop, Accumulo,
Zookeeper) and deploy/start a Fluo application on top of them. The
upcoming Apache Fluo release gives you everything you need to deploy/start
Fluo. It allows you to start Fluo as local processes or as application in
YARN. In the future, I would like to support more ways to start/deploy
Fluo (like to Mesos/Marathon, Kubernetes, etc) and have all of this code be
part of Apache Fluo (but maybe as separate repos).
Uno& Muchos handle setting up dependencies and not deployment. After you
run 'uno setup' or 'muchos setup', you will have Accumulo, Hadoop, and
Zookeeper running but you still need to use the 'fluo' command (which is
distributed with Apache Fluo) to deploy your Fluo application to YARN.
While I think we should hold off on moving Uno& Muchos to Apache Fluo, I
am open to moving them to Apache in the future if it make senses.
On Fri, Aug 5, 2016 at 11:17 AM Keith Turner<[email protected]> wrote:
On Fri, Aug 5, 2016 at 10:34 AM, Josh Elser<[email protected]> wrote:
While this does fall into ASF guidelines, I do not agree that relying on
external projects (or vendors as is often the case elsewhere) for
deploying
your software is a good idea.
I'm of the opinion that you should at least have one way in Apache Fluo
that
people can use to deploy Apache Fluo. That's just my opinion on the
matter
though :)
Sorry for the spam everyone. I just keep thinking of nuances. These
tools are also extremely useful for testing and experimenting with
just Accumulo. I use Muchos all of the time to test Accumulo RCs on
EC2 (and do nothing with Fluo).
Christopher wrote:
Good points, Mike. I agree with that position. I agree with
linking/supporting/making room for independent innovation in the area of
cluster management and integration, rather than incorporating them into
the
Apache Fluo PPMC responsibilities.
On Wed, Aug 3, 2016 at 3:32 PM Mike Walch<[email protected]> wrote:
My view is that Apache Fluo should only contain code the used to run
Fluo.
We should avoid bringing in any projects that run the entire stack (i.e
Hadoop, Accumulo, Zookeeper, etc) like fluo-dev and zetten (now called
Uno
and Muchos). While some users may find Uno/Muchos useful, others might
prefer to integrate Fluo in their own development stack or cluster
management tool.
If we move Uno/Muchos into Apache Fluo, then we should be willing to
accept
similar contributions (like a development tool that starts the Fluo
stack
in docker or vagrant or a Chef script that launches Fluo and it
dependences
on cluster). If we accept every project like this, we create a heavy
maintenance burden for Apache Fluo. If we only move Uno/Muchos and not
others, then it will look we are endorsing them over of other tools.
I would rather link to these tools from the Apache Fluo website and
give
users as many options as possible on how they want to run Fluo. There
is
so
much innovation going on in cluster management. I would rather make
room
for a several external projects compete and innovate rather than
endorse
a
certain tool (even if its the ones that I helped create).
On Wed, Aug 3, 2016 at 1:37 PM Keith Turner<[email protected]> wrote:
On Wed, Aug 3, 2016 at 12:37 PM, Josh Elser<[email protected]>
wrote:
Christopher wrote:
On Tue, Aug 2, 2016 at 3:37 PM Josh Elser<[email protected]>
wrote:
Christopher wrote:
Okay, so we've been having a long discussion regarding trademarks
as
the
project transitions from fluo.io to fluo.apache.org on the
incubator
list (
https://lists.apache.org/thread.html/69a0c4befd56240ac642c4912e7497ea53720920a459e923f5cf7e91@%3Cgeneral.incubator.apache.org%3E
).
Several issues arose, and Keith, Mike and I have been discussing
what
we
think is the best plan forward.
What we think is best:
1. Create a branch in the incubator-fluo repo for the resources,
and
do
an
Apache release of the checkstyle/formatter rules in that resources
jar.
+1
2. Update the parent POM to use that resources jar instead of the
previously released io.fluo one.
Is there are reason these resource jars were not included with the
parent pom release?
Not a very good reason. The main reason is that the released
artifact
already existed and was suitable. There's also a chicken-egg issue
that
makes things a bit annoying doing new releases of the resources
object...
because it can't depend on the parent POM. It's also versioned
separately.
But mostly, there was no immediate need for a new one any time soon
when
the current one works fine.
So would you think a new repo is appropriate for this? Would you want
to
just use the same Git repo that the parent pom exists in (put two
separate
maven projects inside)?
As far as tech goes, I don't think this is super critical, but the
feelings
aspect of it might require more immediate action.
5. Open a discussion on [email protected] to determine
whether
the
GitHub organization "fluo-io" should be renamed, and what would be
an
acceptable name for a GitHub organization containing fluo-related
3rd
party
projects. Also determine whether it is acceptable to use the
trademark
for
fluo-related extensions repository names (eg. "fluo-stress" and
"fluo-quickstart").
My feeling is that with proper distinction that "fluo-io" is not
affiliated with "Apache Fluo (incubating)" and the ASF but are
related
software projects would be fine. Admittedly, I'm not sure the
reasoning
behind wanting to keep them separate (was there a reason these were
not
included in the original donation?) and bringing them under the ASF
umbrella would make sense to me.
As discussed on the thread, some of the projects are not appropriate
for
ASF, and were not part of the original donation. I agree with your
assessment (and I also made the argument) that "fluo-io" can be
properly
distinguished from "Apache Fluo" and the ASF, with some effort. That
would
be the position we'd bring to trademarks@. But also, if we give up
the
domain "fluo.io", either by donation to ASF or by letting it lapse,
it
will
not longer make sense for the GitHub org to be called "fluo-io", and
it
might make more sense to rename it to something like "fluo-tools".
Regardless, if it has "fluo" in the name, we'll want to get it
cleared
as
an approved use of the trademark.
Yeah, I'm not sure what to recommend for maintaining such an org.
Let's
make
sure to tread very carefully. Because the maintainers/creators of
these
tools that were not brought to Apache are the PPMC now, this has the
potential to be misconstrued.
Would it be out of line for me to suggest that for the projects
currently at
github.com/fluo-io:
* Specifically decree those with no interest to maintain as such
* Make a plan to bring others into the Apache umbrella
I know this is a bit totalitarian, but I'm not sure how to avoid
further
drama over an organization of fluo-related software projects,
maintained
by
a subset of the PPMC.
This seems unnecessary to me for the following reasons :
* Not all software built on top of an Apache project needs to reside
at
Apache
* Its ok for people on the PPMC of a project work on whatever they
want outside of Apache.
* The precedents set by what we do with these projects need to scale
to any user of Fluo. I would like to avoid setting the precedent of
accepting drive by contributions of projects that build on Fluo and
are not maintained by anyone.
I think its fine for these projects to exists outside of Apache for
now and possibly move to Apache in the future if we become more
certain about their direction. I don' think we should do anything
hasty w/o a good plan.
I think the main thing we need to do in the short term is clean up
using the Fluo name in these external projects, like rename fluo-dev
to something else. Also need to rename the fluo-io github org to
something else. Zetten already has a good name. We also need to
clean up the links to the projects on the website to add proper
context (that these projects are optional and may be helpful) and
disclaimers.
We may want to move some of them, not sure yet (but again I don't
think we should hurry and set bad precedents). Also it m be best to
discuss plans for each external project individually (or in groups).
For example the need for fluo-quickstart may completely go away. I am
working on new Fluo Tour for the website and it needs a small
associated git repo (with pom and basic java code) to help people get
started quickly. I was thinking of re-purposing fluo-quickstart for
this. However, Christopher suggested that since this bit of code
will be so closely associated with web site that we could put in a
branch on the existing fluo-website repo. I really like this
solution, but Christopher pointed out that it does not make sense for
fluo-stress, phrasecount, and webindex. I agree that it does not
make sense for these.
Regardless, VP of trademarks has a much heavier weight of opinion
than
I
do. A healthy discussion sounds great.
6. Complete the PODLINGNAMESEARCH, so all this effort to protect
the
"Fluo"
trademark isn't done in vain.
+1 this isn't that hard to do either. Feel free to ask for
help/guidance.
Please help. :)
But seriously, we did create the JIRA issue, but have not yet
contributed
to documenting the fact-finding there yet.
https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-109
:) ok. Let's break this one out. I think we should get the other
items
here
done and then we can come back to the namesearch after (it's good to
get
it
done early, but not as important as the other branding concerns).
I'll go ahead and get started on item 1, because I think that
should
be
relatively easy to do.
