September 2006

(September 30th 2006) Release 2.1.7

YencaP core and YencaP-Manager core are almost finished (I mean the features implementation, not the bugs). Extension modules are not finished.

Access control is done also for copy-config and delete-config
API changed for Module class
- def get(self, configName):
- def getConfig(self, configName): where configName is one of "running", "candidate" or "startup". (These constants are accessible via C.RUNNING, C.CANDIDATE, C.STARTUP).
- def copyConfig(self, sourceName, targetName, sourceNode = None):
- def validate(self, targetname, moduleNode = None): where targetname is one of "running", "candidate", "startup" or "config" (the last case requires that the moduleNode must be given as parameter). validate operation is from Maximilian Huetter.

(September 25th 2006) Bug fixes and more

Humberto fixed a bug in BGP module. (for the demo)
Maximilian added support for validate operation (not tested yet)
RBAC improvement for being able to activate a junior role of the assigned roles. (for the demo)

(September 22th 2006) Design refactoring

I refactored the page generation process of YencaP Manager. All pages now inherit from a common model (Page class). This class has three sub classes: mainPage for the agent selection, AgentConnectedPage for managing a given agent and AgentReachablePage which gives minimal info about an agent. AgentConnectedPage has many sub classes corresponding to different things:

Forms for Netconf operations
Module forms using XSLT

It should be now much easier to build new pages. I also start ed to update the documentation of YencaP Manager. See Documentation.

(September 20th 2006) Python 2.5 has been released

The good news is that EnSuite works with python 2.5 (installed from tar.gz, not rpm). The only thing is that it prints a lot of warnings, but I think this should be solved in the official rpm of Fedora. I didn't notice big changes on performances compared with 2.4.

(September 18th 2006) Refactoring module of YencaP

BGP module and Route module should be updated. BGP module integrates route-maps whereas they are not specific to BGP. Route module uses the route command where it should use zebra. These two modules should be splitted in several modules:

BGP module (with only bgprouter part)
Static_Routes module
Route_Map module
Route module : not configurable (use get, not get-config), to see the learned routes.
Interfaces_Module

(September 16th 2006) BGP module of YencaP Manager

I did the BGP module for yencap Manager side. It allows to define neighbors, route-maps and assignements between them.

(September 16th 2006) BGP module of YencaP

4Suite rc4 has been released on September 15th, 2006. They solved the XPointer bug and BGP module is working again !

(September 14th 2006) External releases coming soon

Fedora Core 6 general availability is scheduled on October 11th, 2006.
Python 2.5 final release is scheduled on September 19th, 2006 (next tuesday...)
4Suite rc3 has been released on August 28th, 2006.

(September 12th 2006) YencaP BGP problem

BGP module is still not working because of a bug in 4Suite1.0rc3 concerning XPointer. This bug is responsable for a segmentation fault error while parsing XML files. I reported the bug.

(September 11th 2006) YencaP copy-config fix

Small bug fix in copy-config and edit-config due to namespaces.

(September 10th 2006) YencaP operations and access control improvements

Operations are now loaded by the OperationFactory. Operation information are read from operations.xml by OperationReader. OperationReader now uses amara. OperationFactory now uses the same system as ModuleFactory. OperationManager is the central point for the Operation management.

Edit-config has been improved. The default operation is first set to the default value. Then, for each module, it checks that the operation attribute is present or not in the parent nodes because this changes the default operation (merge, replace, create, delete). This happens before calling the modules.

Access control for edit-config has been improved. It selected the authorized nodes in the received request (using XPath scopes). Then if an operation attribute is in the parent nodes then the operation is not allowed since the permissions are granted only on the subtree, not the parents.

(September 9th 2006) YencaP rpm

I built a Fedora Core 5. rpm for YencaP and YencaP Manager. They need more test so you should be careful and be aware of possible unwanted side effects.

In order to build the RPMs:

make targz

rpmdevtools package is required for the following steps:

su builder
cd
fedora-buildrpmtree
cp /tmp/yencap-2.1.2.tar.gz /home/builder/rpmbuild/SOURCES/
cp /tmp/yencap-manager-2.1.2.tar.gz /home/builder/rpmbuild/SOURCES/
cp /tmp/yencap.spec /home/builder/rpmbuild/SPECS
cp /tmp/yencap-manager.spec /home/builder/rpmbuild/SPECS
rpmbuild -ba rpmbuild/SPECS/yencap.spec
rpmbuild -ba rpmbuild/SPECS/yencap-manager.spec

(September 8th 2006) EnSuite cleaning

I cleaned a lot the code, in particular the unnecessary imports. I also removed the XMLSec support. The last version supporting XMLSec is 2.1.1. RBAC is still valid because it was independant of the transport protocol. Consequently, xmlsec1, xmlsec1-devel, xmlsec1-openssl, xmlsec1-openssl-devel and PyXMLSec packages are no longer required !

I also continued the migration to amara for the configuration files parsing. The configuration file syntax has changed also but does not require documentation since XML is self-described and verbose.

It would be nice to have an equivalent of XPath in the edit-config operation. XUpdate is an excellent candidate for that since it provides a XPath-based XML language for updating XML documents. The good news for EnSuite is that there are Python libraries that can create automatically an XUpdate document by making a diff between two XML documents. It means that when the manager updates the XML config, it can generate a diff document using XUpdate and send it to the agent. There is no efforts for generating the edit-config request. This should be implementable quickly in EnSuite.

(September 7th 2006) EnSuite modules management

The goal was to provide a dynamic deployement/undeployement and load/unload of YencaP modules. I defined a new Netconf operation manage-MIB-modules that allows to deploy the module code as a zip file, install it on the agent, and load it on-the-fly.

The idea is to have a OSGI-like Netconf agent on which it is possible to deploy modules and to load them (all this remotely and dynamically). The advantages are:

it is possible to update a module by replacing it with a new one,
it is possible to deploy new modules without shutting down the Netconf agent.

The moduleManager has been changed to allow load(Module module) and unload(Module module) methods. A new Operation has been coded. The following XML code is the new syntax for modules.

<module>
  <name>RIP</name>
  <xpath>/ycp:netconf/ycp:routing/rip:rip</xpath>
  <namespace pref="rip">urn:loria:madynes:ensuite:yencap:module:RIP:1.0</namespace>
  <cache-lifetime>1000000</cache-lifetime>
</module>

Another improvement was to split ModuleManager into:

ModuleManager which is responsible for (un)loading modules on demand. This is implemented as a Singleton,
ModuleFactory which is responsible for building modules on demand. This is implemented with both a Singleton and Factory design Pattern,
ModuleReader (formerly ModuleParser) which is responsible for parsing modules on demand (with amara). This is implemented as a Singleton design Pattern.

(August 28th 2006) YencaP Manager new features

Release 2.1.1 of YencaP Manager has a new interface. It allows to filter agents based on their IP, the function, their status and their capabilities. One of the nice thing is that you can navigate more easily even with many Netconf agents. Moreover, it is now possible to open (or close) a lot of Netconf sessions simultaneously. Also the web interface should be more stable now.

EnSuite - a Netconf Framework