I think that there is room for both. We need to define the usecases that need to be served.
I can see: 1. global gateway resources served by multiple webapps/topologies - especially for in the very least for branding resources, etc 2. topology/webapp specific resources served only be individual apps 3. topology/webapps that need resources from both - if this is possible On Wed, Dec 23, 2015 at 9:29 AM, Zachary Blanco <zbla...@hortonworks.com> wrote: > I like the idea! It's definitely something that's required if we're to > serve these HTML/JS/CSS files. > > Are you thinking that these files will be topology specific? Or does the > solution in your mind have the files served at the "knox-level". i.e. not > topology specific? I'm thinking that they could just be served after the > 'gateway.path', such as (https://host:port/gatewaypath/file.html). > > ________________________________________ > From: larry mccay <lmc...@apache.org> > Sent: Wednesday, December 23, 2015 7:43 AM > To: dev@knox.apache.org > Subject: Re: [DISCUSS] An Administrator UI for Knox > > Hi Zac - > > I've taken a quick look at your POC. > > You've run into the same thing that I have in that you had to specifically > code the access to the html and js files from a resources directory. > We need to open up the ability for Knox to let jetty serve those resources > just as any web app which will let jetty do what it does well, allow for > arbitrary pages, css, javscript, etc. > > I do think this is a great start and something that we can work with as a > POC to figure out the best UI experience. > > Let's file a JIRA to allow arbitrary files be served by the hosting > appserver and the ability to configure the files directory for those files. > > thanks, > > --larry > > > > On Fri, Dec 18, 2015 at 7:37 PM, Zac Blanco <zacdbla...@gmail.com> wrote: > > > Balaji, in response your first first question about what this could > provide > > over Ambari. I think that Larry made a good point about not always using > > Ambari. This could also make the ease of creating/updating/testing > > topologies much easier. Something that Ambari would not be able to > provide. > > Because the admin API is already in place this UI can easily utilize the > > API to do these updates by making simple POST/PUT/DELETE requests with > > requests directly from the browser. > > > > I also think that we could turn this into an Ambari iframe view and make > it > > appear as a "quick link" in Ambari. I know a few of the other services > have > > their own UI which can be reached from the Ambari configs too. > > > > Originally, I intended for this to be something that admins would be able > > use. It could just make setup/testing/updating the topologies in Knox > much > > smoother. The way this POC is currently implemented requires that at > least > > one topology is deployed with the admin service. To be able to reach the > UI > > you need to provide the admin credentials. > > > > I think on top of the testing tools that I had previously implemented it > > could make working with Knox (Ambari or not) much easier. > > > > However I think if we had something like swagger <http://swagger.io>for > > services as well could potentially be very useful or interesting too > > > > > > > > On Fri, Dec 18, 2015 at 6:35 PM larry mccay <larry.mc...@gmail.com> > wrote: > > > > > I imagine that there will be functionality for both Administrators and > > API > > > consumers. > > > Administrative functionality would be protected with with appropriate > > > authorization just as the admin API is today. > > > > > > How the functionality for different user classes is separated would > need > > to > > > be discussed and designed appropriately. > > > This is still in a POC stage. > > > > > > If you have specific suggestions please feel free to provide them. > > > > > > > > > On Fri, Dec 18, 2015 at 6:21 PM, Balaji Ganesan <bgane...@apache.org> > > > wrote: > > > > > > > Thanks Larry. Agree all shops do not use Ambari. Back to my original > > > > question, are we targeting this UI at administrators or we targeting > to > > > end > > > > using APIs that are routed through Knox? > > > > > > > > On Fri, Dec 18, 2015 at 3:06 PM, larry mccay <larry.mc...@gmail.com> > > > > wrote: > > > > > > > > > Balaji - > > > > > > > > > > 1. Not all shops use Ambari > > > > > 2. We can keep an eye on enabling this to bootstrap an Ambari view > > for > > > > > shops that do use it > > > > > > > > > > --larry > > > > > > > > > > On Fri, Dec 18, 2015 at 5:42 PM, Balaji Ganesan < > > > > > balaji.ganesa...@gmail.com> > > > > > wrote: > > > > > > > > > > > What is the use case for this UI ? What cannot this be done in > Knox > > > > > service > > > > > > in Apache Ambari? > > > > > > > > > > > > On Fri, Dec 18, 2015 at 1:38 PM, larry mccay < > > larry.mc...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > +1 to this idea! > > > > > > > > > > > > > > I have a couple interesting things to hang off of it as well. > > > > > > > I've got a POC for a KnoXplorer - simple UI for viewing > WebHDFS. > > > > > > > We can provide a simple REST API test page for each service in > > the > > > > > > topology > > > > > > > too. > > > > > > > > > > > > > > Also, I would love to expose Swagger or WADL for the APIs that > we > > > > > proxy. > > > > > > > > > > > > > > It seems that if we are to drive this from the admin API that > it > > > > would > > > > > > need > > > > > > > to span topologies though - not be under each topology. > > > > > > > Since you already have it working, I will take a look at how > the > > > code > > > > > is > > > > > > > making the context assumptions. > > > > > > > > > > > > > > I'll try and spend some time looking at it tonight! > > > > > > > > > > > > > > On Fri, Dec 18, 2015 at 4:24 PM, Kevin Minder < > > > > > > > kevin.min...@hortonworks.com> > > > > > > > wrote: > > > > > > > > > > > > > > > Hey Zac, > > > > > > > > This has long been on my “wish list”. I struggle with how we > > > might > > > > > > want > > > > > > > > to balance investment here against what we might want to do > in > > > > Ambari > > > > > > > > however. > > > > > > > > > > > > > > > > On a technical level should this be something that ends up > > being > > > > part > > > > > > of > > > > > > > > each topology or part of the admin topology > > > > > > > > http://host:port/gateway/admin/ui > > > > > > > > > > > > > > > > > > > > > > > > Kevin. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 12/18/15, 4:11 PM, "Zac Blanco" <zacdbla...@gmail.com> > > wrote: > > > > > > > > > > > > > > > > >Hi everyone, > > > > > > > > > > > > > > > > > >I've been thinking recently about the possibility of adding > a > > UI > > > > > that > > > > > > > > >someone could access using the admin API. I wanted discuss > and > > > see > > > > > if > > > > > > > this > > > > > > > > >would be a feature that would be welcomed. > > > > > > > > > > > > > > > > > >I'm thinking that this UI could utilize AJAX requests and > make > > > > calls > > > > > > to > > > > > > > > >Knox's Admin API to gain information about deployed > > topologies. > > > It > > > > > > could > > > > > > > > >then display information about the topologies to the user. > > > > > > > > > > > > > > > > > >I started working on something at > > > > > > > > >https://github.com/ZacBlanco/knox/tree/knox-admin-ui > > > > > > > > ><https://github.com/ZacBlanco/knox> . I added a new > resource > > > > under > > > > > > the > > > > > > > > >*gateway-service-admin* module: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/ZacBlanco/knox/tree/knox-admin-ui/gateway-service-admin/src/main/java/org/apache/hadoop/gateway/service/admin/ui > > > > > > > > > > > > > > > > > > > > > > > > > > >As long as the user has a deployed topology with the Admin > API > > > > then > > > > > > the > > > > > > > > >resource should be available under http://host:port > > > > > > > > /gateway/{topology}/ui/home. > > > > > > > > >Obviously the name/location could change. This is just more > or > > > > less > > > > > > > just a > > > > > > > > >proof-of-concept for now. > > > > > > > > > > > > > > > > > >I was thinking that there could also be a feature where you > > can > > > > send > > > > > > > > "test" > > > > > > > > >requests to different services to test whether they are > > working > > > or > > > > > > not. > > > > > > > > > > > > > > > > > >If we do want to add this feature we should also think about > > how > > > > we > > > > > > > might > > > > > > > > >integrate testing for this with our current infrastructure. > > > Just a > > > > > > > > thought. > > > > > > > > > > > > > > > > > >I would love to know what everyone thinks! > > > > > > > > > > > > > > > > > >-Zac > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
