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.

Declaring sipXecs Project Maintainers?

In 2004 when the sipXecs source code was first released to SIPfoundry, the developers agreed to divide the source code into 9 distinct projects. We then decided that if these projects were going to be successful, then someone was going to have to be the point-person for each project to make sure they were well kept. We came up with the role "Project Maintainer". It was exciting to be declared a "Project Maintainer".

Since 2004 folks have come and gone and now many of the 34 distinct projects don't really have a clear "Project Maintainer". So the question has come up: Should projects try to find a new "Project Maintainer"?

Before we answer that question, it's worth taking a looking back. Some projects prospered having a "Project Maintainer" others did not. I could go into detail about each project but I don't think that it's actually necessary and here's why. I discovered something truly amazing being a part of the sipXconfig project that I never experienced before. The more unit test coverage a module got the more contributors that module saw, The more contributors a module saw the better the APIs got. The better the APIs got the more reusable the module was. The more reuse the module got the more bugs were discovered and fixed. These things can be considered the definition of success by most measurements.

I also discovered that code without unit test coverage had contributions were often stalled or rejected because "Project Maintainers" were always in fear of holding the bag on contributions that introduced bugs while not advancing their employer's goals. Contributions were unjustified risks as we all strive to be lazy programmers.

I am of the opinion that sipXecs's governance needs to advance, but I'm not sure I'm of the opinion we should repeat the decisions we made back in 2004 by declaring "Project Maintainers" in light of what I learned about unit testing since then. Without these unit tests in place, "Project Maintainers" will inevitable find themselves in a position where they're putting their employer at risk taking contributions that are not unit tested.

The unit test coverage on the codebase varies between each project. It all depends on the precedence that was set by the "Project Maintainer". We're therefore is a position where projects without a "Project Maintainer" will suffer.

I'm making an unofficial proposal (because I haven't completely thought it through yet) that we should consider finding "Unit Test Sheppards" for each project. A "Unit Test Sheppard" has established a productive unit test environment for a project so contributions can begin to flow. Projects can skip right past needing a "Project Maintainer" and jump right to "Community Owned". It's like going from mid-evil times straight to a democracy and skipping feudalism. Somehow the job title "Unit Test Sheppard" is less attractive though. Visions of shoveling sheep manure come to mind. Yet is remains an attractive solution to our problem. Once a project is seeing improvements, bringing back the concept of a "Project Maintainer" might make sense, but more as a role of visionary or leader instead of self satisfying dictator. That visionary will probably be self-evident by the newly prosperous project community.

I owe a beer to anyone that cloned my sipxecs git repo

My git repo was severely messed up so I rewrote the history on github. So if you cloned, I supposed you have to save out your patches, re-clone and apply your patches again. Sorry.

Here's an atom feed to my development activity on github if you want to keep tabs on me.
http://github.com/dhubler.atom

I'm in the process of attaching patches to track.sipfoundry.org now.

sipXecs 32 and 64 bit ISOs on CentOS 5.4 ISO available

I just finished building ISOs for 32 and 64 bit

http://download.ezuce.com/sipfoundry/4.2.1/ISO/

Containing the RPMs from here
http://download.ezuce.com/sipfoundry/4.2.1/CentOS_5/

I was not able to test 64 bit, for some reason VirtualBox didn't let me run any 64bit code. I would appreciate any help testing. It only has the initial splash screen, i did not incorporate the other images yet.

But wait, there's more. I contributed the source I used to build the ISO as project so folks can respin their very own sipx CDs.

Instructions on how to build your own ISOs:
Step 1: Download the sipXiso project

git clone git://github.com/dhubler/sipXiso.git
cd sipXiso

Step 2: Download CentOS 5.4 disc 1 CD for 32 and 64 bit and place them into a directory ./ISO. Do not rename the iso files.
Step 3: Build or download all sipx RPMS for CentOS, 32 and 64 bit. Doesn't matter how they are organized, just that they are all there and place them into another directory called ./repo
Step 4: Build sipXiso

autoreconf -if 
./configure
make

I do plan to make improvements to the project to customize the splash screens. Contributions and/or feedback welcomed.

Fedora 12/11 are really ready this time

As well as CentOS 5 including 64 bit for all

I put together some instructions
http://docs.google.com/View?id=dfs8q7k9_30cqgtpbcc

Here's what I've done to test
Install Fedora 12 and do the usual things (set hostname, disable firewall and selinux...)
* added yum repo
* installed sipecs
* set DHCP to point system (dhcp-option=66,"192.168.1.100")
* added user 200 to system
* reboot polycom 430 (3.2.3 firmware) and it registered fine as temp user
* associated phone to user, sent profiles, phone rebooted
* setup ITSP account to VOIP.MS
* Make call to my cell phone
Notice, i didn't have any issue sipxconfig-ftp package adding PlcmSpIp user w/mixed case. This is working fine. Maybe it's because i disabled selinux first???

