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