By RangerRick, on May 7th, 2009
There has been a lot of discussion recently on the Open Source Definition, and the use (and abuse) of the term “Open Source.” One of the things that has been missing from this discussion is a higher-level overview of where the friction between “open source” and so-called “fauxpen source” comes from: intent.
The Open Source Definition arose out of the ambiguity of the word “free” in “Free Software,” as defined by the Free Software Foundation.” In the English language, “free” is a loaded term that has two meanings: “freedom”, and “costing nothing.” It was created to get rid of some of the emotional baggage that came with the intense philosophical point of view of the FSF, but just because the OSD is more “business-friendly” does not mean that it doesn’t have the philosophy and intent of openness behind it.
This friction comes from two very different approaches to open source that I think have been missing from a lot of the discussion regarding how open source applies to business models. I’m going to call these “community value” and “monetary value.”
In some ways, this dichotomy reminds me of the GPL (GNU Public License) versus the LGPL (Lesser GNU Public License). The GPL is a pure open-source license, which guarantees the user’s freedom by making it so that no software that uses GPL software can hide or restrict that use in a derivative work. The LGPL, on the other hand, was a compromise, a pragmatic license which allows one to create free software, but it does not require free distribution of things that link to that software. The LGPL has always clearly been discouraged by the FSF precisely because it compromises the freedoms guaranteed by the GPL.
Open Core: Nurturing Monetary Value (“Lesser” Open Source)
Advocates of using the term “open source” to apply to open-core and similar business models approach open source from a monetary value point of view. It is an approach of pragmatism: you create a business plan, get venture capital to get going, and sell software licenses to (hopefully) eventually pay back the VC firms and continue to grow. In many ways, an open-core business is exactly the same as any other startup. Open Source is not a fundamental philosophical part of the business, it is instead used to cut costs, and to help grow “buzz” about what your company is doing, and perhaps even get some free QA, bug reports, etc. The focus is not on creating a community to draw customers indirectly by improving the product, but to draw customers directly by creating awareness. To meet the demands of the venture capital, it requires a fast-growth, high-yield business model, and the community model doesn’t grow that fast.
In the end, how much work you do nurturing a community is directly a matter of how many you can convert to paying year-over-year for software licenses, or whatever other artificial scarcity you create. Once customers have decided they want the features only available in the up-sell (“enterprise”) version of your software, they have more resistance to changing to another product.
This is growing monetary value. The open-source community in a “monetary value” business is a side-effect of a marketing push to draw licensed customers. If the community goes away, you still have an essentially standalone commercial business that can continue just as if the community never existed. This is not to say the community doesn’t provide value, nor that it doesn’t derive value from the open source portion of their software, only that the business plan itself doesn’t hinge on the openness of the software.
Open Source: Nurturing Community Value (“Pure” Open Source)
On the other hand, “pure” open source business models (services & support, like my employer) approach business from a community value point of view. This is not to say that pure open source companies don’t want to make money — only that to be successful, we compete with much bigger companies by multiplying our value with that of the community. To be able to be competitive with companies with huge amounts of seed money, we can’t afford to treat our community just as a resource to be mined; our community is what makes it possible to support a large user-base with a small number of employees. Our community are like-minded individuals, working on this project with us together.
Since we are not beholden to venture capital, we don’t have to get quick returns to maximize stockholder returns. Instead what we need is to work with the community to make great software, and to continue to challenge ourselves to extend and expand our knowledge of that software, so we are able to provide our expert opinions as a service worth paying for. As long as we can pay the bills, give ourselves a comfortable salary, keep customers and the user-base happy, and grow the business, we consider ourselves successful. Our goal is to become the de facto network management platform, and we can do that better by not being in debt to venture firms for years.
On the surface, the value we and our community get from each other may not look that different from that of an open-core company, but looking deeper, there are a number of advantages to the “slow and steady wins the race” methodology we use:
- Everyone Gets the “Enterprise” Version
-
You are not held ransom for features that are only in the for-pay version. You can evaluate the product as it truly is, without time-limited evaluation licenses, crippleware with features missing, or annoying shareware reminders.
- No Software Licenses
-
The software isn’t artificially limited, it is capable of whatever your hardware is capable of without an arbitrary restriction because the sales VP decided that’s where to draw the line. Note that it’s easy to think that Red Hat is a counter-example, since they charge licenses for installed hosts, but from a freedom perspective, you can install the code on as many hosts as you like (ie, CentOS) without restriction, the restriction is only on “official” support.
- Everyone Benefits from Community Involvement
-
When the community adds value, everyone benefits. Users help each other with issues, provide patches, documentation, and so on. The community contribution to OpenNMS has been huge — not only major features, but default configuration for large amounts of network gear, which OpenNMS now supports out of the box on every new install.
- Everyone Benefits from Commercial Involvement
-
Since the code is 100% open-source, customers who pay for custom development not only get their own value from the transaction, but the software goes back into the mainline, and benefits everyone.
An anecdote: We had a support customer who paid for some custom development for a somewhat esoteric feature. It was originally done in a branch of OpenNMS something like 5 or 6 years ago. The OpenNMS code base has gone through huge upheavals, refactorings, and architectural changes since that feature was created, but since it was released back into the OpenNMS mainline, when they finally upgraded their production system to an up-to-date OpenNMS release, the feature continued to work. If a consulting company did that same custom work as an HP OpenView plugin, they would have to port/implement it all over again after 3 major version revisions of the upstream software.
- 100% Forkable
-
While we make a living supporting OpenNMS, we do not “own” the project. (Although, we do own the OpenNMS trademark — the realities of business in the US require it if we want to be able to protect the name of the project.)
At best we are stewards, but the list of OpenNMS employees is a fraction of the number of “core” contributors, and the core contributors are a fraction of the number of users who have added value to OpenNMS over the years.
We run and guide the project, but only because the community trusts us to do so. Our job is to earn that trust, by upholding the principles I’ve outlined above. When we do so, everyone gets value from OpenNMS. If we fail to do so, the OGP will “vote us off the island,” and if it becomes bad enough, the source is fully available so it can be forked to something the community approves of.
Either Approach is “Better,” but Only One is Truly Open
In the end, it’s like the difference between a stable community bank who personally knows every person it gives a loan to, and an investment bank bringing in money fast with high-risk derivatives; they are focused on providing value to two entirely different sets of people. Either approach is better depending on your point of view — they each have their advantages. However, in the end, I believe it is disingenuous to claim that open-core and similar business models have as much right to the phrase “open source” as pure open source businesses.
Share on Facebook
By RangerRick, on April 12th, 2009
Alright, folks, the bearding has commenced.
Now’s your chance to make a pledge for the Carolina Hurricanes Kids ‘n’ Community Foundation. Just hit the “Pledge a Friend” button, and put in “Benjamin Reed“.
If you know me, you know my dedication to never exposing my unfortunate double-chin to the horrors of sunlight. Don’t let this sacrifice be in vain! Pledge now!
Share on Facebook
By RangerRick, on April 9th, 2009
In the ’05-’06 Stanley Cup run, I grew a pretty substantial playoff beard, just for the heck of it. (see fig. 1, pictured right)
This time, the Hurricanes are doing a great charity event for the Kids ‘N Community Foundation: the Beard-A-Thon!
When the regular season games are over, I’m going to shave, and then grow a playoff beard as hard as I can.
Now, as I mentioned, it’s a charity event, and I need you folks to help me out, by pledging at the Beard-A-Thon page. Don’t forget to enter “Benjamin Reed” where it says, “ There’s a specific beard grower I’d like to support.”
Share on Facebook
By RangerRick, on April 3rd, 2009
I’ve just committed all of KDE 4.2.2 to Fink Unstable.
There’s still a lot of rough edges, but it’s definitely at least beta quality, and a lot of apps work great. It includes a number of fixes, including updated scripts to register all of the desktop files properly with ksycocoa on post-install, case-sensitive filesystem fixes, and a number of other packaging fixes. I’ve also finished packaging all of the “core” KDE distribution.
I’ve got Amarok working in my experimental tree, I just need to do a little more testing before I can release it (It’s based on a snapshot of what will become Amarok 2.1.0, since 2.0.x has some build issues on Mac OS X that are difficult to resolve). Also, the KOffice folks just put out a release candidate that I’m working on finishing up packaging on. Hopefully I will have that out soon.
As always, please let me know if you run into issues. I’ve test-built on 10.5/i386 and 10.4/ppc so I’m sure some 10.4/i386 and 10.5/ppc users will give bug reports soon. 
Share on Facebook
By RangerRick, on March 31st, 2009
If you’ve followed this blog for a bit, you know that I write music and (finally) released an album last year.
One of the places my music is available for download is bandcamp.com, who offers up a nice little download/portal service where you can make your music available. You can get my music there for free at 128kbit, or if you want to support my music, or get a higher-quality format (all the way up to FLAC and Apple Lossless!), you can name your own price.
I was looking at my download/listen statistics, and I saw something strange. They do 60-day, 30-day, week, or daily graphs, along with defender graphs.
Defender?!
So I clicked on it, and I saw the coolest most useless statistics graph ever. You can play defender in your graphs. The little UFO flies around, there’s people on the ground, and you can move your ship back and forth and shoot them. Awesome!
60-day graph:
Defender graph:
How cool is that!!?
Share on Facebook
By RangerRick, on March 22nd, 2009
I’ve had a chance to get a few more of the KDE4 packages polished up into what I hope is a releasable state. 
Please give them a shot, let me know if you have any issues, if things don’t work as expected. I know one major thing to look into still is to get document-opening working. Right now the KDE desktop files describe which apps should open different document types, but that is not being translated to OSX’s document-opening APIs.
The following packages were released to unstable today:
- digikam-mac and digikam-x11
- kdeaccessibility4-mac and kdeaccessibility4-x11
- kdeadmin4-mac and kdeadmin4-x11
- kdeartwork4-mac and kdeartwork4-x11
- kdeedu4-mac and kdeedu4-x11
- kdegraphics4-mac and kdegraphics4-x11
- kdemultimedia4-mac and kdemultimedia4-x11
Big ones left on the hitlist are amarok2 and koffice2. Amarok2 I’m starting work on again as a snapshot of the 2.1.0 build, since there are some issues with 2.0.x building on OSX. KOffice is actually working pretty well in my experimental tree, but 2.0 release candidate is due out in the next week or so, so I’m going to wait to update to that before doing a release.
Share on Facebook
By RangerRick, on March 16th, 2009
Since this blog is more about my own personal development on OSX, Fink, KDE, and OpenNMS, and This Week in OpenNMS is about, well, all of OpenNMS development, I figured it was high time to move it to somewhere more official.
Without further ado, I present to you: This Week in OpenNMS. Same bat-time, different bat-channel.
RSS is still available, but the url has moved here, rather than getting everything through my blog.
Please, update your links!
Share on Facebook
By RangerRick, on March 11th, 2009
Yes, that’s right, a post to my blog that isn’t about OpenNMS.
As you can tell, I’ve been pretty busy having fun hacking on OpenNMS lately. While I have been keeping up with my Fink work to some extent, one major thing was still looming: finally getting all the work I did on KDE/Mac released in Fink, now that things have stabilized.
If you’ve been watching the commits for the last few months, you’ve seen the beginnings of that work. Updates to Qt, releases of support things like strigi and soprano… The big hurdle was getting D-Bus in a state where it plays well with KDE/Mac. After some initial hiccoughs, the D-Bus updates have been released to Fink now, and seem to be working well for people.
Today, I released the base packages for KDE 4.2.x into fink: kdelibs4, kdepimlibs4, and kdebase4.
Because of the cross-platform nature of KDE, I’ve released them in 2 variants: mac and x11, so you can run konqueror as an X11 app, or as a mac app.
Some things will only be present in one or the other, for various reasons (X11-specific features, etc.) One thing that will be in the X11 variant that is not there now is kdebase-workspace, so no plasma desktop as of yet. I’ve built it, but it doesn’t act right currently, so I’m waiting to release until it’s in a usable state.
This is still early test stuff, so if you run into issues with it, please feel free to let me know and I’ll see what I can do.
I can’t thank enough Orville Bennett and the other KDE/Mac folks. They have picked up the early work I did on porting and ran with it, helping polish it into a nice, buildable, and solid set of code while I was on my “hiatus” from KDE packaging. They have done a lot of great work in helping bring native mac KDE from “freakish mutant” to “used every day by KDE developers.”
In the coming weeks I hope to get more of the base KDE packages done. I’m in the testing phase for koffice, amarok, kdeartwork, and a couple of others, and working my way through packaging more. I’ll post as I get anything interesting.
Share on Facebook
By RangerRick, on March 9th, 2009
 |
