Re: [DISCUSS] Metron Release - 0.7.1 next steps

[Tamás Fodor]

In PR#1360 we introduced a new state management strategy involving a new
module called Ngrx. We had a discussion thread on this a few months ago and
we successfully convinced you about the benefits. This is one of the
reasons why this PR is going to be still huge after cleaning up the commit
history. After you having a look at the changes and the feature itself,
there's likely have questions about why certain parts work as they do. The
thing what I'd like to point out is that, yes, it probably takes more time
to get it in.

In order to being able to release the RC, wouldn't it be an easy and quick
fix on the backend if it sent the aggregated parsers to the client as they
were one sensor? It's just an idea, it might be wrong, but at least we
shouldn't have to wait until the aforementioned PR gets ready to be merged
to the master.

On Wed, May 1, 2019 at 4:16 PM Justin Leet  wrote:

> Short version: I'm in favor of #2 of 0.7.1 and #1 as a blocker for 0.8.0.
> #3 seems like a total waste of time and effort.
>
> The wall of text version:
> I agree this isn't "just the wrong thing shown", but for completely
> different reasons.
>
> To be extremely clear about what the problem is: Our "dev" environment
> (whose very name implies the audience is develops) uses a performance-based
> advanced feature to ensure that all our of sample flows are regularly run
> and produce data. This feature has a bare minimal implementation to be
> enabled via Ambari, which it currently is by default.  This is because of
> the limited resources available that previously resulted in us turning off
> Yaf, and therefore testing it during regular full dev runs. Right now
> however, this feature is not exposed through the management UI, and
> therefore it isn't obvious what the implications are. Am I missing anything
> here?
>
> For users actually choosing to use the parser aggregation feature in a
> non-full-dev environment, I'd expect substantially more care to be involved
> given the lack of easy configuration for it (after all, why would you
> bother running the aggregated parser alongside the regular parser? This
> could be more explicitly stated, but again that feels like a doc problem.
> Right now I could essentially provide two of the same parser and create the
> same problem, so right now aggregation is only special because it runs on
> dev by default).  This is, in my opinion, primarily a first impression
> problem and likely one of many areas that could use improved documentation.
>
> Quite frankly, I think the issue pointed out here could mostly be resolved
> by documenting how the current aggregation is done in dev, and telling how
> to change it.  Especially for a 0.x.1 release, which is primarily bug
> fixes. As can be inferred from my vote, I don't think this problem is a
> problem that needs solving in a point release.  I would support improving
> the documentation, both full-dev and for aggregation in general for the
> 0.7.1 point release, while making a 0.8.0 release contingent upon the
> outstanding PRs to enable it in the management UI.
>
> There are a couple deeper issues, imo, that I care substantially more about
> than this in particular
> * The dev environment is being used as our intro for users, because it's
> convenient for us to not maintain more environments (which has been a major
> pain point in the past). Worse, the dev environment strongly implies it's
> for Metron developers, rather than people looking to build on top of
> Metron. We need an actual strategy for providing end users a clean
> impression of Metron (this could be clarifying what the expectations of
> full dev are, renaming it to something like "full-demo", something more
> involved, etc.). This is something that we've needed for awhile in general,
> and includes larger topics like improving our website, potentially
> improving the site book, actually publishing our Javadocs somewhere so
> people can develop things easier, publishing out info about Stellar
> functions in a better manner, etc.
> * The fact that parsers are handled in Ambari at all. It's awful and leads
> to situations like this. To the best of my knowledge, once we can do
> chaining and aggregation in the Management UI, we should be able to
> entirely divorce these two overlapping domains.  I'd love to see parsers
> ripped out of Ambari, then full-dev manages all the setup via REST. At that
> point, we can easily tell everyone to just use the management UI.
>
> On Wed, May 1, 2019 at 7:23 AM Otto Fowler 
> wrote:
>
> > I think it would help if the full consequences of having the UI show the
> > wrong status where listed.
> >
> > Someone trying metron, will, by default , see the wrong thing in the UI
> for
> > the ONLY sensors they have that are running and doing data.
> >
> > What happens when they try to start them to make them work? One, two or
> > all?
> > What happens when he edits them or try to add transformations? One, two
> or
> > all?
> > What other things can you do 

Re: [VOTE] Metron Release Candidate 0.7.1-RC1

[Tamás Fodor]

