The long and the short of it is that I don't think there is likely
to be much more time invested in enhancing, upgrading, or expanding the
Ambari MPack features for Metron from this point on. We have many users
that currently depend on the installation process, and I think the option
should continue to exist, but we should start the process of decoupling our
installation from Ambari.


That seems like just the short of it.  Why don’t you think it is likely
more time will be used on mpack?

Can you elaborate?



On March 29, 2019 at 13:12:53, Michael Miklavcic (
michael.miklav...@gmail.com) wrote:

Hi devs,

I wanted to kickstart a high level discussion on what the future of
development on Ambari MPacks and upgrades will/should look like ongoing for
Metron. The long and the short of it is that I don't think there is likely
to be much more time invested in enhancing, upgrading, or expanding the
Ambari MPack features for Metron from this point on. We have many users
that currently depend on the installation process, and I think the option
should continue to exist, but we should start the process of decoupling our
installation from Ambari.

I propose that we extract and decouple our install python scripts that are
in the MPack. We're already executing on decoupling our core platform code
wrt Storm. The scripts are already pretty well modularized, but we'll want
to replace some of the core Ambari features we currently depend on with our
own implementations. I'll emphasize that this refactoring should not and
cannot break the Ambari install, at least for now - my thought is that
validation would include a successful deployment with fulldev and the
Amazon EC2 cloud deployment script. We can re-evaluate what long term
support for Ambari will look like at a later time. For now, I want to
emphasize that this is just to enable flexibility.

The other nut to crack here is upgrades, and more to the point of why I'm
starting this thread in the first place. We've talked about it a while now,
and I think it's about time we got serious about paving the way to making
upgrades easier. I think we should make this process a pluggable set of
scripts as well. And from there, the community can plug that into whatever
cluster management software they wish.

Does this sound reasonable? I'm eager to hear everyone's thoughts.

Best,
Mike Miklavcic

Reply via email to