"Shell" access on RC3?

1 view
Skip to first unread message

Raúl Alexis Betancor Santana

unread,
Apr 16, 2006, 4:27:34 PM4/16/06
to py...@googlegroups.com

Hi Duncan, I was reading something on the old list about a "shell" access
ala "CISCO IOS" for pymon .. will it be included on the RC3 release?

When could we spec the new release? have you any time prediction?

--
Saludos.

Raúl Alexis Betancor Santana
Director Gerente
Dimensión Virtual S.L.

Duncan McGreggor

unread,
Apr 16, 2006, 8:09:53 PM4/16/06
to py...@googlegroups.com
On 4/16/06, Raúl Alexis Betancor Santana <ra...@dimension-virtual.com> wrote:


Hi Duncan, I was reading something on the old list about a "shell" access
ala "CISCO IOS" for pymon .. will it be included on the RC3 release?

When could we spec the new release? have you any time prediction?

Sadly, I don't have a prediction. I am a software consultant, and last year was very tough for business. I've been putting all my extra time into trying to form new business relationships with longer-term contracts (6 months+ plus). Ideally, a company would like to have some simple but flexible monitoring like pymon, and they would just contract with me for something like distributed pymon (see http://maillists.adytum.us/pipermail/pymon/2006-March/000352.html), or for detailed reporting (detailed monitoring/service records) possibly tying in my work with PyRRD, or for adding MIB support, etc. All of these and more would be wonderful because not only would I be getting paid for something that I loved and am good at, but all of you would be reaping the benefits as well, since this would all go back into the source code.

Once I am not longer working week-to-week, I will have more stability and more time. At which point, I will continue with the pymon componentization, unit tests, additional monitors, distributed/peered pymon, and UI stuff like the shell, improving the web UI, integration with jabber and email, etc.

None of it is difficult to do, and in most cases I already have prototypes or proofs-of-concept written. It's a matter of "leisure" and time...

Also, discussing pymon architecture on the mail list really gets me going. After I send this email off, I will probably spend the rest of the night background-processing these thoughts, and when I have a space hour or two this next week, I could very well write some code -- simply out of the benefit of this type of interaction. So, if all you have to give is questions and time, that may be all that is needed in some cases for me to write additional code for pymone :-)

While I'm thinking about it, here's a few more notes on the componentization:

Each piece of pymon need to have formal tests. Each piece should be written such that it can be plugged into fake/dummy test setups, and pass the tests written specifically for that peice. For instance: monitors. All they are is client factories. But in order to test these, the unit test suite (twisted.trial) will have to setup the necessary infrastructure, essentially a "dummy" pymon instance. Ordinarily, that would be a pain in the ass. But with components, we will be able to do this clearly and cleanly.

The goal of this isn't just to have unit tests -- it's to have what unit tests provide: an ideal vehical for debugging complicated software. If there is a problem in one of the monitors or in the notification system or in the pymon shell, it will simply be a matter of looking at an isolated component, or of the communications between two components. As things stand now, debugging is very difficult due to a lack of comprehensive unit tests and a sane way of implementing them.

Once this is in place, adding features will be even easier that it is now. And there will not be an exponential increase in the maintenence burden. With an increase in components, an increase in maintenence is simply a linear relationship.

What's more, if I have no time to implement features, the components and documentation will make it very easy for anyone who wants to contribute (especially if they already know twisted).

These are the reasons that componentizing pymon is my top priority. Doing so ensures that you actually get what you want with the pymon shell, etc.

I know I reambled on, but I hope this is helpful... and not discouraging!

Thanks!

d

P.S. A note about that distributed pymon email link above: In that email, I mention using XML-RPC for inter-pymon comms. I have since written a Twisted JSON-RPC server, complete with unit tests. I needed HTTP Basic Auth, so it's still got some overhead, but less than XML-RPC. One of the things I'd like to do is supplement my twisted JSON-RPC library code with a TCP implementation for when authentication is not needed, so that the option would exists for super-lightwieght RPC.

If you are interested, here is the code for the twisted JSON-RPC server:
  http://projects.adytum.us/tracs/adytum/wiki/TwistedJsonRpc
It has a complete set of unit tests, and all pass. You use it identically to how you use twisted.web.xmlrpc, with the exception of replacing XMLRPC with JSONRPC, etc. There is no good jsonrpc library comparable to xmlrpclib right now, thought Bob Ippoolito has taken the first step with the latest release of simplejson (he's providing method hooks now).

As you can see from the length of my email and my P.S., I really do love this stuff and really wish I could spend more time on it right now :-)

Please keep the questions and comments coming :-)
Reply all
Reply to author
Forward
0 new messages