As part of our ongoing efforts to improve documentation...
1. We've posted updated ControlTier installation instructions on Open.ControlTier.
The key installer enhancements for 3.1 are:
* Out-of-the-box compliance with the self-contained directory convention largely avoiding the need to edit "default.properties".
*Jobcenter installation support has been completed including start/stop scripts.
The instructions have been tested on both Windows and Linux using the latest 3.1 release candidate.
2. New ModuleForge documentation has been posted. This includes new documentation for the ATG, Content Deployment, and RDB Deployment libraries.
As always, feedback on the mailing list is greatly appreciated.
Thursday, December 06, 2007
Monday, November 26, 2007
ControlTier 3.1rc1 relesased
We are happy to announce that 3.1rc1 has been released. 3.1rc1 includes a number of bug, performance, and usability enhancements. We are now on the home stretch towards a general release for 3.1!
Below is an extensive list of the fixes that have gone in the last beta and this first release candidate. Changes are group by whether they are in the ControlTier project or and the underlying AntDepo framework (with tracker ID, if available):
ControlTier (http://sourceforge.net/tracker/?group_id=151079)
* #1740053 – dispatchCmd support for remote user name
* #1807666 – Add ThreadCount to Mediator’s dispatchCmd
* #1620501 – Workbench/Activity Report: URL query-able activity report
* #1776641 – Show command usage for Deployment objects
* #1769627 – Ant task to check if Workbench project exists
* #1766323 – creating a project from the command line
* #1720429 – library import support for ProjectBuilder
* ProjectBuilder: XML based object definition format (projectxml)
* make logging messages consistent format
* report task to echo report text to console
* Mediator dispatchCmd option initialization supported by full set of attributes
* Mediator: add support for passing buildstamp
* ProjectBuilder: For command generate-objects, add support for projectxml format
* ProjectBuilder: add -load option to build-library to load built library to server
* Package: ensure all the package metadata field values are passeed into the “install” command.
* Deployment: move runChangeDependencies from Updater to Deployment
* Deployment: new “Deploy” command to supersede “Update”
* Builder: allow non propfile method to repoImport
* Builder: Automatic multi-package (Builder) repoImport
* Installer: Follow CTIER_ROOT self-contained directory convention
* Workbench: Initial integration with AntDepo to streamline antdepo object installation
* Java code interdependencies among the ControlTier components have been separated into a common library
* the change-package-dependencies task/action has been altered on the server side to remove the use of rules-based reasoning with the Jena engine, bringing performance improvements and adding resilience to model inconsistencies.
* change-package-dependencies now behaves as expected when the package Type specified is actually a sub-type of one of the allowed-types for the dependencies.
AntDepo (http://sourceforge.net/tracker/?group_id=147344)
* #1803918 – lazy framework initialization. Loads lazily and now dynamic.
* #1765616 – Support get-opts “defaultproperty” attribute
* #1835431 – depot-setup option:—name <>
* #1835432 – depot-setup action name change
* Antdepo now has a ‘framework.ssh.user’ property, used as the username when invoking SSH executions.
* Read “framework.ssh.user” from command execution context. Will default to value in framework.properties file.prefix logged messages with command context info
* depot-setup now must use -p option
* Allow Framework object to be embedded in long running server processes.
* Add java min/max heap settings to cmdline client
* Add ignormalformed and propertydefault attributes
Below is an extensive list of the fixes that have gone in the last beta and this first release candidate. Changes are group by whether they are in the ControlTier project or and the underlying AntDepo framework (with tracker ID, if available):
ControlTier (http://sourceforge.net/tracker/?group_id=151079)
* #1740053 – dispatchCmd support for remote user name
* #1807666 – Add ThreadCount to Mediator’s dispatchCmd
* #1620501 – Workbench/Activity Report: URL query-able activity report
* #1776641 – Show command usage for Deployment objects
* #1769627 – Ant task to check if Workbench project exists
* #1766323 – creating a project from the command line
* #1720429 – library import support for ProjectBuilder
* ProjectBuilder: XML based object definition format (projectxml)
* make logging messages consistent format
* report task to echo report text to console
* Mediator dispatchCmd option initialization supported by full set of attributes
* Mediator: add support for passing buildstamp
* ProjectBuilder: For command generate-objects, add support for projectxml format
* ProjectBuilder: add -load option to build-library to load built library to server
* Package: ensure all the package metadata field values are passeed into the “install” command.
* Deployment: move runChangeDependencies from Updater to Deployment
* Deployment: new “Deploy” command to supersede “Update”
* Builder: allow non propfile method to repoImport
* Builder: Automatic multi-package (Builder) repoImport
* Installer: Follow CTIER_ROOT self-contained directory convention
* Workbench: Initial integration with AntDepo to streamline antdepo object installation
* Java code interdependencies among the ControlTier components have been separated into a common library
* the change-package-dependencies task/action has been altered on the server side to remove the use of rules-based reasoning with the Jena engine, bringing performance improvements and adding resilience to model inconsistencies.
* change-package-dependencies now behaves as expected when the package Type specified is actually a sub-type of one of the allowed-types for the dependencies.
AntDepo (http://sourceforge.net/tracker/?group_id=147344)
* #1803918 – lazy framework initialization. Loads lazily and now dynamic.
* #1765616 – Support get-opts “defaultproperty” attribute
* #1835431 – depot-setup option:—name <>
* #1835432 – depot-setup action name change
* Antdepo now has a ‘framework.ssh.user’ property, used as the username when invoking SSH executions.
* Read “framework.ssh.user” from command execution context. Will default to value in framework.properties file.prefix logged messages with command context info
* depot-setup now must use -p option
* Allow Framework object to be embedded in long running server processes.
* Add java min/max heap settings to cmdline client
* Add ignormalformed and propertydefault attributes
Monday, October 01, 2007
ControlTier 3.1b1 and Job Center
I'm happy to announce that ControlTier 3.1b1 with the new Job Center has been released.
ControlTier 3.1-beta-1 has bug fixes and performance enhancements throughout Antdepo and Workbench. But the biggest thing included in this release is the new Job Center application.
Job Center
Job Center is a web interface for creating, scheduling and managing jobs executed in the Antdepo environment. It is still in Alpha form (0.4-alpha), so the interface may eventually be different and bugs may pop up.
Features include:
Job Center development required converting the Antdepo Framework concept into an embeddable application. Since Antdepo executes in the Ant environment, this posed some problems because Ant was not necessarily designed to be embedded within another application. Until now, Antdepo has not had to address this problem because the Antdepo context is necessarily single-user and short-lived when running as a command line application. Converting this method of operation into a multi-user, long-lived web server process paradigm required getting over some hurdles in both the Ant and Antdepo frameworks.
One problem brought up by Ant was that of output on STDOUT and STDERR. For example, when a command is dispatched to a remote Node, an Ant SSHExec task is created to handle the SSH connection to a node and execution of a remote Antdepo command. The SSHExec task in Ant prints its output to STDOUT and STDERR. With the command-line "ad" command this is not a problem. However in Job Center the output of the command has to be captured by the executing thread in order to make it visible for the user. In addition, multiple commands may be running simultaneously in several Java Threads, and if multiple commands are executing SSHExec tasks then all of the output will end up on the output console and not in the command log where we want it to go.
The solution to this problem is to use a custom replacement for the Java System's standard-output and standard-error PrintStream objects. By using the special InheritableThreadLocal class, the STDOUT and STDERR can be replaced by a custom OutputStream for each command Thread. The OutputStream is then inherited by any child Threads spawned by the command thread. This is necessary because SSHExec specifically uses another Thread while it is executed, and other tasks may do the same thing. This custom OutputStream logs the execution output to a file for use by Job Center to view the command output. After execution, the InheritableThreadLocal is cleared of the custom OutputStream for the Thread.
ControlTier 3.1-beta-1 has bug fixes and performance enhancements throughout Antdepo and Workbench. But the biggest thing included in this release is the new Job Center application.
Job Center
Job Center is a web interface for creating, scheduling and managing jobs executed in the Antdepo environment. It is still in Alpha form (0.4-alpha), so the interface may eventually be different and bugs may pop up.
Features include:
- Jobs can either be transient (one-off), stored for on-demand execution, or scheduled to run periodically.
- Job execution progress can be followed live on the web
- Browse, filter and customize reports of previously executed jobs
- Easy access to all Jobs that are Now Running, or have recently finished executing.
- Intuitive interface.
Job Center development required converting the Antdepo Framework concept into an embeddable application. Since Antdepo executes in the Ant environment, this posed some problems because Ant was not necessarily designed to be embedded within another application. Until now, Antdepo has not had to address this problem because the Antdepo context is necessarily single-user and short-lived when running as a command line application. Converting this method of operation into a multi-user, long-lived web server process paradigm required getting over some hurdles in both the Ant and Antdepo frameworks.
One problem brought up by Ant was that of output on STDOUT and STDERR. For example, when a command is dispatched to a remote Node, an Ant SSHExec task is created to handle the SSH connection to a node and execution of a remote Antdepo command. The SSHExec task in Ant prints its output to STDOUT and STDERR. With the command-line "ad" command this is not a problem. However in Job Center the output of the command has to be captured by the executing thread in order to make it visible for the user. In addition, multiple commands may be running simultaneously in several Java Threads, and if multiple commands are executing SSHExec tasks then all of the output will end up on the output console and not in the command log where we want it to go.
The solution to this problem is to use a custom replacement for the Java System's standard-output and standard-error PrintStream objects. By using the special InheritableThreadLocal class, the STDOUT and STDERR can be replaced by a custom OutputStream for each command Thread. The OutputStream is then inherited by any child Threads spawned by the command thread. This is necessary because SSHExec specifically uses another Thread while it is executed, and other tasks may do the same thing. This custom OutputStream logs the execution output to a file for use by Job Center to view the command output. After execution, the InheritableThreadLocal is cleared of the custom OutputStream for the Thread.
Sunday, September 23, 2007
Why Open Source ControlTier is a Good Thing for Our Customers
Why is ControlTier's open source model a good thing for ControlTier customers?
Simply put, it's about giving customers freedom and helping them better align their IT costs with their business.
More specifically*:
1. Open source platforms can be leveraged to a far greater benefit
If you look across the software industry for past 5 or so years, you'll see that the new platforms that have been widely adopted are all open source platforms. This success has more to do with freedom then with a license price.
The success of any technical platform depends on a user's willingness to invest in the skills needed to leverage that platform to its fullest extent. The only way developers (and in turn, a development organization) will get the maximum return on that investment is if they are acquiring an open and transferable skill.
Users must be free to reuse the platform and their skills anywhere and anyhow they see fit. Any license or monetary barrier that stops reuse diminishes the value of the platform.
With ControlTier, you can be assured that any effort put into learning or using the platform can be reused and leveraged across your organization however you see fit.
2. Open source licenses don't restrict your business
There are different ways that traditional closed-source license schemes measure deployment and use. However, they all have one thing in common, the more you use the more you pay. This business model ends up imposing an artificial "tax" (mental and monetary) on your business operations.
In the changing world of online services, you must be able to scale your environment in any direction you wish. Constraints on where you can deploy licensed software only interfere with your business. As architectures become even more service oriented, the physical infrastructure is shared across multiple services and business applications. Aligning those infrastructure costs to any particular business function becomes very difficult in these new architectures.
If you want to move to a larger number of commodity servers, you shouldn't have to pay more. If you want to open another disaster recovery center, you shouldn't have to pay more. If you want to broaden the use of the software to include other employees, you shouldn't have to pay more. You should be free to change the scope and shape of your physical environment or operations in any way you see fit and not be penalized for it.
Another way that closed-source licensing restricts your business is by forcing upgrade cycles upon you. Updates or fixes are limited to what the vendor wants to give you. Upgrades or new versions generally only come after additional negotiation and you are forced to accept a bulk of features that you may not want or need.
With ControlTier, you are free to distribute or use our software in any way you wish. You are also free to modify our software in any way you like, so long as you honor the spirit of the open source license. The fact that we aren't selling upgrades avoids feature bloat and encourages you can accept or make updates on your own schedule.
ControlTier also has a strong aversion to the "per box tax" when it comes to our support and implementation services. To us, we are being paid to help you design and deploy automation for a particular business application, process, or stack. The complexity of the automation and the level of support we provide is what determines our compensation, not where the automation is installed or how many users or machines rely on it. This makes it easier for our customer to directly align their costs with particular business applications or services.
3. Open Source ensures that ControlTier's business goals and our customers' business goals are aligned
Open source licensing combined with a services and support-based business model ensures that our goals are aligned with our customer's goals. At ControlTier we earn our revenue by providing direct value to our customers. This is quite different from traditional closed-source business models where customers pay a large fee upfront and then significant annual fees for the promise of value being delivered in the future. For those vendors the biggest incentive is on selling you more promises, not on deliver on those promises.
Under our model we have to prove direct and measurable value for each dollar a customer spends with us. If we don't prove that we can get the implementation done with the highest quality and lowest price point, you are free to go elsewhere (most likely in-house). If our support services don't deliver on their value, you are free to drop them. Our model keeps us on our toes and forces us to find new ways to help you make more money. To us, that seems to be a better deal for everyone.
*Note: You'll probably notice that license cost isn't on this list. Of course, getting something with significant commercial value for free is a nice thing, but that really doesn't tell the whole story as to why the Open Source model is a vastly superior one for enterprise customers. Additionally, no matter what a vendor charges for a closed source license, that dollar amount is trivial compared to how the freedom of true open source software changes the overall economics and manageability of a customer's business.
Simply put, it's about giving customers freedom and helping them better align their IT costs with their business.
More specifically*:
1. Open source platforms can be leveraged to a far greater benefit
If you look across the software industry for past 5 or so years, you'll see that the new platforms that have been widely adopted are all open source platforms. This success has more to do with freedom then with a license price.
The success of any technical platform depends on a user's willingness to invest in the skills needed to leverage that platform to its fullest extent. The only way developers (and in turn, a development organization) will get the maximum return on that investment is if they are acquiring an open and transferable skill.
Users must be free to reuse the platform and their skills anywhere and anyhow they see fit. Any license or monetary barrier that stops reuse diminishes the value of the platform.
With ControlTier, you can be assured that any effort put into learning or using the platform can be reused and leveraged across your organization however you see fit.
2. Open source licenses don't restrict your business
There are different ways that traditional closed-source license schemes measure deployment and use. However, they all have one thing in common, the more you use the more you pay. This business model ends up imposing an artificial "tax" (mental and monetary) on your business operations.
In the changing world of online services, you must be able to scale your environment in any direction you wish. Constraints on where you can deploy licensed software only interfere with your business. As architectures become even more service oriented, the physical infrastructure is shared across multiple services and business applications. Aligning those infrastructure costs to any particular business function becomes very difficult in these new architectures.
If you want to move to a larger number of commodity servers, you shouldn't have to pay more. If you want to open another disaster recovery center, you shouldn't have to pay more. If you want to broaden the use of the software to include other employees, you shouldn't have to pay more. You should be free to change the scope and shape of your physical environment or operations in any way you see fit and not be penalized for it.
Another way that closed-source licensing restricts your business is by forcing upgrade cycles upon you. Updates or fixes are limited to what the vendor wants to give you. Upgrades or new versions generally only come after additional negotiation and you are forced to accept a bulk of features that you may not want or need.
With ControlTier, you are free to distribute or use our software in any way you wish. You are also free to modify our software in any way you like, so long as you honor the spirit of the open source license. The fact that we aren't selling upgrades avoids feature bloat and encourages you can accept or make updates on your own schedule.
ControlTier also has a strong aversion to the "per box tax" when it comes to our support and implementation services. To us, we are being paid to help you design and deploy automation for a particular business application, process, or stack. The complexity of the automation and the level of support we provide is what determines our compensation, not where the automation is installed or how many users or machines rely on it. This makes it easier for our customer to directly align their costs with particular business applications or services.
3. Open Source ensures that ControlTier's business goals and our customers' business goals are aligned
Open source licensing combined with a services and support-based business model ensures that our goals are aligned with our customer's goals. At ControlTier we earn our revenue by providing direct value to our customers. This is quite different from traditional closed-source business models where customers pay a large fee upfront and then significant annual fees for the promise of value being delivered in the future. For those vendors the biggest incentive is on selling you more promises, not on deliver on those promises.
Under our model we have to prove direct and measurable value for each dollar a customer spends with us. If we don't prove that we can get the implementation done with the highest quality and lowest price point, you are free to go elsewhere (most likely in-house). If our support services don't deliver on their value, you are free to drop them. Our model keeps us on our toes and forces us to find new ways to help you make more money. To us, that seems to be a better deal for everyone.
*Note: You'll probably notice that license cost isn't on this list. Of course, getting something with significant commercial value for free is a nice thing, but that really doesn't tell the whole story as to why the Open Source model is a vastly superior one for enterprise customers. Additionally, no matter what a vendor charges for a closed source license, that dollar amount is trivial compared to how the freedom of true open source software changes the overall economics and manageability of a customer's business.
The ControlTier Manifesto (a work in progress)
The word manifesto may be a bit too overloaded, but we've always hated the meaningless content of corporate mission statements. So here it is:
The ControlTier Manifesto
Who we are...
1. We are a unique combination of development and operational experts that have lived in each others' shoes. With a deep understanding of each others problems and requirements, we have set out to streamline and automate operations across development, QA, and production environments.
2. We are developers and administrators who are determined to provide services that give our customers a competitive advantage by enabling them to achieve operational excellence and improved margins.
What we do...
1. We are our customers automation partners. We act as their independent agents of change focused on improving the efficiency of the application lifecycle through streamlined processes and extensive automation. We don't just provide the missing tools, we provide the expertise and accumulated best practices needed to successfully implement the tools and bridge the gaps between the various groups involved with the application lifecycle.
2. We develop and implement model-driven toolchains that automate build, deployment, configuration, and management activities. These toolchains implement an enterprise's specific processes, are reusable across all environments, are built to be flexible and extensible, and are built on open source tools and frameworks.
Further, we believe...
1. Build, deployment, and configuration activity happens all across the application lifecycle and impacts Development, QA, and Operations budgets. Too many talented and expensive technical resources, in every group, are being consumed by these non-value adding activities.
2. While acknowledging that writing source code has some elements of an artistic endeavor, the rest of the application lifecycle is a strict engineering endeavor and must be be expected to have the same level of widespread reliable automation and visibility that is found in traditional manufacturing operations.
3. The point of companies that operate software as a revenue producing service is to operate software as a revenue producing service. It is pointless for all software not to be "operations-ready" from the moment it is checked-in by developers. To enable operational readiness, all Development, QA, and Operations groups must be linked by a common automated build deployment framework.
3. All automation must pass the "two toss" test: If you throw any machine out of a window, can you automatically and instantly rebuild your service to a properly working state? If you toss any developer or admin out of a window, does your ability to deploy and maintain your service remain intact?
4. In order to be successfully adopted, automation frameworks must be available under a free Open Source license. Developers want open, transferrable skills to which they are free to apply in any manner, form, or frequency they see fit. Enterprises should be free to utilize, modify, or extend their automation (and its underlying framework) in any manner, form, or frequency they see fit. Traditional closed source licensing only places an unnecessary and burdensome "tax" on both individuals within the enterprise and the enterprise itself.
The ControlTier Manifesto
Who we are...
1. We are a unique combination of development and operational experts that have lived in each others' shoes. With a deep understanding of each others problems and requirements, we have set out to streamline and automate operations across development, QA, and production environments.
2. We are developers and administrators who are determined to provide services that give our customers a competitive advantage by enabling them to achieve operational excellence and improved margins.
What we do...
1. We are our customers automation partners. We act as their independent agents of change focused on improving the efficiency of the application lifecycle through streamlined processes and extensive automation. We don't just provide the missing tools, we provide the expertise and accumulated best practices needed to successfully implement the tools and bridge the gaps between the various groups involved with the application lifecycle.
2. We develop and implement model-driven toolchains that automate build, deployment, configuration, and management activities. These toolchains implement an enterprise's specific processes, are reusable across all environments, are built to be flexible and extensible, and are built on open source tools and frameworks.
Further, we believe...
1. Build, deployment, and configuration activity happens all across the application lifecycle and impacts Development, QA, and Operations budgets. Too many talented and expensive technical resources, in every group, are being consumed by these non-value adding activities.
2. While acknowledging that writing source code has some elements of an artistic endeavor, the rest of the application lifecycle is a strict engineering endeavor and must be be expected to have the same level of widespread reliable automation and visibility that is found in traditional manufacturing operations.
3. The point of companies that operate software as a revenue producing service is to operate software as a revenue producing service. It is pointless for all software not to be "operations-ready" from the moment it is checked-in by developers. To enable operational readiness, all Development, QA, and Operations groups must be linked by a common automated build deployment framework.
3. All automation must pass the "two toss" test: If you throw any machine out of a window, can you automatically and instantly rebuild your service to a properly working state? If you toss any developer or admin out of a window, does your ability to deploy and maintain your service remain intact?
4. In order to be successfully adopted, automation frameworks must be available under a free Open Source license. Developers want open, transferrable skills to which they are free to apply in any manner, form, or frequency they see fit. Enterprises should be free to utilize, modify, or extend their automation (and its underlying framework) in any manner, form, or frequency they see fit. Traditional closed source licensing only places an unnecessary and burdensome "tax" on both individuals within the enterprise and the enterprise itself.
Subscribe to:
Posts (Atom)