I've done the same procedures on CentOS 5 machine as well.

On an earlier build, I did verify IM bot is working. I still need to rename (back?) to My Assistant.

As usual, my src is here
http://github.com/dhubler/sipxecs

sipxcommserverlib-doc and sipxecs-doc?

I highly doubt anyone reads the files in these directories on production machines. INSTALL.ssl is useful but it should be a man page for gen-ssl-keys.sh. sipxecs-doc looks like things that should be on the wiki. I only stumble across these because they are giving me grief trying to build on various platforms and i wanted to take this opportunity to simplify things.

So I'm using INSTALL.ssl as a man page for gen-ssl-keys.sh and the rest are not getting built by the rpms. I'll leave the original doc files in there for now.

RHEL support thru CentOS + rsyslog

suse build service made support binaries build on actual RHEL machines extremely easy, simply add RHEL repo and subsequently 214 sipx rpms can now be had...and tested...and stored, and ... so on!

I want to take a different approach for RHEL support. CentOS promises to provide a binary compatible alternative to RHEL. In addition, CentOS also comes w/some extra rpms RHEL does not such as rsyslog which is now required by sipXpbx rpm. So let's only build rsyslog on RHEL and add that to a the CentOS repo and allow it to get ignored by CentOS machines. I plan to create a symlink on the server point RHEL to CentOS in case I have there is an incompatibility and i need to have separate repos.

This is my plan anyway.

Fedora 12/11 are ready

This brings the final list of distributions
* CentOS 5
* Fedora 11 (untested)
* Fedora 12
* Redhat 5 (untested)
including 64 bit although I have not tested these.

On my fedora system, i had to comment out this line in my /etc/hosts

 ::1 localhost6.localdomain6 localhost6 flamingo.hubler.us

Otherwise commands

 hostname -d
 hostname -f

did not return hubler.us or flamingo.hubler.us respectively

i'm on vacation this week

At Disney so I'll get back to things next week.

sipXecs on Fedora 12/11 almost ready

Thank you Eric V. for the work there!

I waited for builds to finish but i suspect there's an unknown delay from when the build is finished to when it becomes available in the public repo. I'm not seeing my changes right away. md5sum confirms this. If anyone wants to try out Fedora 12 rpms, the repo is here during the day on sunday, they are welcome too, otherwise I may be able to get to them sunday evening.

Very quick list of some open items i can think of:

My Buddy needs to be renamed so as not to be confused w/avaya's. Back to My Assistant?

My Buddy still not showing up in roster automatically. Does seem to log into openfire.

Build labels to identify builds from avaya's

Postgres is too verbose in some area, stdout needs to be swallowed. I wanted to get f12 out so i was aware i'd be introducing a temp regression

Scattered errors reported during update/install by folks

A little more about suse build service

and why i think it's great for community driven things.

SUSE the company has built a build service where you give them your source, they return you binaries on most major linux distros, all for free. The source I upload goes into this the home:sipfoundry project. You may have to create an account to see it, but not to download the binaries from it.

But it gets even better. If you think the source should have feature XYZ and the people that upload to this project disagree with you, you can "extend" this build project, upload just the source for the features you want and have it your way in your local sandbox.

When you combine this with distributed source code management system like git, where you can extend projects at the source code level, then you are truly in control.

This comes with a lot of responsibility because you need to get your changes back upstream or you'll forever be maintaining your changes. So this is really best for tweaking a release to your satisfaction and not a replacement for getting involved in upstream development.

How to install sipXecs 4.2 for testing from suse build service

As of, 04/15/10, this is not an official 4.2 release, more testing needs to be done. The instructions may even change, but here's what I got so far.

Right now all I have is CentOS and RHEL 5 binaries for 32 and 64 bit.

To install them, create repo file /etc/yum.repos.d/sipxecs.repo

[sipxecs]
name=sipxecs
baseurl=http://download.opensuse.org/repositories/home:/sipfoundry/CentOS_5/
gpgcheck=0
enabled=1

I recommend gpgcheck=0 because although the rpms are signed, I haven't figured out where to get the key.

The source for these binaries is here

http://github.com/dhubler/sipxecs

Which periodically stays in sync w/svn but also has:

• patches to build on suse build service


• Support for P-Preferred-Identity XX-6893


• Routing by To: field in sipXbridge. I do not have a bug number for this feature, not sure how to track this.


• Return of sipXimbot (i.e. My Buddy)


• Return of sipXopenfire IM commands (i.e. @call, @conf, @xfer)

What else I'd like to do

• with Eric's patches, I will quickly be working on getting Fedora 11/12 binaries available.


• Finish support for P-Preferred-Identity when ITSP requires registration.


• Return support for IM Federation with Kraken

Any help testing would be appreciated. I'm about to verify a report that "My Buddy" doesn't show up in the roster.

I'll leave comments open on this blog assuming spam stays under control, you can post here, anonymously if you wish.