| Coding on the Porch |
I’ve decided to do This Week in OpenNMS on Mondays, instead of Fridays, since it’s more likely that people will be around to read it on Monday, and since then I don’t have to furiously write under a deadline Friday afternoon when I could be sitting out on the porch, sipping drinks and relaxing. Or something.
Anyways, welcome to This (well, Last) Week in OpenNMS!
Project Updates
-
Stable: Current Release is 1.6.2
1.6.2 is still the current release, and while there are a few fixes pending since it’s release, there are no immediate plans for a 1.6.3 yet.
-
Unstable: Current Release is 1.7.0
Trunk continues to move at a furious rate. We’re still hoping to get 1.7.1 out soon. Stay tuned for updates on that. In the meantime, feel free to try the nightly snapshots (if it’s not on a production system, of course).
-
Trunk: Build System Updates
Work has begun on refactoring our Maven build system. We’ve been trying to move a lot of things out of the main build, to speed up building and to componentize things that should be “external” dependencies. The new structure has been introduced, and we’re looking at eventually moving all of our code into this structure:
-
core: OpenNMS core. This will include event handling, basic daemon support, and other support code needed by all of OpenNMS.
-
api: Interfaces and basic APIs
-
lib: “Library” code (the majority of the core code)
-
runtime: Runtime code, ie, things only needed in a running OpenNMS instance
-
web: Web application code common to all of OpenNMS
-
doc: Documentation
-
features: Any feature of OpenNMS that can be modularized, and isn’t part of the Core. This will include most of the daemons (Notifd, Provisiond, etc.) Each feature gets it’s own directory, and will have a similar structure to the core module.
-
extensions: Any feature of OpenNMS that does not need to be built by default for a basic running OpenNMS installation (ticketing integrations, etc.) Each extension gets it’s own directory, and will have a similar structure to the core module.
-
lib: Support “library” code used by any part of OpenNMS, which can be a standalone package. The lib directory is not built by default, but instead deployed to the maven repository as they are updated as if they were individual projects. Examples include the service-registration framework (DNS-SD advertising), our version of JoeSNMP, and the SNMP strategies.
-
assemblies: Assemblies in maven describe how all of these various components get packaged up together. The plan is to make multiple assemblies for a minimal system, full install, and so on so you can choose how much OpenNMS you want when building from source. Having multiple assemblies will also make it easier to run just a portion of OpenNMS for development and testing.
-
Trunk: Provisiond
Provisiond is solidifying, the only major word to be done is support for the newSuspect events to fully replace Capsd’s functionality. Lots of performance work has been going on in it as well, so it should be able to very quickly scan networks that took a long time under Capsd.
-
Trunk: RANCID
Antonio and Guglielmo have been working hard on the RANCID adapter. I’m told the RANCID map integration is very cool, but I haven’t had a chance to check it out yet. It’s in the latest snapshots.
-
Trunk: DNS Provisioning Adapter
I worked on Dave’s provisioning adapter some, and got it working. Now whenever a node is added/updated/deleted, we can update a dynamic DNS server with the new hostname -> IP address mapping based on the node label in the provisioning group node configuration. It’s a good example of how to make a provisioning adapter.
-
Trunk: UI Enhancements
Donald continues to make our UI more interactive, and handle large numbers of elements sanely. The node page is looking pretty sweet.
-
Trunk: Event Parameter Name Extraction
Jeff did a useful little feature to be able to use parameter names in %parm% expansions. See bug #3061 for details.
About the Inventory Scanner
Matt Raykowski has been working on a very cool feature in a branch called the inventory scanner. I asked him to send me a quick summary of what his goals are for the inventory scanner, and here’s what he said:
Inventory Scanning is a protocol agnostic daemon tasked with collecting inventory and asset information from hosts through whichever means available to it through the coded scanners. At the present point in time only a WMI scanner exists but I plan on trying to get someone “onboard” to write a SNMP scanner and I plan on writing a telnet/ssh-based scanner that works similar to Expect.
Inventory Scanning saves inventory information in three layers: category, asset, property.
- Categories are high level classifications of assets. For example there may be a “Network Adapters” category. Categories are defined in the configuration and are not driven from host-based data.
- Assets are items of interest from hosts. Examples of assets would be “Broadcom 100MB Network Adapter.”
- Properties are the individual components of information for a given asset. To continue our previous example you would have a manufacturer, serial number and assorted configuration information.
Categories are largerly going to be used for grouping and organization in the web representation of inventory information. All assets and properties will be idenfitied with a source, whether they’re active and an effective date. During the process of scanning the scanner will collect all configured information from the host and pass that information to a persister which will go through the process of comparing the scanned asset information to the most effective version of the hosts configuration. It will add new properties and assets as they appear and remove (by setting the property or asset as deleted) any assets in the effective configuration set that are not in the scanned collection and were defined by that scanner source.
This last part is important: whatever is scanned and saved will have a history. When that history changes a UEI will be emitted for interested parties, potentially for notification. But the tracking of the source is important since now you can have multiple protocols maintaining asset information on a single host in addition to providing the user with limitless ability to manually add custom asset information.
Despite the fact that it can keep a history of inventory information in the database and the UI will have the ability to browse history and the user will have the ability to be notified on configuration change events this is not intended to be an enterprise grade replacement for other CMDB tools or inventory tools. It will not have the ability to send configuration changes to hosts, and at least in my incarnation no ability to differential comparisons between hosts or versions. Although this could be added on by some enterprising member of [The OpenNMS Group] or the community if someone decided this was a feature they desired.
Very cool stuff, Matt!
Upcoming Events
Note: April training has been pushed back to May.
If you have anything to add to the events list, or you wish to be a Dev-Jam sponsor, please let me know.
That’s It!
That’s it for this week. As always, questions, comments, non-sequiturs, gifts, and bribes are always welcome, feel free to e-mail me. And if you have a question about OpenNMS that you think would be a good topic in TWiO, please, let me know!
Share on Facebook
By RangerRick, on February 27th, 2009
So I’m a slacker. But I have an excuse, really! I was having so much fun working on JSPs last Friday, that I totally forgot to write TWiO last week. OK, it’s JSPs, so I guess I’m lying about having fun, but I was really almost done with a new feature.
Anyways, since I’ve gotten a little sloppy, I’m going to make it up for you, with a feature on the new Provisiond, which is shaping up quite nicely. And to show my shame, I’ve dubbed this week’s article: This Week (or Two) in OpenNMS.
But, to begin… What’s been going on for the last two weeks?
Project Updates
 |