As Justin pointed out, we've already implemented the frontend related part
of the aggregation in https://github.com/apache/metron/pull/1360. Since
it's a very big changeset, we would like to double check it again before we
merge it back to master. Also, we're waiting for a small change in the
backend code to fully cover everything related to parser aggregation. Once
we have introduced this small patch and fully tested it manually we can
solve the issue with the aggregated sensors on the management UI.

On Sun, Apr 28, 2019 at 8:30 PM Nick Allen  wrote:

> I agree with Justin.  My +1 stands.
>
> Considering that this is a known gap, we have already released with this
> gap, and we have a backlog of numerous improvements that should be released
> to the community, I am not in favor of delaying the release.  Metron
> provides a wide variety of functionality at varying levels of maturity.
> This is to be expected.  If we expect perfection, we will never get a
> release out.
>
>
> On Sat, Apr 27, 2019 at 6:12 PM Justin Leet  wrote:
>
> > Mike is correct, that is because of the combination of full dev
> > restrictions and the lack of support in the configuration UI for parser
> > aggregation.  This was introduced in
> > https://github.com/apache/metron/pull/1207 and also was true of the last
> > release. Currently, parser aggregation is an advanced/manual feature
> whose
> > (bare minimum) configuration can be done via Ambari, out of convenience.
> >
> > I haven't looked into it, but https://github.com/apache/metron/pull/1360
> > is
> > likely the work for this (and need additional work before merging).
> >
> > I'm personally letting my binding +1 stand, although I would support
> either
> > ensuring we get that PR cleaned up and in and/or additional documentation
> > regarding the current limitations of this feature.
> >
> >
> > On Sat, Apr 27, 2019 at 2:38 PM Anand Subramanian <
> > asubraman...@hortonworks.com> wrote:
> >
> > > I can confirm that I've seen the Mgmt UI shows the sensor status
> > correctly
> > > when they run as single topologies.
> > >
> > > -Anand
> > >
> > > On 4/27/19, 11:37 PM, "Michael Miklavcic" <
> michael.miklav...@gmail.com>
> > > wrote:
> > >
> > > I believe that is bc of parser aggregation. The UI does not support
> > it
> > > currently. IIRC there was a PR to change the bro, snort, and yaf
> > > sensors to
> > > aggregated bc full dev didn't have enough resources. The upshot is
> > > that the
> > > UI still works for single sensors, but the feature for enabling
> > > aggregated
> > > sensors has not yet been completed.
> > >
> > > On Sat, Apr 27, 2019, 11:33 AM Otto Fowler <
> ottobackwa...@gmail.com>
> > > wrote:
> > >
> > > > -1
> > > >
> > > > Ran the script and ran full dev, all good.
> > > > In the configuration ui, the status of the sensors is not
> correct.
> > > It
> > > > does not show any running, but they are running in storm and the
> > > data was
> > > > moved correctly.
> > > >
> > > >
> > > > On April 26, 2019 at 09:58:02, Otto Fowler (
> > ottobackwa...@gmail.com)
> > > > wrote:
> > > >
> > > > Curious Anand,
> > > > are your steps for bringing up an open stack cluster something we
> > > could
> > > > script like the AWS stuff?
> > > >
> > > >
> > > > On April 26, 2019 at 09:35:29, Anand Subramanian (
> > > > asubraman...@hortonworks.com) wrote:
> > > >
> > > > +1 (non-binding)
> > > >
> > > > * Built RPMs and mpacks.
> > > > * Brought up Metron stack on 12-node CentOS 7 openstack cluster.
> > > > * Ran sensor-stubs and validated events in the Alerts UI for the
> > > default
> > > > sensors.
> > > > * Management UI, Alerts UI and Swagger UI sanity check
> > > >
> > > > Regards,
> > > > Anand
> > > >
> > > > On 4/26/19, 5:18 AM, "Nick Allen"  wrote:
> > > >
> > > > +1 Verified release with all documented steps and ran up Full
> Dev.
> > > >
> > > > On Thu, Apr 25, 2019 at 6:10 PM Michael Miklavcic <
> > > > michael.miklav...@gmail.com> wrote:
> > > >
> > > > > Ok cool, just finished the validation and updated the steps in
> > the
> > > doc to
> > > > > reflect the current code base.
> > > > >
> > > > > On Thu, Apr 25, 2019 at 3:45 PM Nick Allen  >
> > > wrote:
> > > > >
> > > > > > No voting required. Those are just docs. Whoever is willing
> to
> > > correct
> > > > > > and has access, should be able to. Good catch.
> > > > > >
> > > > > > On Thu, Apr 25, 2019 at 4:32 PM Michael Miklavcic <
> > > > > > michael.miklav...@gmail.com> wrote:
> > > > > >
> > > > > > > We're also not "incubator-metron" any longer. Do we require
> > > any kind
> > > > of
> > > > > > > voting or +1 on that verification page to make corrections
> to
> > > it?
> > > > > > >
> > > > > > > On Thu, Apr 25, 2019 at 2:29 PM Michael Miklavcic <
> > > > > > > 

