Introduction

Apache Knox 1.0.0 added support for topology generation from simplified descriptors and shareable provider configurations. Rather than XML, these topology source configurations can be defined in either JSON or YAML. While these can be hand-coded and manually copied to the Knox host(s), the Knox 1.1.0 Admin UI provides a more user-friendly facility for authoring them, which also does not require ssh/scp access to the Knox host(s). Furthermore, using the Admin UI simplifies the management of topologies in Knox HA deployments by eliminating the need to copy files to multiple Knox hosts.

The Admin UI has provided the ability to view, add, modify and delete topologies since it was created. Starting with Apache Knox 1.1.0, the ability to do the same for provider configurations and descriptors has been added.

The Admin UI can be accessed at the following URL (where hostname is the name of a Knox host) : https://hostname:8443/gateway/manager/admin-ui

This post will focus on working with the provider configuration and descriptor resources. For these types, the icon next to the resource list header presents the respective facility for creating a new resource of that type.
Modification options, including deletion, are available from the detail view for an individual resource.


Provider Configurations

By default, there is a provider configuration named default-providers.

Editing

For each provider in a given provider configuration, the attributes can be modified:

  • The provider can be enabled/disabled
  • Parameters can be added () or removed ()
  • Parameter values can be modified (by clicking on the value)


To persist changes, the button must be clicked. To revert unsaved changes, click the button or simply choose another resource.

Wizards

The Admin UI gives administrators the ability to define provider configurations based on their functional needs. So, rather than having to know the provider names and their respective parameter names, the provider configuration wizard can be used.

A provider configuration is a named set of providers. The wizard allows an administrator to specify the name, and add providers to it.

To add a provider, first a category must be chosen. For this example, let’s add an authentication provider.

After choosing a category, the type within that category must be selected. For this example, let’s choose LDAP authentication.

Finally, for the selected type, the type-specific parameter values can be specified. Here, the demo LDAP server details can be configured.

After adding a provider, others can be added similarly.

Composite Provider Types

The wizard for some provider types, such as the HA provider, behave a little differently than the other provider types.

For example, when you choose the HA provider category, you subsequently choose a service role (e.g., WEBHDFS), and specify the parameter values for that service role’s entry in the HA provider.

If multiple services are configured in this way, the result is still a single HA provider, which contains all of the service role configurations.

Persisting the New Provider Configuration

After adding all the desired providers to the new configuration, choosing persists it.

Following our example, the resulting provider configuration has two providers: authentication and ha.

Expanding these providers, we find the details that were specified in the various wizard steps.

Now, this provider configuration can be referenced by one or more descriptors to be incorporated into the respective generated topologies.


Descriptors

Out of the box, there are no descriptors in the conf/descriptors/ directory; thus, there are no descriptors listed in the Admin UI. Fortunately, the Admin UI makes it easy to add one.

A descriptor is essentially a named set of service roles to be proxied with a provider configuration reference. The new descriptor dialog provides the ability to specify the name, which will also be the name of the resulting topology. It also allows one or more supported service roles to be selected for inclusion.

The provider configuration reference can be entered manually, or the provider configuration selector can be used, to specify the name of an existing provider configuration.

Optionally, discovery details can also be specified to direct Knox to discover the endpoints for the declared service roles from the Ambari-managed target cluster.

Choosing results in the persistence of the descriptor, and subsequently, the generation and deployment of the associated topology.


Knox HA Considerations

If the Knox instance which is hosting the Admin UI is configured for remote configuration monitoring, then provider configuration and descriptor changes will be persisted in the configured ZooKeeper ensemble. Then, every Knox instance which is also configured to monitor configuration in this same ZooKeeper will apply those changes, and [re]generate/[re]deploy the affected topologies. In this way, Knox HA deployments can be managed by making changes once, and from any of the Knox instances.

More details are available in the User Guide.


Summary

These improvements to the Admin UI make it even easier to take advantage of the service discovery and topology generation features of Knox. Now, administrators don’t even have to bother writing JSON or YAML files directly, and they don’t need to access the Knox host(s) via ssh/scp to effect topology changes. Finally, by configuring multiple Knox instances in an HA manner, changes to provider configurations and descriptors are automatically propagated to all participating Knox instances, simplifying management of Knox HA deployments.

More details are available in the User Guide.