DegradationMeister

After some hours of spending into a rudimentary degradation concept, I release the DegradationMeister in version 1.0.

The documentation is available at:

Degradation Concept.pdf@GitHub

This idea is to create a library, which supervises the monitor and automatically calculates the capability of the software dependent on a fixed set of rules.

Function – A function is a well-structured element within a system that has an input/output interface.

Capability – Defines the state describing whether the function is capable to fulfill the task as defined. A function can have several capabilities

Failure – A failure will lead to a state that will lead to a deviation of the intended function in regards to the actual function. There a detectable and non-detectable failures

Failure Cause – A physical event within a physical system or part that leads to a failure.

Monitor – A monitor has the task to detect a failure and report the result of the failure evaluation.

Degrader – The instance that is capable to connect the failures to capabilities and to connect capabilities to other capabilities.

image

{
    var degrader = new Degrader(„All“);
    var monitorPowerSupply = new PowerSupplyMonitor(degrader);
    _capabilityPowerSupply = new Capability(degrader, „Power Supply“);
   
    var monitorActuator = new ActuatorMonitor(degrader);
    _capabilityActuator = new Capability(degrader, „Actuator“);
   
    _capabilitySystem = new Capability(degrader, „System“);

    degrader.AddDefaultRules(monitorPowerSupply.TotalFailure, _capabilityPowerSupply);
    degrader.AddDefaultRules(monitorActuator.TotalFailure, _capabilityActuator);
    degrader.AddDefaultRules(_capabilityPowerSupply, _capabilityActuator);
    degrader.AddDefaultRules(_capabilityActuator, _capabilitySystem);
}

Move to Autofac

I left Ninject… Poor guy… Ninject was my favorite dependency container injector, but there is a new hype. The new hype is called ‘Autofac’.

The main reason for the switch was the support of UWP (Universal Windows Platform) and .Net Core. Ninject is still in Beta while Autofac is used also by Microsoft themselves.

So, time to do a switch. The following caveats were found:

1)

image

Instead of doing a bind to something, you register something as an interface/method.

2)

By default, Autofac does not support the creation of an unregistered, concrete class like Ninject does.

Here, you need to add the following line:

image

I need the creation of unregistered class, because the DatenMeister uses a plugin-like architecture where the plugins are created by the dependency injection.

In a future version, this class will be replaced by a more specific registration

3)

Autofac differs between the builder, the container and the lifetime scope. In Ninject, this was more or less voluntary. This leads to some architectural changes, since some of the methods used the global builder which is not available after everything has been built. Not nice, but acceptable.

http://docs.autofac.org/en/latest/resolve/index.html

image

After having built the container, the builder cannot be changed anymore. A new builder has to be created. This also leads to some architectural changes.

 

In the end… a lot of refactoring without improving the product…

Invoking MsBuild from Powershell

Unfortunately the command ‘msbuild’ is not in the default command line path. This means, that you cannot invoke ‘msbuild’ by just calling ‘msbuild’. You need to find the directory of the .Net-Tools via the registry and use an absolute path.

You could also call your script from the Developer Command Line, but my feeling is that this command line never works as intended.

Another solution is to use a script which does all the look for you:

https://invokemsbuild.codeplex.com

Invoke-MsBuild does all the dirty work for you.

One example about its usage can be found in my Nuget-Package-Packer packaging NuGet-Package for the NuGet-Package-Repository.

https://github.com/mbrenn/datenmeister-new/blob/master/nuget-packages/pack.ps1

It just works (minor improvements ongoing).

DatenMeister.dll auf Nuget

After a long time of doing nothing, I finally published the DatenMeister.dll in Nuget.

This C# library contains a small interface of the MOF specification as defined by the OMG object group.

image

It also include a very simple in-memory interface, which is capable to work on the MOF-instances.

In combination with other libraries, it is planned to create a library, which shows somehow a conformance to the MOF and UML specifications.

Of course, the complete library is available within GitHub. (https://github.com/mbrenn/datenmeister-new/tree/master/src/DatenMeister).

The server

Server was ordered and is assembled and running fine:

image

Due to space constraints, I decided to try out a barebone, where memory, power supply and housing is already included.

IMG_6149

The following components are included,. Since I’m totally non-aware of the current hardware specifications and technology, there was more wikipedia involved than real knowledge. Hard to keep up… also in hardware.

image

So, in total: a Skylake4 GB RAM, 12 TB HDD, 256 GB SSD for the operating system and a small CPU. Should be sufficient as a storage device.

Surprisingly, the assembly of CPUs, HDDs, SDDs (m.2) just lasted about 15 minutes. I expected at least one or two hours. The only guessing I had was the direction of the m.2 interface. It looks symmetric, there is not cut-in and there is no symbol about the upward side… I browsed through the internet and it was called ‘double-sided M.2’. I just tried out side with the logo upwards and hoped… It worked.

It is intended to run the HDDs as a 6 TB mirrored RAID-1 which allows the loss of one of the HDDs without losing any data.

The OS

image

I did not want to waste 90 EUR for a Windows licence and I wanted to improve my Linux knowledge, so the decision was very clear for me:

The OS will be a Gentoo Linux and probably one or two Ubuntu instances with kvm or another virtualization technology. Why Gentoo? Because I always used Gentoo. There is really no reasoning except having the feeling of total control…

The OS itself was installed after 1 hour. Another half an hour was needed to find out that the intel driver “e1000e” instead of “e1000” is necessary for the latest mainboard revisions. Minor issue, a little bit annoying.