| New Node Page |
-
Stable: Current Release is 1.6.2
1.6.2 is still the current release, and while there are a few fixes pending since it’s release, there are no immediate plans for a 1.6.3 yet.
-
Unstable: Current Release is 1.7.0
Commits have been speeding by on trunk as Provisiond moves it’s way into a feature-complete state. I’m still hoping we’ll get a 1.7.1 release out soon so people can give it a shot, but, well, we have to stop to breathe first. In the meantime, feel free to try the nightly snapshots (if it’s not on a production system, of course).
-
Trunk: RANCID Updates
Antonio and Guglielmo have been furiously working away on the RANCID integration, focusing on authentication, and the UI for the most part.
-
Trunk: SNMP Refactoring
Matt has spent some time refactoring some of the SNMP data so that it is instead in the snmpInterface table where it belongs, and it means no more 0.0.0.0 IPs where they don’t belong. This cleans up our model a bit to be more sane. (A bit.)
-
Trunk: Provisiond Updates
Provisiond is nearing feature-complete, and is definitely at a point where it can be tried out on real-world networks. See below for a feature on Provisiond.
-
Trunk: Node Page Updates
Donald and Matt have both been working on updating the node page to be more dynamic. It’s pretty slick now, offering tabs detailing various information related to the node.
-
Branch: Inventory Management
Matt Raykowski continued work on his inventory daemon. I’m still waiting for a more detailed update of what it does/will do, I’ll try to get an update before next week’s TWiO.
 |
