Details

    • Type: Sub-task
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 0.14.0
    • Component/s: Server
    • Labels:

      Description

      Knox should provide the option to monitor an Ambari cluster for which it has deployed a topology, in order to notice configuration changes that affect the service URLs for that topology. Upon noticing such a change, Knox should respond by updating the deployed topology appropriately.

        Issue Links

          Activity

          Hide
          risdenk Kevin Risden added a comment -

          Should Knox be monitoring Ambari or should Ambari be pushing the change out to Knox? I prefer that Ambari pushes out to Knox. Polling Ambari seems backwards.

          Show
          risdenk Kevin Risden added a comment - Should Knox be monitoring Ambari or should Ambari be pushing the change out to Knox? I prefer that Ambari pushes out to Knox. Polling Ambari seems backwards.
          Hide
          pzampino Phil Zampino added a comment -

          What about scenarios where Knox is not managed by Ambari?

          Show
          pzampino Phil Zampino added a comment - What about scenarios where Knox is not managed by Ambari?
          Hide
          lmccay Larry McCay added a comment -

          Kevin Risden - Your concern is well founded. This however is a scenario related to KIP-8 where Ambari is the source for service discovery rather than the management platform that is pushing out all the config details. By allowing Knox to pull the relevant URLs and HA metadata from a service registry abstraction, we can have much simpler topology descriptors. Admins would only need to indicate which services they want in a topology and the rest will be pulled from the service registry. In this case, the Ambari REST APIs are used as the registry. Another source may be ZooKeeper.

          So this is in a way simplifying what the Ambari UI needs to do - instead of all that XML we can have a simple page of services with checkboxes as well as allowing for the metadata to be pull from other sources if desired.

          Give KIP-8 a read and see whether it makes sense to you.

          Thank you for raising a concern here!

          Show
          lmccay Larry McCay added a comment - Kevin Risden - Your concern is well founded. This however is a scenario related to KIP-8 where Ambari is the source for service discovery rather than the management platform that is pushing out all the config details. By allowing Knox to pull the relevant URLs and HA metadata from a service registry abstraction, we can have much simpler topology descriptors. Admins would only need to indicate which services they want in a topology and the rest will be pulled from the service registry. In this case, the Ambari REST APIs are used as the registry. Another source may be ZooKeeper. So this is in a way simplifying what the Ambari UI needs to do - instead of all that XML we can have a simple page of services with checkboxes as well as allowing for the metadata to be pull from other sources if desired. Give KIP-8 a read and see whether it makes sense to you. Thank you for raising a concern here!
          Hide
          lmccay Larry McCay added a comment -

          This is really discovered data change discovery not necessarily that the topology (simple descriptor) definition has changed.
          So, for instance, if a service URL changes for a service that is being proxied by one or more topologies then they will need to be updated with the change.

          Show
          lmccay Larry McCay added a comment - This is really discovered data change discovery not necessarily that the topology (simple descriptor) definition has changed. So, for instance, if a service URL changes for a service that is being proxied by one or more topologies then they will need to be updated with the change.

            People

            • Assignee:
              Unassigned
              Reporter:
              pzampino Phil Zampino
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:

                Development