Greetings Larry, As always thanks for the community's good work and collaborative support.
I have been following the traffic on Knox improvements for sometime but have not built and used the interim builds. All the deployment topology improvements sound very useful in production. To fully close the loop for our operations team, the integration with Ambari is going to prove critical. Many tools we use (Confluent Kafka REST, Livy, etc) require manual installation and then complex configuration. With these recent addition to Knox and future improvements to Ambari, it would be great to declaratively state which services to proxy and have automatic host detection with high availability/failover. Essentially a complete end-to-end solution with a low rate of failure opportunity for our operations teams. So in the interim, I would ask that changes necessary to support automatic deployment/registration of Ambari managed services be sufficiently documented in the Knox. That way existing topologies could be manually setup or a configuration is set which uses Ambari as a registry. I just don't want all the good work done to be overshadowed by inadequate documentation. Personally, I have been focused on the Knox to client side of things. This includes creating a thin HBase REST client out of their baseline. In the near future, we should have Kerberos support from the HBASE REST Client API as well. This work is being tracked in HBASE-19207 (https://issues.apache.org/jira/browse/HBASE-19207). The project can be found on Github: https://github.com/rmkellogg/hbase-lite-rest-client. After which I will be looking at tackling Kerberos support from the SOLRJ API as well. Take care, Rick -----Original Message----- From: larry mccay [mailto:lmc...@apache.org] Sent: Thursday, November 30, 2017 4:52 PM To: dev@knox.apache.org Subject: Re: Ambari Enhancements Hi Rick - Good to hear from you! I don't think that there is any danger of getting out of sync with Ambari expectations here but I may be missing something. Let me try and summarize the work being done which is based on KIP-8 [1] and you can tell me what your concerns are... 1. We will continue to support the native topology file which is what Ambari is doing 2. We are introducing a simplified descriptor and shared provider config mechanism that results in generated topologies that Ambari will be unaware of in the near term 3. The topologies are generated by using the Ambari API to discover the service details which obviously is compliant with the current Ambari REST API but Ambari itself is unaware of it 4. The descriptors and provider config will be able to be monitored in Zookeeper as well as local file system Ambari will remain inline with local default.xml, knoxsso.xml and admin.xml topologies and unaware of ZK based configs for now 5. Ambari improvements are planned to be able to manage the descriptors and provider config and to push them to ZK when available otherwise to local disk 6. Editing topologies that are generated from descriptors would be problematic and lead to confusing when they get overwritten upon changes discovered in the descriptors or service details via Ambari REST API. So Sandeep is making the generated topologies readonly in the UI with an indication as to why. Ambari is completely unaware of the Knox Admin-UI currently and will likely remain so. Does the above address your concerns and/or can you share what your concerns are? thanks! --larry 1. https://cwiki.apache.org/confluence/display/KNOX/KIP-8+Service+Discovery+and+Topology+Generation On Thu, Nov 30, 2017 at 3:34 PM, Rick Kellogg <rmkell...@comcast.net> wrote: > Greetings, > > > > Has there been any enhancements made or even suggested to the Ambari team? > > > > I see a lot of work being done on the Knox internally and to the Knox > Admin UI and have some concerns that Ambari v2.6.0+ might not play > well with all the new enhancements. > > > > Just my two cents, > > Rick > > > >
