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 11:4
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
being kept (
Piling on, +1 to what Justin said.
On Mon, Nov 12, 2018 at 12:42 PM Michael Miklavcic <
michael.miklav...@gmail.com> wrote:
> 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
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
> wrote:
>
> > I wanted to add back onto this thread after putting some more thought
> into
> > it.
> >
> > I like Slack for the ty
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
> it.
>
> 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
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 conversati
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+Provider
and specifically
https://knox.apache.org/books/knox-1-0-0/dev-guide.html#Rewrite+Steps is a
startin
Hello Ryan,
I am still catching up on the architecture so let me know if I am
misunderstanding anything.
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 o
I wanted to add back onto this thread after putting some more thought into
it.
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?", "Anybod
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 <
si...@simonellistonball.com> wrote:
> Doing the Knox proxy work
Doing the Knox proxy work first certainly does make a lot of sense vs the
SSO first approach, so I'm in favour of this. It bypasses all the anti-CORS
proxying stuff the other solution needed by being on the same URL space.
Is there are reason we're not re-writing the asset link URLs in Knox? We
sh
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 -
https://node1
13 matches
Mail list logo