Re: [DISCUSS] Add ngrx to handle state management in Angular

[Tamás Fodor]

Personally, I prefer following the flux approach because having one store
as a single source of truth makes a complex web app more predictable and
easier to reason about.
In angular we can easily achieve this by using NgRx which supports the
unidirectional data flow by involving pure functions that hold the business
logic and it it's extremely simple to test them. With NgRx we could also
have separated functions to manage side effects like http requests. Not to
mention the aforementioned awesome Redux toolbar to see how the data flows
trough the application.
This approach has been proven over the years and perfected by many other
developers. Onboarding new members in team has never been easier, since,
instead of spending a lot of time to come up with our own solution and
write a documentation or a usage guide, new devs can find tons of resources
about best practices on the Internet.
NgRx also forces developers to keep the state immutable which is a very
important ingredient of the whole story. By having an immutable data
structures we can get the most out of Angular's rendering capabilities by
setting the proper change detection strategy. We can simply avoid a lot of
unnecessary re-renders and difference calculations between the previous and
the new state. If we use immutable state Angular can compare it by
reference checking which is extremely fast. If the data has the same memory
pointer as the previous data it simply skips the reconciliation process for
a certain part of the (or the entire) component tree.

On Wed, Nov 28, 2018 at 10:48 AM Tibor Meller 
wrote:

> NgRx also makes testing easier and the architecture more straightforward.
> Components in a Redux/NgRx architecture only responsible for rendering and
> dispatching events.
> All the data alternation implemented in pure functions so-called effects
> and reducers.
> No intertwined components, side effects just easily testable pure
> functions.
>
> +1 (non-binding)
>
> On Tue, Nov 27, 2018 at 5:09 PM Shane Ardell 
> wrote:
>
> > There are a couple of good examples in Metron Alerts showing different
> > advantages we would gain using NgRx. First, you’ll notice that a lot of
> > state does not persist between view changes. For example, if a user
> inputs
> > search criteria into the search bar, switches to the PCAP view, then
> > switches back, that search input is not persisted. If we used NgRx, the
> > application store can persist this state between view changes if we
> wanted
> > to. The importance of this will continue to become more apparent as the
> > application scales up and different views are added.
> >
> > In addition, there is quite a bit of shared application data between
> > components. For example, you’ll see that both the GroupByComponent and
> > AlertFiltersComponent display the number of facets available. When you
> > filter by a facet, these numbers update. You can filter by clicking on
> the
> > facets available in the AlertFiltersComponent, or you can search with a
> > filter keyword and value in the search bar. Multiple areas of the
> > application are showing the same data, and multiple areas of the
> > application are manipulating that data. While passing data through @Input
> > and @Output decorators and services is fine for basic sharing of
> > application data, you’ll eventually create a complex web of data sharing
> > and mutation that can be hard to follow and debug. In my opinion, we are
> > nearing that point in our application. NgRx solves this with its
> > one-direction data flow and immutable data structures. The store is the
> > single source of truth which your component derives state from rather
> than
> > having components holding their own state and having to manage,
> communicate
> > and pass data between them.
> >
> > There are also many debugging advantages. I don’t have a specific example
> > at the moment, but you can probably imagine how much easier it is to
> “time
> > travel” with NgRx debugging tools. What I mean by “time travel” is the
> > ability to move back and forth among the previous application states and
> > view the results in real-time rather than setting a breakpoint, reloading
> > the application, inspecting, setting another breakpoint to inspect a
> state
> > previous to your current breakpoint, reloading the application, etc. This
> > is a very repetitive and time-consuming thing to do when debugging on the
> > front-end, and is very common. For a visual example of this, here is a
> > video containing a decent overview of debugging with NgRx:
> > https://www.youtube.com/watch?v=70ojPxMA7Ig
> >
> > On Tue, Nov 27, 2018 at 5:30 AM James Sirota  wrote:
> >
> > > I found a helpful article here:
> > > https://brianflove.com/2018/01/08/ngrx-the-basics/
> > >
> > > A lot of this goes over my head, but in a nutshell, it's a tree-based
> > > state management object for JS.  Its main drawback seems to be added
> > > complexity, but if the guys who are more familiar with UI say we would
> > > 

