Software Versioning

Over the last few months, I have been co-handling the release procedure for our builds. This task primarily stemmed from the fact, that I was involved with the design of the *build* infrastructure for our product(s). I realised an interesting thing about versioning a software, which is said to be closely tied with "Software Engineering" (SE) principles, a publicly despised subject in our graduation curriculum.

(What I mean by versioning a software is, regarding the x.y.z string that you normally see in a software package you use, following the name of the software, e.g. Firefox 2.0.0.4, and how do you decide when to change one of these digits.)

One does not need much of SE knowledge, in order to come up with a versioning scheme. This can be dictated solely by common-sense. In layman terms, what I mean is, that SE principles will tell you what processes to follow when you release a software build, but they do not tell you which of those digits to change, and by how much. An example versioning scheme:

I number all my releases in the x.y.z format. My first release is 1.0.0. Now, all my immediate minor bug fixes, like typos, formatting changes, etc. will go into version 1.0.1. Following minor bug fixes will go into version 1.0.2, and so on. This essentially means that there will be no functionality changes in any of the 1.0.x versions of my software.
A slightly more critical change will go into version 1.1.0. This may include changes like support for a new browser, changes in the GUI layout, etc. Once again, minor bug fixes will keep going into versions 1.1.x. So, the functionality in 1.0.x and 1.1.x still does not vary, but still I can say that my 1.1.x release works better than my 1.0.x release.
Now, when I do a major feature addition (/removal) in my software, I will change my version to 2.0.0. These changes may be on the lines of addition of new capabilities, support for a new OS, a new platform, a rehaul in the design of the software, etc. And the changes in the smaller numbers mentioned above continue for version 2.0.0.

Now, this mechanism of changing these numbers can change based on many factors. The foremost criteria that I came across, is the kind of upgrade procedure that you follow and support (as will be agreed by Sujay), and vice-versa. Continuing with the example:

In this scheme, it is obvious that a customer should be allowed to upgrade to any of the versions where the last digit changes, i.e. from 1.0.3 to 1.0.4 or 1.0.5.
Also, since 1.1.0 does not have any functionality modifications, she should be allowed to upgrade even if the second digit changes, i.e. from 1.0.x to 1.1.x.
However, since versions 2.0.x involve a major change in the way things work, upgrading can prove to be a headache, and may even result in data loss, all the more so if the upgrading mechanism itself undergoes a change.

Now, if your upgrading mechanism does not follow these rules, then your versioning system is reduced to only a series of numbers to distinguish between different builds. And if you want you upgrading system to be able to jump from any release to any higher release, then again your versioning system should be designed to allow that.

Other factors that may come into play when you design a versioning system for your software may be:

• the source code repository being used,
• the number of products which come under the same versioning system,
• the number of configuration options for a single release, etc.

Some of the common versioning mechanisms currently in use are:

• Date - e.g. Wine 20040505 (released on 05/05/2004)
• Year - e.g. Windows 98, Windows 2000, MS Office 2003
  
• Alphanumeric - e.g. Windows XP, Windows ME
• Even number releases - e.g. kernel 2.4, kernel 2.6 (kernel 2.3, kernel 2.5 are for development)
• Floating point - e.g. Perl 5.8.7 is actually Perl 5.008007
  

Mirroring

Lets share our knowledge on this one...

Currently I am trying to implement the mirroring. When I thought of implementing it, one thing just came across my mind, which one to implement 1) Volume mirroring 2) Disk mirroring - which are essentially the two types of implantation.

I started with Volume mirroring (with the help of Mayur).
Here are some points which one should keep in mind while implementing the same
(from Windows point of view...considering DDK kit)

Assumption
Source and target Volumes should be consistent

Ways to proceed
FIRSTLY do full format on source and target volumes
ELSE you need to write syncing code

Handling WRITE request
EITHER create a new IRP and redirect it to target volume (but this will require a sound knowledge on drivers)
OR just manually write the data on target volume using the information available in IRP (meta-data)

2nd inning
Now if you are thinking of handling write request manually then people will suggest that to let you original WRITE requests to complete, in mean time log the necessary information on scratch-pad (NOTE: scratch-pad info should be complete enough so that later on you can create your READ request for the same data-buffer using your info) Generate a READ request and write the retrieve data on the target volume. This will not hamper any performance as you are not wasting much time in WRITE request (you just log necessary information on scratch-pad thats all) and much important is, if write fails you can just remove the scratch-pad entry in contrast to other approach where default WRITE request may fail and then you are in trouble :-)your another WRITE request to target volume may have completed successfully.

Now your target volume is replica :-) So try to implement the things....in case of doubts post your opinion...

QoS for servers

guys now this is something to which you must reply & discuss..

currently i am analysing what can be QoS(quality of service) requirements of a server. Server can be web or database or anything.. Basically QoS helps in differentiating the kind of services offered to different clients.

