0

This is my first question so please indicate if my question is too vague and not understandable. My question is more related to High Level Design. We have a system (specifically an ATCA Chassis) configured in a Star Topology, having Master Node (MN) and other sub-ordinate nodes(SN). All nodes are connected via Ethernet and shall run on Linux OS with other proprietary applications.

I have to build a recovery Framework Design so that any software entity, whether its Linux, Ramdisk or application can be rollback to previous good versions if something bad happens.

Thus I think of maintaining a State Version Matrix over MN, where each State(1,2....n) represents Good Kernel, Ramdisk and application versions for each SN. It may happen that one SN version can dependent on other SN's version. Please see following diagram:- enter image description here

So I am in dilemma whether to use Package Management Methodology used by Debian Distributions (Like Ubuntu) or GIT repository methodology; in order to do a Rollback to previous good versions on either one SN or on all the dependent SNs. The method should also be easier for upgrading SNs along with MNs.

Some of the features which I am trying to achieve:-

1) Upgrade of even single software entity is achievable without hindering others.

2) Dependency checks must be done before applying rollback or upgrade on each of the SN

3) User Prompt should be given in case dependency fails.If User still go for rollback, all the SNs should get notification to rollback there own releases (if required).

4) The binaries should be distributed on SNs accordingly so that recovery process is faster; rather fetching every time from MN.

5) Release Patches from developer for bug fixes, feature enhancement can be applied on running system.

6) Each version can be easily tracked and distinguishable.

Thanks

Improve this question
2
  • I think your question is unclear for two reasons. First of all, I do not understand difference between proposed alternatives. Indeed, Google does not return a single hit for exact "Debian Version Management Methodology" query, and I don't want to guess what you mean by it. More importantly though, you ask which solution to your problem is best but do not provide any criteria beyond "it should be easy to upgrade too".
    – mkalkov
    Commented May 6, 2014 at 6:03
  • @mkalkov Thanks for comment it out.In case of systems where several nodes have different versions and configurations and dependencies among them, doing a rollback to previous version or performing upgrade on a single node is cumbersome. So, initially I thought of maintaining GIT repository of all images and one GIT repository for compatibility matrix which can be refer while applying rollback.I am a regular GIT user, so i am a little bias towards it.Ubuntu achieve same by using "apt" tool for maintaining all the software versions, performing upgrades,rollback.I will edit my question.
    – actiononmail
    Commented May 6, 2014 at 6:15

1 Answer 1

Reset to default
1

Imo, you want Puppet or a similar configuration management tool to satisfy req 1, 3 and 5. You can even manage puppet config in a git repo to satisfy req 6. It also sounds to me that using Debian packages would be better than git repos in your case for the following reasons:

  • dependency checks are integrated into dpkg (req 2)
  • apt-get caches binaries locally (req 4)

Of course, all of these can be reimplemented without reusing a configuration management tool and a package manager, but this sounds like more work. Finally, remember that no configuration tool is ideal, and the following issues may still arise:

  • an upgrade of some software entity breaks the configuration tool itself
  • a new version of software entity changes configuration in a backwards-incompatible way, e.g. by updating a database scheme and a rollback becomes problematic
  • common package managers such as APT may produce surprising behaviour (example)

Hence, it is still important to define your changes properly (scope, time window etc.) and roll them out in stages.

Improve this answer
1
  • Puppet seems to be interesting but considering by delivery timeline (1 month) and understanding of Ruby, I will look into some more Configuration Tools (en.wikipedia.org/wiki/…) and will update in the Question ASAP.
    – actiononmail
    Commented May 6, 2014 at 10:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.