First java "Conf2 Java App"

I've been working on my management library called "Conf2" and while the library is written in Go, I've been working on the seamless integration with Java. As an example app, I created the beginnings of a minecraft mini-game. The game still needs work, but the API is taking enough shape that I thought I could share the initial code : https://github.com/dhubler/mcstone 

The 3 important classes to look at are StoneGame, StoneGameBrowser and Main and one important file mcstone-lite.yang

• StoneGame is void of any references to the Conf2 library. This represents any pre-existing written application that needs to be configured (read-write fields), inspected (read-only fields), watched (events) or have operations exported (rpcs) 
• StoneGameBrowser connects the application to the Conf2 library. It navigates the StoneGame app and all it's pieces according to a predefined schema. If you see weird java syntax, it's 1.8's lambda expressions. 
• Main unites StoneGame and StoneGameBrowser, creates a RESTful service, registers the StoneGameBrowser, then starts the rest service.  
• mcstone-lite.yang is the application schema that StoneGameBrowser supports. For java, "container" means object instance, "list" means collection, "leaf" means java assessor.

The Conf2 engine is https://github.com/dhubler/yang-c2 but I'm going to eventually move it to https://github.com/dhubler/conf2

DevOps 2.0 w/YANG and RESTCONF

tl;dr - I'm implementing YANG and RESTCONF standards that allow software vendors to distribute their software easier and reduce integration work for software consumers. Implementation will introduce minimal complexity w/o sacrificing customization and enable reusable web-based user interface.

Platforms are starting to emerge to make DevOps easier, but industry is ready for some standards so DevOps folks can mix and match components easier and software vendors can focus on their innovational pieces and not various management platforms plugins.

One standard; YANG and one draft; RESTCONF I believe can play a large role in making DevOps easier.

• YANG - RFC6020 - It's an IDL (Interface Definition Language) that focuses on the API instead of code generation. Yet another IDL, but it's flexibility for reuse among other niceties make it very useful capturing the canonical API of a service, be it web-based or otherwise. RFCs are already being submitted that are just YANG files with the purpose providing a common API for SDN (Software Defined Networking) components like routers. YANG can describe configuration parameters, metrics, RPCs and event streams.
• RESTCONF - RFC-TBD - When a service that implements RESTCONF is installed on your network, you can send RESTful calls to it that honor the YANG files when managing other services in your network. In my opinion, the draft is headed in the right direction.

If you are wondering what this has to do with traditional DevOps tools like Puppet or Chef, think about the majority of work these tools do : edit config files, start/stop services. If you could tap into running applications and configure them on the fly w/o ever touching a config file, much (but not all) of the scripting in these tools go away.

If you are wondering what this has to do with web-based management tools like Ansible, this should allow Ansible to integrate modules faster. Ansible contributors or software vendors would still have to provide web based admin UI distributed as an Ansible plugin. As a software vendor, you would need to build plugins for other tools in this space and require your customers to use such tools.

So with YANG and RESTCONF software consumers and producers have less work to do, and there are a few open source tools that implement these standards: Open Daylight, netopeer, and YumaTools. I researched these tools and I think there's room for another implementation with following goals:

• More computer language friendly - Python, Java, C, Golang, ...
• Works more like a library (ala netopeer) instead of a large platform (ala Open Daylight) to reduce complexity.
• Provides integrated UI (like Ansible) but allows vendors to supply reusable UI components without customer requiring another tool.