-
Notifications
You must be signed in to change notification settings - Fork 16
ODPi Ambari Specification
TODO - Should the title be "ODPi Installation and Management Specification" rather than "Ambari"?
Pointer to runtime spec objective, with added text on how this is about installation and management.
Based on Ambari version 2.x (which one?).
Comment on ability for vendors to add patches.
Package formats that are supported. (rpm and deb)
What expectations are put on application writers in how they lay out their packages?
How should packages be named? versioned?
Vendors packages must conform to the specifications we give to applications.
How are repositories managed? (Currently Ambari supports a single repository for hosting rpm/deb packages for the stack, in addition to a "utility" repository).
Where do vendors put their stack definitions? How can applications and users access these? How can they determine which ones are installed and which one is active?
Recommendation and validation of Application configurations MAY be added via Stack Advisor. (Currently this is defined as a monolithic script at the stack level - ideally this should be defined per service, with an optional service-level stack advisor to address cross-cutting concerns).
Dependecies of which Application should be started in which order is specified via Role Command Order (role_command_order.json) (Again, this is specified at the stack level, but we might want to put this at the service level).
An Application MAY provide custom logic for determining and exposing QuickLinks, which are hyperlinks to the Application's Web UIs/JMX, etc, if any.
What do applications need to do to support static upgrades? Rolling upgrades? (This is upgrade of the stack, not the application as Ambari does not support that yet.)
Do all vendors need to support rolling upgrades (of their stack, not applications)?
Shall ODPi push for standardizing around things like alternatives for managing side-by-side installations or do we bite the bullet and invest in our own mechanism?
Are vendors required to support Kerberos?
What do applications need to do to work with Hadoop when Kerberos is being used?
For example, if the Application talks to HDFS, then it must be able to authenticate against a Kerberized HDFS?
An Application MAY (MUST?) provide a "Kerberos descriptor" metadata file in order to let Ambari know what Kerberos principals/keytabs need to be created, what config changes must be made, etc.
An Application MAY expose custom actions that are exposed via the Ambari Web UI and API. (E.g., HDFS Rebalancer). How is this done?
How does an application emit events for monitoring? An Application MAY provide a Hadoop Metrics2 Sink implementation to emit its own metrics into Ambari Metrics System.
How are metrics collected and stored? Where can a user view/query them? What guarantees around this is the vendor required to make?
In order to expose the Application's collected metrics via the Ambari API, metrics.json must be defined (this is the current behavior, though we are looking to get rid of this in 2.2.0). What's the format and how does an application provide this file to Ambari? Or do just specify whatever is coming in 2.2?
How does an application submit a view for Ambari to host? What languages and tools are supported?
- https://issues.apache.org/jira/browse/AMBARI-12885 [dynamic stack extensions]
- https://jira.odpi.org/browse/ODPI-3
This work is licensed under a Creative Commons Attribution 4.0 International License