Monthly Archives: November 2010

jquerymobile and having design constraints

2 Replies

I’ve been working on this idea/project called Eyes for the past year on and off. Maybe for the past 4 to 6 months I’ve been stymied by what I want the visual representation to look like, struggling with the options of an open HTML design canvas. I’m afraid the sheer potential of anything there left me struggling – there were too many ideas of what I could do for a visual presentation and interaction, and I wasn’t able to really narrow it down all that well.

I’ve been following SproutCore for a while, sort of thinking about that as an interesting mechanism, and then more recently I saw the announcements about the jQueryMobile framework setup. Having done some iPhone and iPad development, the common metaphors of list views, tableviews, etc. felt very familiar. jQueryMobile isn’t all that to be perfectly honest, but the basic design feel is reasonably close.

I made a branch on Eyes and started laying it out – and I’ve been going gangbusters since. Laying in the constraints of the framework has really made the choices much easier to work out. Not that I haven’t run down some dead ends and had to back out, but I feel like I have better sense of how the pages flow and work together.

And best of all, I have something that I’m comfortable will work on mobile devices, while not looking like crap on a larger view.

I’m still learning the various tidbits of the framework CSS stylings, and I’m already seeing some elements where I’m going to want to dig deeper. The only real struggle I’ve had is working with Ajax based forms submissions and debugging them when I bork it up. Doing so much javascript work and debugging is still pretty unfamiliar to me. I’m ending up with a lot of print(“..”) debugging on the back end, and alert(…) debugging in the javascript itself.

All in all, I’m very pleased with the effects and results of using jQueryMobile. I do rather wish I hadn’t left my jQuery book at work for the holiday weekend though – I’m certainly not a jQuery expect, and it would have come in very handy more than once already. Thank god for excellent online documentation.

Eyes – a new monitoring system

2 Replies

It was over a year ago that I started getting really annoyed at the state of monitoring systems. They all do what you sort of expect a monitoring system to do – watch (poll) systems and alert you when something’s gone off. Pretty much anyone who’s done much system administration work knows the obvious critters: Nagios, Munin, Cacti, Zenoss. Zenoss is the start into the pay realm too – GroundWorks, BMC Patrol, HP’s SiteScope, etc.

So here’s my annoyance – all of these systems, even the open source ones, are really set up to be managed by people, not other systems. They’re not built with API’s to be able to create, update, check on, and delete monitors. Some of them come darned close – Zenoss, SiteScope, etc. Others have this sort of worked around from the back side – i.e. Puppet or Chef recipes that generate Nagios configuration files.

So a year ago I decided that I could probably put something together that does the same basics, but has API’s built in from scratch. I did a lot of noodling on the idea, scratching ideas in notebooks and such, before I really kicked things off. Then I decided to see what I could do to wrap up a new system. I built it around Nagios plugins – mostly because there’s a lot of them and they do some pretty good stuff right off the bat. And that’s all open source as well. And I wrapped that around with a web application based on Django, because – well – I know Django reasonably well. The result is a basic system that I’m calling “Eyes”.

The whole source, from the very beginning, is on Bitbucket at http://bitbucket.org/heckj/eyes. And after poking at it on and off for nearly 12 months, I decided to wrap this up a bit and get it out there – so as of today I have my first release on PyPi, with documentation. And I created a mailing list – eyes-monitoring – on Google Groups to have some place to talk around it.

I very intentionally included documentation for the project from the very beginning, embedded with the project. I also very intentionally wrapped a large number of tests around the project, and have been checking and watching test coverage as the project grows and changes. The state today? Basically functional, but you have to know the innards to do much more with it.

Today it doesn’t have anything related to alerting or escalation within it. It doesn’t have much of anything around a user interface, and the data is stored all in RRD files. It’s at the point now where the basic framework is in place – and there’s a lot more to go: design of the user interface, blocking in alternate mechanisms to do monitoring, and fleshing out higher level features like notifications and alerts – both via email and alternative mechanisms (like web-hooks, or XMPP event streams).

