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
