(This is only brainstorming.)
I like Metron's documentation. There has been effort and care taken there.
Ambari is nice, but given that mpack is moving behind a paywall then it seems
that the groups benefiting from the paywall can chip in to build Metron mpacks
at their leisure.
Elasticsearch
I think the difference is the maintenance of the core of metron that *has*
to be, and other things that may still be done, but will be worked on for
their merits or by community need and not be required for everything
On April 21, 2020 at 10:29:24, Justin Leet (justinjl...@gmail.com) wrote:
How
How we install depends on what we're choosing to keep around. My concern is
getting core Metron's scope down to a supportable level. This entire
conversation is probably just a thought experiment until we properly limit
the rest of our scope. It's putting the cart before the horse. I want to
Hi Tom -
> Do you or anyone have enough experience to judge if it is possible to
leverage Ansible as a replacement to deploy a working cluster?
Yes, I worked a lot on the Ansible mechanism in the early days of Metron.
This was the primary deployment mechanism before we had the Ambari MPack.
We
Hi Nick,
I see there is a lot of work done using Ansible in the repository. Do you or
anyone have enough experience to judge if it is possible to leverage Ansible as
a replacement to deploy a working cluster?
Now that I am typing this out, I wonder if docker might be a solution that
would
This is a good discussion and one that I haven't fully grappled with in my
own mind yet. I'll have more to add, but I just want to chime in on the
topic of Ambari at this point.
### Ambari and the Paywall
The problem with Ambari is that its installation mechanism requires a
repository of
- Dropping Ambari.
I like the progress that Apache did with Ambari in 2.7. And I don't know a
better installer/manager for all the services (we use other Hadoop eco
services besides Metron).
Sometimes its buggy, agents get stuck or server needs reboot from time to
time, mpacks brake some
This is a bit off the top of my head, but I'd I agree with pretty much all
of points on what's bringing a lot of overhead. There's probably also a
worthwhile discussion about what value we're shooting for the project to
provide to people that influences what stays/goes.
Thinking out loud a bit
To me Metron is big and broad in the scope of technology required to get it
running. If things were more modular that would go a long way to reducing the
learning curve or at least putting it into smaller bites (and it might
encourage more people to get involved).
If the UI were an add-on
As far as I know there is no minimum bar of development activity to keep a
project open. I think we would all be grateful for any investment that you
or your organization would want to make.
It also occurs to me that your observation is absolutely spot on: we have a
LOT of moving parts.
I see
Hi Casey,
It is still possible to make this project alive and take it forward. The
major challenges I am facing at the moment is deploying machine learning
models.
I see the project still has potential to be made better
There is opportunity to change the way we deploy and serve models.
There is
Hi Casey,
I'm new here and new to contributing to an open source project. Thus far my
contribution has been questions, however the steep learning curve has had me
working to understand all the moving parts for the last 18 months and I see
that as a big investment by my organization.
What is a
Hi all,
When composing the board report today, I realized that we have effectively
had no development in the last quarter on this project. Please be aware
that I say this without a shred of blame or judgement (especially so
considering I have not contributed in a long time). That being said, I
13 matches
Mail list logo