Re: [ANNOUNCE] Shane Ardell is a committer

[Tamás Fodor]

Congratulations Shane! 

On Mon, Nov 19, 2018 at 5:58 PM Mohan Venkateshaiah <
mvenkatesha...@hortonworks.com> wrote:

> Congrats Shane !!
>
> Thanks
> Mohan DV
>
> On 11/19/18, 10:26 PM, "Michael Miklavcic" 
> wrote:
>
> Congrats!
>
> On Mon, Nov 19, 2018 at 8:56 AM Shane Ardell  >
> wrote:
>
> > I want to extend a huge thank you to everyone part of Apache
> Metron's PMC
> > for offering me this opportunity!
> >
> > Cheers,
> > Shane
> >
> > On Mon, Nov 19, 2018 at 4:53 PM zeo...@gmail.com 
> wrote:
> >
> > > Congrats Shane!
> > >
> > > Jon
> > >
> > > On Mon, Nov 19, 2018 at 10:43 AM Anand Subramanian <
> > > asubraman...@hortonworks.com> wrote:
> > >
> > > > Many congratulations, Shane!
> > > >
> > > > Cheers,
> > > > Anand
> > > >
> > > > On 11/19/18, 8:36 PM, "James Sirota"  wrote:
> > > >
> > > >
> > > > The Project Management Committee (PMC) for Apache Metron has
> > invited
> > > > Shane Ardell to become a committer and we are pleased to
> announce that
> > he
> > > > has accepted.  I wanted to congratulate Shane on this
> achievement.
> > > >
> > > >
> > > > Being a committer enables easier contribution to the project
> since
> > > > there is no need to go via the patch submission process. This
> should
> > > enable
> > > > better productivity. Being a PMC member enables assistance with
> the
> > > > management and to guide the direction of the project.
> > > > ---
> > > > Thank you,
> > > >
> > > > James Sirota
> > > > PMC- Apache Metron
> > > > jsirota AT apache DOT org
> > > >
> > > >
> > > >
> > > > --
> > >
> > > Jon Zeolla
> > >
> >
>
>
>

Re: [DISCUSS] Add ngrx to handle state management in Angular

[Tamás Fodor]

That is a great idea!

+1

On Mon, Nov 26, 2018 at 10:19 AM Tibor Meller 
wrote:

> Shane, Thanks for gathering the information and raising this.
> I also feel that our UIs reached a level of complexity what makes this to a
> reasonable next step.
> This complexity on the client side will grow in the future and I believe it
> is better to prepare instead of trying to make huge refactorings later.
> NgRx/Redux is quiet the industry standard architectural library in both
> React and Angular realm. Pretty well known in the community.
> I would be happy to move forward with NgRx.
>
> On Fri, Nov 23, 2018 at 3:44 PM Shane Ardell 
> wrote:
>
> > What I'm referring to is roughly the entire contents of the UI
> > application's memory.
> >
> > On Thu, Nov 22, 2018 at 6:29 PM Otto Fowler 
> > wrote:
> >
> > > Can you describe what you mean by “state” in a little more detail?
> Not a
> > > complete description, maybe just a crib list.
> > >
> > >
> > > On November 22, 2018 at 07:21:43, Shane Ardell (
> shane.m.ard...@gmail.com
> > )
> > > wrote:
> > >
> > > As both the Management and Alerts UI grow in size, managing application
> > > state continues to become more and more complex. To help us deal with
> > > managing all of this state and ensuring our application derives state
> > from
> > > a single source of truth, I suggest we start using NgRx, a state
> > > management
> > > library based on the Redux pattern but built for Angular. It is by far
> > the
> > > most popular library of this type for Angular. As you can see in the
> > > project's GitHub Insights tab  >,
> > > it's quite actively worked on and releases are pretty frequent. The
> > > project
> > > is licensed under MIT.
> > >
> > > As far as an approach to integration, I don't think we necessarily
> need a
> > > big refactoring right off the bat. I feel something like this can be
> done
> > > in a piecemeal approach over time. I think we can start by introducing
> it
> > > into the project the next time we have a new application feature.
> > >
> > > What are everyone's thoughts around this?
> > >
> > > Cheers,
> > > Shane
> > >
> > >
> >
>

