Draft the world the way you want it.
Specify, objectify, relate, and attribute something to all the things and in the way you want for your world.
GitHub Project
YANA is a super simple, bare bones model management service where you specify, store and manage administrative information using an object graph. YANA is like a drafting board that lets you define and manage your model as specifications. Use YANA as a place to visualize and navigate the management information and put it all together into a single model.
YANA provides a plain jane GUI for viewing and modifying the model. YANA provides access control to govern who can change what parts of the model. YANA includes an API and export/import services to interact with the model from other tools and systems.
YANA is a super simple thing, that lets you do a not-always-super-simple thing, describe your world. YANA lets you create object graphs that represent your online software systems as interconected Nodes. Nodes are described with Attributes and Relationships as declared by thier Type. The YANA model objects can be declared via API or XML documents. YANA only takes responsibility to store, update, query, export and import the model. YANA enables easy "integration" with other services via a RESTy API and XML document support.
A YANA model is a specification of your world. It's the model of your world state. You can't represent the world as it is because it's always changing but you can represent the way you want the world to be. YANA let's you create an a-priori definition of expected state. With YANA you can specify environmental state or represent state definitions be they about configurations, properties, dependencies, etc. Tools can be controlled by the state in the YANA model or even change the model's state.
YANA is not unique as a node authority. There are many other node authorities.
It's more than just data. It's data about your datacenter (in the cloud, somewhat virtualized or otherwise).
Drive your automation world with the resource model that represents your application and infrastructure.
You describe the things in your world with a Node in a YANA model.
Connect Nodes together through Relationships to describe the interconnections in your world.
Resuable data. Define your model once and use it over and over again. Data-driven automation processes FTW!
Alike Nodes are described as Node Types that serve as a template for them.
Use YANA import and export services to maintain base model data in text files.
Access your resource model over the web, via browser or API. It's going over HTTP either way (SSL is configurable).
Access YANA model data programmatically over a simple HTTP interface.
Stop the information sprawl. Keep your information organized and structured the way you want so its easier to access.
Drive multiple tools with the same data model to avoid "similar but different" autorities of truth.
Avoid unstructured documenation formats spread across internal wikis and loose "README" files by capturing this knowledge into a formalized artifact.
Not ITIL, not DMTF
The YANA model does not prescribe a particular standard. For example, it does not provide a schema for an ITIL CMDB or implement a standard from DMTF. YANA only provides a very basic set of modeling concepts that help you define an object graph using a type system. Objects are called "nodes" in the YANA model. Each node is defined by its "type", which is in turn defined in terms of "attributes". Nodes in the model connect through "relationships". Relationships dictate the patterns of connection between "parent" and "child" nodes.
Yet another node authority
More and more automation tools, like MCollective, Chef/Knife, Salt, Fabric, need information about the hosts in their infrastructure. The location of execution is often governed by selecting hosts based on class membership or attribute. Rather than maintain this host inventory in scripted code, a YANA model can be used to independently represent the host information and provide it back to tools. YANA also supports a formalized process to define and control the model's evolution friendly with an SDLC.
Real time service model
Monitoring tools need to help you know if a business service is really up. YANA helps you describe the business service in terms of interconnected objects. Monitoring tools like Nagios can use YANA models to correlate and learn about dependencies. Infrastructure changes fast (especially in virtual ones) so the YANA model is easy to change, but in a way that stays in step with your management tools.
YANA only gives you a basic set of objects to specify things in your domain: Nodes, Types, Attributes and Relationships.
Node: A Node is an object in the graph. It may or not be connected to another Node by a Relationship. It may have few or many Attributes describing its characteristics and state. Nodes have an inherent feature called tags that take a list of labels useful for loose classification or grouping needs.
Type: A Node Type is a template specifying a kind of Node. A Node's allowable Attributes and Relationshps are declared by the Node Type. A YANA Node Type is different than a type in a programming language like Ruby or Java. YANA Type's do not support specialization or generalization through inheritance or composition. Node Types are like a frame that defines the permissible "slots" for attributes and relationships.
Relationship: A Relationship represents a connection between two Nodes. It is said in this relationship there is a Parent and a Child. This is just a matter of perspective but is often useful to know.
Attribute: A Node Attribute defines a property about a Node. An Attribute is a key/value pair who's value is restricted by a Filter.
These four basic concepts are enough to create a YANA model. Nothing beats some pictures so how about some?
Here's some drawings showing the basic YANA modeling objects and how they work together. Using those objects we can define Types and Nodes to represent application environments.
The first drawing shows the model primitives and how they are used together. Two Nodes, "node A" and "node B", have a relationship where "node A" has a child, "node B". One can also see "node A" has an attribute with a "value" that defines some state. To the left, one can see "Type A" reflects the model for "node A" and "node B". The Type declares one attribute and one type of relationship.
The second drawing shows a model describing a set of Nodes representing the information about some customer application instances. It shows several columns, each one for Nodes of a given Node Type. The "CentosHost" Nodes, centos01 and centos02, represent the hosts serving the "JBoss" nodes, jboss-5 and jboss-6. Several "AppInstance" Nodes represent JBoss application instances. The "OracleRDB" Node, represents an Oracle database instance. The "Customer" Nodes represent the business service Nodes provisioned for the customers, A, B and C.
The third drawing shows the Nodes connected through Relationships. Relations are used to compose Nodes together to form larger structures. Note, YANA models can arrange Nodes into hierarchies but practically speaking, YANA models often take the form of networks.
Overlaying the application model, an administrator may enhance the model to apply tags to Nodes or create their own Nodes to represent points of control.
The first step towards building a YANA model is to define the Node Types and necessary Attributes. Attributes can be common between Types so think of them like properties which can be general and shared. Once Node Types have been declared the next stage begins by defining the Relationships between the Nodes of the declared Types. One might consider the type definiton layer, the Node Types and Attributes, to be like the "schema" of the model.
In the drawing below, one can see a model spec coming from a git repository (could be another source code management system) and, via the YANA API, the model spec is imported to the YANA database. Models are stored in a YANA project and thus the project name is a parameter to the import function. YANA considers it a good practice to maintain the type definition layer as an artifact in the source repository and formally released to YANA instances. YANA instances can share model data through an export/import process as one can see in the top left of the drawing. One might share a set of base types across a number of projects.
On the right hand side of the drawing, are Monitoring and Deployment tools which interact with the YANA db via the REST API and the exchange of model specs. A Monitoring tool might modify the YANA model to reflect operational state. One might imagine the Monitoring tool is updating Nodes based on operational tests. The drawing shows how the Deployment tool gets information about Nodes (perhaps based on search queries) and uses the model spec during its remote execution across a set of Hosts.
YANA is not unique as a Node Authority. There are many other tools and services that support maintaining a node model. For example, configuration management tools like CFEngine, Puppet, and Chef are each capable of collecting and storing information about infrastructure and applications. This information is then made available to the automation layer and makes actions data-driven and thus more reusable.
ITIL declares the concept of a "CMDB" containing information about how business systems are comprised of interconnected components. This information is important for Service Management concerns like incident, problem, change and capacity management.
Infrastructure as a Service environments all include a Node Authority that knows about the virtual machines they control. The VM life cycle, from launch to retirement are governed by the compute service controller. This controller is the absolute truth about the state of the hosts.
Tools like Zookeeper allow you to define object graphs that model the structure of your application. The graph can be made active and invoke actions when the graph changes. These graphs are useful for the application to self-configure.
Monitoring tools like Zenoss, allow you to model your environment from network layer to service layer, letting you also define relationships between objects. This is important because these "run-time service models" are essential to understand how faults can impact the broader environment.
Your house-built system management tools probably include multiple Node Authorities. Inventory databases, deployment consoles, alarm managers each contain a view of the environment and the applications that run in it. These tools might be built from using libraries like neo4j that make it easy to implement object graph data structures.
Each of the Node Authorities named above are useful and share an important common purpose, to represent the structure and properties of an environment. YANA is yet another Node Authority, but just that. YANA is not active. YANA just provides basic CRUD, import/export, and access control. You can use YANA as a generic node model representation when you need to share specifications between one or more tools.
YANA is an open source project maintained at GitHub. The work is done under an Apache 2 license. Because it's an open source project, we welcome your contribution. YANA is a young project and plenty of refinement can be made. If you find YANA a useful tool, consider contributing to the project in some way whether it be through source code or just feedback and guidance.
Tweets