| Provisioning Groups: UI |
| |
 |
| Provisioning Groups: Edit Requisition |
| |
 |
| Provisioning Groups: Edit Foreign Source |
A History Lesson
Architecturally, OpenNMS is very sound. It was written from the beginning with scalability in mind, by people who had been dealing with network management for their entire careers. However, Java, as a language (and as an environment), has grown immensely in power, reliability, and expressiveness since we started this project. Gone are the heady days of requiring IBM’s 1.3 JDK because it was the only one that handled large numbers of open ports gracefully.
That does not mean all remnants of those days are gone, however.
Over the years, most of OpenNMS has gone through an architectural upgrade, under the guidance of Matt Brozowski. Whole subsystems were cleaned up, rewritten, and/or modernized. 3 glaring exceptions remained, until recently: Capsd (the capability scanner), Notifd (the notification engine), and the web UI (I don’t know if it’s web 1.0, or web 0.9, but well… it needs an upgrade.) Thanks to the recent implementation of Provisiond, I’m happy to say we only have two glaring exceptions to the wonderful architectural upgrades OpenNMS has gone through. Notifd: I’m coming for you next!
Capsd! Huugh! Good God, Y’all! What Is It Good For?
OpenNMS has three distinct phases when it comes to how it discovers and works with nodes:
-
Discovery (What’s Out There?)
Discovery is the beginning of the life of a node. OpenNMS does a ping sweep across the range of addresses specified in your configuration, and says, “did it respond?” If the answer is “yes,” discovery shouts into the event bus, “HEY! I suspect I might have found a new node!” Discovery is not actually a requirement of OpenNMS, it is entirely possible to use it without doing discovery, either by sending your own newSuspect event (through a script, or the “Add Interface” link in the admin UI), or by using the model importer.
-
Capability Scanning (What Does It Do?)
Capsd, the capability scanning daemon, listens for newSuspect events, and says, “Hmm, what is this IP address capable of?” It does service scans (based on the capsd plugins defined), checks for SNMP, and does some other things to determine whether it’s a new node or part of another node, and what services are publicly listening.
-
Monitoring (Is It Still Doing It?)
Once a node has been discovered and capability scanned, it goes into the queue to be monitored, based on the poller-configuration. At that point it becomes a part of the normal poll/data-collection/thresholding/notification cycle that you know and love.
The Model Importer
Some of our users are integrating OpenNMS into larger systems, or want tighter control over what nodes OpenNMS is aware of than can be provided by a ping sweep and Capsd scan. For that, we wrote the model importer, or “provisioner”.
To use the model importer, you would create an import definition XML file, which describes the nodes, their interfaces, and services which you want to manage directly. Most folks who are doing this either export from some other internal database of managed nodes, or use the Manage Provisioning Groups UI and custom-build a set of nodes directly. You hit the import button, and voila! Your database is populated with the exact set of nodes, interfaces, and services you specified.
This is very powerful, but also very rigid. It’s pretty much an all-or-nothing affair; there’s no room for discovering extra information about provisioned nodes.
What Does Provisiond Do?
Provisiond replaces the functionality of Capsd, and replaces and expands upon the old model importer, by defining not only the nodes and interfaces you wish to monitor, but also adding the ability to distinguish how we should behave when importing these nodes. It has a pluggable architecture which allows for defining policies such as, “scan the imported node, and if it’s in this IP address range, automatically put it in the routers category,” and “scan the specified interface, automatically discover the SNMP interfaces, and if they are non-IP, don’t bother putting them in the database.”
Architecturally, Provisiond is chopped up into a number of subsystems:
-
The Provisioner
This is the meat of provisiond, it’s responsible for managing a provisioning “lifecycle,” which includes scheduling scans, listening for events, and kicking off the various parts of scanning and writing to the database. Matt has written a very powerful engine for doing these various tasks which I suspect will move into other parts of the code as we refactor them in the future. There’s a lot more flexibility in determining when things will be scanned than Capsd’s main loop.
-
Detectors
The detectors are the replacements for Capsd scanners, and they’ve received an upgrade over their Capsd counterparts as well. They’ve been rewritten with an architecture that allows them to run asynchronously, so service scans which take a while don’t have to bottle up the scanning of other nodes. Additionally, the SNMP scanning has received an upgrade that lets us react to bulk gets as soon as a complete “row” of data is received, so node sub-interfaces discovered through SNMP will start showing up sooner.
-
Policies
Policies act as filters on the data as it’s coming in. We’ve got a few simple ones in the first release, but since they’re written with a very simple and pluggable API, it makes it easy for you to define your own business logic by creating an incredibly simple class and dropping it in the classpath.
A Bit More on the Model
The existing model importer had the concept of a “provisioning group,” which is a collection of node/interface/etc. definitions, and was configured through the Manage Provisioning Groups UI. Each provisioning group had a “foreign source” which defined a discrete collection of nodes, so that if you removed a node from that foreign source, it would be deleted from the database as well.
In Provisiond, the foreign source is no longer just a tag that’s a unique identifier, it’s a definition of the behavior of the provisioner (ie, defines the detectors and policies). To that end, we’ve renamed the generic “provisioning group” to a Requisition. There is then a separate configuration for the Foreign Source which defines the policies which describe how the requisition is imported.
What Works?
At this point, almost everything. The only thing missing is the part that listens for newSuspects, so it doesn’t completely replace Capsd as of yet. However, barring that, all of the functionality of Capsd is essentially implemented in Provisiond at this point.
How Do I Try It?
Grab a 1.7.1 snapshot or build from source, and fire it up. Provisiond is enabled by default now, and you can go to the Manage Provisioning Groups link in the UI to try it out. Did I mention this is unstable software? Really, it’s unstable software. Don’t do this on a production system! That said, it’s cool. =)
Upcoming Events
If you have anything to add to the events list, or you wish to be a Dev-Jam sponsor, please let me know.
I’m Beat
Man, it was a lot of work to write that up. I’m so tired, I just might miss TWiO next week. We’ll just have to see.
As always, if you wish to berate me publicly, feel free to leave a comment on my blog, and if you wish to berate me privately, feel free to send me an e-mail. Until next time!
Share on Facebook
|
|
|