Re: [DISCUSS] Switching to a better alternative of Pikaday.js

[Tamás Fodor]

Organizing the codebase as a monorepo could be a good idea to address it.

There's a popular and very powerful tool called Lerna
<https://github.com/lerna/lerna> to maintain a monorepo:

"Splitting up large codebases into separate independently versioned
packages is extremely useful for code sharing. However, making changes
across many repositories is messy and difficult to track, and testing
across repositories gets complicated really fast.
To solve these (and many other) problems, some projects will organize their
codebases into multi-package repositories (sometimes called monorepos).
Projects like Babel, React, Angular, Ember, Meteor, Jest, and many others
develop all of their packages within a single repository.
Lerna is a tool that optimizes the workflow around managing multi-package
repositories with git and npm.
Lerna can also reduce the time and space requirements for numerous copies
of packages in development and build environments - normally a downside of
dividing a project into many separate NPM package."

To me, it seems to be a good approach to deal with what we have in the
metron-interface folder. It forces you to write independent and focused
packages regarding the single responsibility responsible. You can easily
share them across the alerts and the management UI. I highly recommend you
to go through the docs and think about it.

Btw, shouldn't we register an organization on npm to publish our packages?
@hortonworks is already taken. Does it belong to us? Do you know who's got
permission to publish packages under it? Can we also have the rights to
publish?

Cheers,
Tamas

On Tue, Oct 16, 2018 at 6:50 PM Michael Miklavcic <
michael.miklav...@gmail.com> wrote:

> I'm still +1 to this approach. Thanks guys!
>
> To Tibor's other point - the management UI is currently a completely
> separate service, as I understand it. If there is infrastructure you think
> is shareable while still allowing them to be independently deployed, then I
> think it would be desirable to make improvements there also. My only
> caution would be that there are instances where early architectural
> duplication seems wasteful, but is really just a short-term illusion
> because of code maturity. ie, there are instances where you absolutely
> don't want to tie architectural components together even if it seems like
> you're duplicating code. I don't believe this fits that concern, but I
> thought it was worth mentioning. To that end, I wouldn't have your progress
> on the alerts UI improvements be hampered by the management UI. I think we
> can take the lessons learned in the Alerts UI and apply them to the
> management UI when it makes sense to.
>
> Best,
> Mike
>
>
> On Tue, Oct 16, 2018 at 2:21 AM Tibor Meller 
> wrote:
>
> > Thanks, Tamas! The plan you described seems a good approach to me.
> > Let's wait another day before we create Jira tickets from these steps to
> > make sure no one else has other concerns.
> >
> > One more question: how much of these changes could be applicable to the
> > Management UI?
> > It would be great plus to see those two UI getting closer to each other
> > with the underlying technologies instead of shifting away.
> >
> > On Tue, Oct 16, 2018 at 9:37 AM Tamás Fodor 
> wrote:
> >
> > > I'm agreeing with moving forward with Ng Bootstrap. In order to do
> that,
> > I
> > > think it would be a good start to refactor those components which use
> the
> > > obsolete jquery based vesrion of bootstrap. Shane has already started
> it
> > by
> > > refactoring the Modal dialog in the management UI (We also have this
> > > component in the alerts UI). Once we've succeeded that, we can remove
> > > (hopefully) jQuery form the dependency list.
> > > As the second step, we should migrate to Ng bootstrap. I'm assuming
> that
> > if
> > > the jquery based Boostrap is replaced with Ng bootstrap, we're still
> good
> > > since we're using only classes from the bootstrap CSS which is shared
> > > across jQuery bootstrap and Ng bootstrap.
> > > If everything is good and nothing is broken we can start working on the
> > new
> > > date/time picker component based on Ng bootstrap and then we can get
> rid
> > of
> > > Pikaday.
> > > Once Pikaday is completely eliminated from the system, we can be sure
> > that
> > > the PR about eliminating moment.js is ready to go.
> > >
> > > Cheers,
> > > Tamas
> > >
> > > On Mon, Oct 15, 2018 at 8:36 PM Michael Miklavcic <
> > > michael.miklav...@gmail.com> wrote:
> > >
> > > > I like point #3 from Tibor - you can pick and choose how you compose
> &

[DISCUSS] Switching to a better alternative of Pikaday.js

[Tamás Fodor]

I'd like to open a discussion about switching to a new date picker library
in the Metron Alerts UI regarding to the following:

