Re: [DISCUSS] Slack Channel Use

2018-11-12 Thread Otto Fowler
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

Re: [DISCUSS] Slack Channel Use

2018-11-12 Thread zeo...@gmail.com
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

Re: [DISCUSS] Slack Channel Use

2018-11-12 Thread Casey Stella
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

Re: [DISCUSS] Slack Channel Use

2018-11-12 Thread 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 Justin Leet > wrote: > > > I wanted to add back onto this thread after putting some more thought > into > > it. > > > > I like Slack for the

Re: [DISCUSS] Slack Channel Use

2018-11-12 Thread Michael Miklavcic
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,

Re: [DISCUSS] Slack Channel Use

2018-11-12 Thread Nick Allen
+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

Re: [DISCUSS] Slack Channel Use

2018-11-12 Thread Scott C. Cote
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

Re: [DISCUSS] Knox SSO feature branch review and features

2018-11-12 Thread Simon Elliston Ball
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

Re: [DISCUSS] Knox SSO feature branch review and features

2018-11-12 Thread Sandeep Moré
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

Re: [DISCUSS] Slack Channel Use

2018-11-12 Thread Justin Leet
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?",

Re: [DISCUSS] Knox SSO feature branch review and features

2018-11-12 Thread Ryan Merriman
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

Re: [DISCUSS] Knox SSO feature branch review and features

2018-11-12 Thread Ryan Merriman
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 -