What it is ready for is outside eyes. If you’re interested in contributing, or even sharing some ideas about what to do with Eyes, I’d love to hear from you. Fork the code and try it out, or join the mailing list (http://groups.google.com/group/eyes-monitoring) and share some of your ideas or thoughts.

Nearly at the top of that first hill

1 Reply

I’ve been thinking about the past week at the OpenStack Design Summit (Bexar) solidly from last night (flying home from San Antonio, TX) through the various errands I’ve been running today. This morning Rick Clark tweeted “A question about OpenStack”. As I think about it, this shouldn’t be about what is going right and wrong, but where the project is and what will provide the most benefit by improving it.

I’m saying all this after a week with the OpenStack guys – both in design sessions and just chillin’ out. Focused, intelligent, demanding conversations scattered through the week with an amazing “no-ego” attitude presenting itself. Not that there weren’t some good ole technical “best way to do it” or “which is better” fights, but given the breadth of this project and the open nature with vendors lurking all around the corners – well, frankly I expected a lot more “special interest” to be clearly showing itself. Everyone at that conference was interested in making OpenStack better at every turn.

250 people, 12 countries, 90 companies/organizations – all that after 3 months from being publicly announced. And they’re going it without any prior structure – building up an OpenStack foundation, doing all the legal and community building, right from scratch. And yeah – that’s showing right now.

The first thing I see that will provide the biggest gains:

  • “How do we all work together?”

Some of the best sessions were around “What does the status X of bugs mean” and talking through the development and release process. At this point I’m convinced the core folks are reasonably comfortable with LaunchPad (the platform the system is hosted on) – and being at the conference really taught me a great deal about how OpenStack is effectively using it. Prior, it wasn’t comfortable or familiar to me at all. The object store and compute (swift and nova, respectively) core groups are really quite separate teams, all trying to figure out how to get some common ground in re-using code, libraries, and even setting up documentation.

The second:

  • “Show me it’s workin’, again and again”

OpenStack is quickly heading to be the kernel or core of a platform. You could see it in the twinkle of Eucalyptus’ eye when they talked about Swift (the object store), or chatting with the folks from Scalr or RightScale. The whole system is being built with API in mind from the ground up, and while there is some pretty good unit testing in play and continuous integration, it was clear that installing this sucker was a PITA – and the documentation to really pull that all together starting coming together in the documentation sprint and install fest at the summit. One of the “blueprints” of the design summit (i.e. “Things we want to do, and how we want to do it for the next release”) is to get some fully automated integration testing as well as track the metrics on how the system is operating. There were a lot of folks that have some cross over into the Drizzle project, and the ideas of running and tracking benchmark data on every revision is darned power.

Add to that the benefits of a constant flow of functional testing against a couple of pre-defined clusters of both compute and object store, and you have a powerful engine to make sure trouble is spotted early and can be resolved quickly.

The third:

  • “How’s this thing tick?”

One of the admitted weak points is that some small, damned effective core teams have done most of the work – and if you want to understand the system, well… you’ve just got to read the code. That is a huge investment – and frankly a barrier to entry into the project that can be avoided with some effort towards docs and discussion. Again, great progress was made there (I learned what the “project” concept was in Nova at the summit) – but the interactions between components, what the components are responsible for, and what they’re *not* responsible for, are all kind of tricky to learn right now.

This extends down into digging into the code, where docstrings could be better (and are getting better!) so that if you wanted to go help with something specific, you didn’t have to grok a broad codebase to get a handle on what the impacts are of the changes you’ll need to make.

And the last thing I’ll throw in here:

  • “What OpenStack isn’t, or won’t do…”

The project is still in a lot of flux. There were some great components that were shown off at the summit that ride over the top of the infrastructure, or work with it through APIs. Should those be a part of OpenStack, or on the side? Some service providers were very interested in more platform-kind of elements – a common logging infrastructure, a common authentication, ID, and authorization infrastructure. Should that be a part, or on the side? How tightly or loosely do we want to couple some of these elements? The philosophy is there and forming up, but the real truth of it all will be over the next 6-12 months of the project when decisions are made, reviewed, and a core forms out of it. There have been a few architectural decisions made early: “Don’t mandate anything in the client”, “If a feature would restrict scale, it MUST be optional”, etc. that I absolutely applaud. I think it will form up more as projects apply to join the OpenStack umbrella and either make it or don’t. It will become clear what’s common, and what isn’t, pretty darn quickly.

I’m pumped about this project, the people, and it’s future. The core openstacker’s have clearly been driving up a steep hill to get to where they can level out a bit and move into more of a marathon mode. Really, it feels like we’re nearly at the top of that first hill.