[cisco-voip] Consolidating access to Cisco CUCM APIs via Service Mesh

Tue Jun 16 20:55:52 EDT 2020

This is more or less what I had been doing internally at a very primitive level, and its been very valuable but quickly consuming of a ton of time to try and account for the items and interactions between them.  I have to more or less abandon Ruby at this point given that gems are not being updated and things are starting to be a problem to maintain for me, oh well.

The Ruby gem I coked up abstracts a user object with details pulled from LDAP, UCM, Unity Connection, and lets me interface with local resources or write simple reports. It is what I used to write a basic CSV Jabber import (stripped way down to just basically AXL) tool, though no one took me up on it for import over BAT. I think they’re nuts to use that.

I am still unclear on what a service mesh is, but, my overall vision was to have some sort of abstracted layer that monitors some level of object history, but allowed me to tether business rules and systems to actions in the data systems. It became pretty quickly obvious a job engine, call brokering and buffering, intermediate database with reconciliation and clean up jobs, etc would be needed on top of trying to define the way the objects actually interact with each other. I don’t have the time.

I did not look into AutomationFX, and I’ll earn some ire for this, but, we have used both PhoneView and MigrationFX. PhoneView I have largely gotten past internally with my own tooling but it is great for the rest of the team looking to do a quick data dump or get some data for reporting and with it’s built in data cache it’s pretty good. MigrationFX seems to be built on top of AutomatioFX, but, while better than going to each phone and configuring a new one, has had a clunky interface that doesn’t appear to be possible to secure when using older phones, at least per my coworkers, and I don’t want to invest my efforts into that.

I’d love to see something like this, but I wonder how complicated it would have to be to be ubiquitously useful.

Adam

From: cisco-voip <cisco-voip-bounces at puck.nether.net> On Behalf Of Anthony Holloway
Sent: Tuesday, June 16, 2020 8:34 PM
To: Pete Brown <jpb at chykn.com>
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Consolidating access to Cisco CUCM APIs via Service Mesh

Yeah....still lost.  Possibly even more than I was before.  I'll just see myself out now.

On Tue, Jun 16, 2020 at 6:44 PM Pete Brown <jpb at chykn.com<mailto:jpb at chykn.com>> wrote:
Thanks for mentioning AutomationFX.  That’s exactly the sort of API consolidation I was thinking of.  Should’ve guessed the guys at UnifiedFX had already done something along these lines!  I’ll probably still build a CUCM mesh agent just to demo the marrying of access to objects & their associated data streams.  But it won’t be near as complete as AutomationFX.

Wouldn’t say ignorant at all.  Service meshes (Istio, etc) in their current form have only been around a few years.  Even most developers I talk to haven’t really touched them beyond POCs.  Mainly due to the complexity since they all require the use of Kubernetes.  The concept has never really been applied to infrastructure sources before, especially in a vendor agnostic way.  In infrastructure we’re dealing with a federation of loosely coupled data sets instead of something that a single architecture group came up with.

To answer the question of “why” regarding the mesh I’m working on, it’s to eliminate a bunch of the common pitfalls in traditional integrations.  Instead of finding and calling each source directly using different client libraries, the mesh provides a single method of executing RPC & pub/sub operations against backend services.  You can even navigate the resources like a directory structure.

In this mesh, the backend services register themselves and declare their functions, object schemas, etc.  That’s why I say it’s sort of a hybrid between a service mesh and a data mesh; you can call service functions or search on object class attributes regardless of source.  Clients who need to access sources make calls to the Brokers.  Very roughly analogous to a “meshified” version of SNMP.

Here’s a before and after of what an Ansible script might look like calling difference sources.

[cid:image001.png at 01D6441F.07C40490]

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Anthony Holloway<mailto:avholloway+cisco-voip at gmail.com>
Sent: Tuesday, June 16, 2020 3:02 PM
To: Pete Brown<mailto:jpb at chykn.com>
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Consolidating access to Cisco CUCM APIs via Service Mesh

You lost me there, as I'm too ignorant to understand what an API mesh is, but this sounds very familiar to what UnifiedFX is/was doing with AutomationFX, is it not?  Or am I again showing my ignorance?

On Tue, Jun 16, 2020 at 12:32 PM Pete Brown <jpb at chykn.com<mailto:jpb at chykn.com>> wrote:
TLDR – Developing a hybrid service/data mesh for interacting with infrastructure services.  Thinking about what a modern, consolidated API might look like for CUCM.

I was scheduled to give this talk at DevNet Create until everything was shut down…
https://github.com/adhdtech/DRP/blob/master/DevNet%20Create%202020%20-%20Making%20a%20Mesh%20of%20the%20Infrastructure.pdf<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadhdtech%2FDRP%2Fblob%2Fmaster%2FDevNet%2520Create%25202020%2520-%2520Making%2520a%2520Mesh%2520of%2520the%2520Infrastructure.pdf&data=02%7C01%7C%7Cd6a891dd87c54621067108d8123041fd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637279345751719757&sdata=dyBvjV7Fh1Wk6XYSOaQGqXfl65bjxthF50%2FWuEKSz54%3D&reserved=0>

For the demo I had data from a few of the CUCM APIs being piped into a consolidated logical model.  Nothing too complex; just users, devices and associated JTAPI streams.  It got me to thinking, though.  If you could snap your fingers and have a modern, consolidated API for interacting with CUCM services, what would it look like?  Not just RPC operations, but pub/sub as well.

I’m considering creating a mesh service agent for CUCM.  Instead of leveraging the existing APIs, the goal would be to effectively replace them and inject their capabilities into the mesh.  Before I do, I’m trying to figure out what some of the “must have” features would be for a POC.

The project README needs some updating, but it does give a general idea of how everything works.  Recently added a command shell; need to get that documented.
https://github.com/adhdtech/DRP<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadhdtech%2FDRP&data=02%7C01%7C%7Cd6a891dd87c54621067108d8123041fd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637279345751729741&sdata=%2BayXqiSdtWHtbnS5ZsAfS1k3cU%2BZ3rLo59oA1NtX3nA%3D&reserved=0>

-Pete

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7Cd6a891dd87c54621067108d8123041fd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637279345751739738&sdata=f0jlP20VlNLd9zIENVXVvcB%2BguROK6VN54qnc7Ina2M%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200617/a1bc37d4/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 60437 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200617/a1bc37d4/attachment.png>