https://lists.apache.org/thread.html/2e4fafa4256ce14ebcd4433420974e24962884204418ade51f0e3bfb@%3Cdev.metron.apache.org%3E

https://github.com/apache/metron/pull/1219#discussion_r223733562

A week ago, I opened a PR about removing moment.js from the code base to
decrease the size of the production javascript bundle. I could achieve 15%
loss in the final bundle size which is admittedly not a game changer but
still. Not to mention if we want to heavily rely on date manipulator
functions in the future it's better to get rid of it at this early stage.
Go here  to read more about the
background and the results. I tried to provide as many details as I could.

So far, so good. But then I stumbled upon an obstacle, Pikaday
.

Before going further, let me thank Tibor Meller, Michael Miklavcic and
Nicholas Allen for taking their time to go through my proposal to deal with
the aforementioned issue. At the end, we agreed on basically not going with
my temporary solution that intended to solve the related problems of
Pikaday and we'd rather like to find and change for a better alternative.

To be fair, Pikaday is a pretty good date picker module, its only problem
is the moment dependency if it's installed via npm. But other than that, it
functions perfectly. Zero dependencies, small, etc. Long story short, it's
good for us unless we want to get rid of moment.js.

Before making a decision on what's next, I'd to ask you a question. Is it
really a priority and is it really worth the effort to touch our currently
used date picker component to get ~15% reduction in the bundle size by
removing moment?

I'm asking it because if we want to do so, considering that it's a huge
topic, the following questions might come up:

*A: What component do we want to use instead of Pikaday?*

I'm not satisfied with the alternative individual solutions out there on
npm. I'd rather pick a component library like the angular port of Bootstrap
 or the angular material library
. Both of them have a date picker component
and many other components to rely on and reuse throughout the Metron app.

*B: What component library do we want to use?*

Introducing a new component library requires a lot of research and there
are many things we have to agreed on. Since it's a long term plan because
it would be great to use it consistently instead of picking a new one a few
months later just because we chose wrongly.

*C: What about the jQuery version of Bootstrap?*

So basically we already have a component library and we still use it but
we're also planning to replace it with another or the angular port at least
to get the most out of the angular rendering engine. Since it uses jquery,
it's much less performant than a port written in Angular.
And I think it's a bad idea to introduce a new one and use multiple
component libraries within one project.
We can also pick the date picker component from the jQuery Bootstrap but,
again, it's not as efficient as the angular port so it seems to be
beneficial to replace it with something else.

What do you think, guys?

Thanks,
Tamas

Re: Invite to Slack Channel

[Tamás Fodor]

Hello,

Michael, can you add me as well?

Thank you in advance!

Tamas

On Wed, Oct 3, 2018 at 4:27 PM Michael Miklavcic <
michael.miklav...@gmail.com> wrote:

> Sent
>
> On Wed, Oct 3, 2018 at 8:17 AM Shane Ardell 
> wrote:
>
> > Hello everyone,
> >
> > Is it possible for someone to send me an invite to the Metron Slack
> > channel?
> >
> > Regards,
> > Shane
> >
>

[DISCUSS] Replacing Moment.js with date-fns or native functions

[Tamás Fodor]

I'd like to open a discussion about replacing Moment.js
 in Alerts UI. date-fns  has
almost the same functionality to manipulate date/time in the application.
Moment.js is a great library but it has a huge footprint in the bundle and
it's significant when it comes to performance optimization in order to
decrease the initial load time.

Here you can find a brief introduction of the problem and a few ideas how
to replace it with date-fns or native functions.
https://github.com/you-dont-need/You-Dont-Need-Momentjs

*The problem:*
In order to use Moment.js, we have to import the whole library which has
significant impact on the size of the production bundle of our javascript
code.

*A few examples:*
https://github.com/apache/metron/blob/e66cfc80e6a6fa53110c3f2fa8ee0d31ea997bf6/metron-interface/metron-alerts/src/app/utils/utils.ts#L18
https://github.com/apache/metron/blob/ccdbeff5076553382091d4b9423ed48ccdba10ee/metron-interface/metron-alerts/src/app/shared/pipes/time-lapse.pipe.ts#L20

Even though, we have tree-shaking
 which is a great feature of
javascript bundlers (in our case Webpack), because of how Moment.js is
structured, it prevents the bundler from doing tree-shaking properly
.
date-fns is just fine with that
.
For example, to use the `format` functions we don't have to import the
whole library, we can import only the format function
 individually.

What do you think?

Tamas