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 > > > > > > > > > > > > > > > > > > > > >