pls comment on this, I am trying to list out some quantifiable requirements which clients ask for or essential ones... (sometimes some of these terms sounds boring, but delivering such things with the software is most critical & beneficial work...)

The major requirements for supporting QoS in software server are as follows:

• Performance:
• Throughput – min, peak, allowed burst, reward function for achieving throughput between [min, peak], penalty function for throughput < min
  
• Response time / latency – distribution or percentile.
• Availability: Probability that a service is available.
• Duration for which service should be available.
• Time-to-repair (TTR).
• Accessibility: Probability measure denoting the success rate or chance of a successful service instantiation at a point in time. Requires scalable system.
• Integrity / Transactional QoS
• Reliability: Capable of maintaining the service and service quality. The number of failures per month/year represents a measure of reliability.
• Security: Providing confidentiality and non-repudiation by authenticating the parties involved, encrypting messages, and providing access control.
  

Omkar

Hello folks,
I am Omkar Gosavi.

I am from Pune. I have completed my Engineering in Information Technology, from Vishwakarma Institute Of Technology, Pune.

I started my professional career with Concepts Systems Pvt. Ltd. based in Pune. I worked there on a Java project ( Antivirus patch Auto-update) and did some work on the concepts web-site. Then after few months, I joined InMage Systems Pvt. Ltd in Hyderabad. Now it has been more than an year with them. InMage works on a data-recovery product using Continuous Data Protection(details for which can be found on the website).

During this 1 year I have been working on the dataprotection part of the product which involved coding in C and C++.

I am really pleased with the idea of this "K" bar for discussions. Looking forward for such wonderful discussions.

Thats all folks.

Thanks,
Om

Welcome to Virtual World (Server Virtualization)

lets start with some technical stuff....

sometime back I started working on one of the popular Virtual Machine Monitor(VMM) / hypervisor called xen. Basically there are various kinds of Virtualization like 1) Virtual Memory 2) Linux IP virtual Server 3) Application Virtualization 4) Server / Software Virtualization out of which xen does the last i.e. Server Virtualization.

Let’s see some of the basic terms in Server Virtualization.
Virtual Machine (VM) – This is an artificial environment created which simulates all the hardware resources needed by an operating system. The OS running in such environment is called as guest OS. Guest OS has a virtual view of the underlying hardware.
Virtual Machine Monitor (VMM) / hypervisor – This is the interface between the guest OS and
underlying hardware. Through VMM all the administrative tasks like adding a new guest OS,
allocation of resources to each of guest OS is done. Some examples of VMM are – Vmware, Xen
Host OS – The native OS running on the given hardware is called as Host OS. The VMM is
installed on Host OS. This OS has all the privileges on given hardware. We can have VMM running directly on hardware without any host OS which is called as Bare Metal Environment.

In simpler terms, the actual physical resources are divided into logical partitions. Each of the
logical partition is allocated to some guest OS. Each guest OS runs independently on given
partition. For Host OS, guest OSes are like the normal processes running on it. But with a major
difference that every guest OS has resource guarantees. This is the similar case as that of real
time systems where resource guarantees are associated with the processes.

Capabilities of Virtual Machines

• Workload Isolation or Workload Consolidation
  
• Workload Migration
• OS debugging
• Running Legacy Applications

Types of Virtualization
These types are based on the nature of guest OS.
Para-Virtualization: In this scenario, Guest OS requires some modification to run in
Virtual Machine environment. Reason behind this is that the OS are made with
assumption that they are having all privileges on the hardware. But in case of Virtual Machines, guest OS doesn’t have rights to run all the privileged instructions on the given
hardware. So to resolve this case, there are two alternatives. One is to have support from
processor, otherwise change the privileged part of code(which possible in open source OS only). Guest OS runs in ring 1 of x86 family processors which do not support virtualization.
Full Virtualization: In this type, unmodified OS can run in Virtual Machine. This is
actually achieved by any of the following two ways. One way is Hardware (processor) support for Virtualization. X86 family started give support from Intel-VT & AMD-V which released in 2005 and 2006 respectively. Other way is Binary Translation the one adopted in VMware. Vmware tries to track the all the instructions issued by guest OS & whenever a privileged instruction comes in, VMware translates it. But some people argue that this is a costlier solution.

this was just overview of world of Virtual Machines (hereafter we'll use this term. don't confuse it with Java Virtual Machines)

Any queries and/or suggestions & clarifications about any mistake I done while writing are most welcomed ( rather I will say reply is MUST :) )

Blog Bar......

As per Sayesha's terminology, let's call this place as "K" bar, where some nice foods for thought along with rich old drinks will be served. So here everybody can contribute to make our customers fully satisfied by keeping them always "talli".......

So stay tunned....... :)