What we need is a slackbot where you can:
- start a discuss thread, that will get sent to email list
- listen to emails ( be on the list ) and post any discuss thread replies
not from slack TO slack
- add tagged comments to discuss thread
the list-slack singularity
On November 12, 2018 at
Spot on Justin, I totally agree. My only nit is that often it's much
easier troubleshooting in Slack as opposed to the mailing lists, so I'm
game to allow some troubleshooting in Slack as long as the issue and
resolution makes it back to the lists. Given that slack message history is
Piling on, +1 to what Justin said.
On Mon, Nov 12, 2018 at 12:42 PM Michael Miklavcic <
> I'm also +1 to Justin's points.
> On Mon, Nov 12, 2018 at 10:38 AM Nick Allen wrote:
> > +1 to all your points Justin.
> > On Mon, Nov 12, 2018 at 10:08 AM
I'm also +1 to Justin's points.
On Mon, Nov 12, 2018 at 10:38 AM Nick Allen wrote:
> +1 to all your points Justin.
> On Mon, Nov 12, 2018 at 10:08 AM Justin Leet
> > I wanted to add back onto this thread after putting some more thought
> > it.
> > I like Slack for the
Your suggestion is well received. I think what we're trying to avoid is a
big dump of Slack's stream of consciousness. There is an inherent
organization and required collection of thoughts that comes with the
dev/user list discussions that doesn't occur on Slack. Maybe threads can
help that a bit,
+1 to all your points Justin.
On Mon, Nov 12, 2018 at 10:08 AM Justin Leet wrote:
> I wanted to add back onto this thread after putting some more thought into
> I like Slack for the type of small developer "what's going on here?" type
> discussions. That's the kind of thing I like
I realize that I’m a “new kid” here, but I think you can have your cake and
eat it too…..
If I can create it, find it, or configure it, perhaps the really best way is to
be able to either:
1) dump public slack conversations to the developer thread - arbitrarily
2) dump public slack
What you're looking for is an OUT rewrite rule, and a filter rule on
content-type. It's not spectacularly well documented, but
https://knox.apache.org/books/knox-1-0-0/dev-guide.html#Rewrite+Steps is a
I am still catching up on the architecture so let me know if I am
You could have multiple serviced deployed in Knox
1. for metron (metron/api/v1)
2. for alerts-ui (metron-alerts-ui/alerts-list)
and have them run in one Knox instance and you could have
I wanted to add back onto this thread after putting some more thought into
I like Slack for the type of small developer "what's going on here?" type
discussions. That's the kind of thing I like being real-time ("Hey, full
dev is acting weird", "What's the basic layout of this stuff?",
I'm just coming up to speed on Knox so maybe rewriting assets links are
trivial. If anyone has a good example of how to do that or can point to
some documentation, please share.
On Mon, Nov 12, 2018 at 8:54 AM Simon Elliston Ball <
> Doing the Knox proxy work
Let me clarify on exposing both legacy and Knox URLs at the same time. The
base urls will look something like this:
Legacy REST - http://node1:8082/api/v1
Legacy Alerts UI - http://node1:4201:/alerts-list
Knox REST - https://node1:8443/gateway/default/metron/api/v1
Knox Alerts UI -
Mail list logo