when you need to branch

[jonesy]

Hi,

I just provisioned a LampCluster application, and hope to use it as the foundation/starting point for building my own app. What I noticed in glancing at the appliances, though, is that some of them are branched, and some are not. My understanding was that classes that were not branched would lose any customizations that were made to them, but I don't remember which events would cause that loss of customization, so maybe it's not an issue that my HLB is not branched? Or should I branch it now, even though I have no plans to make changes to it from its current state?

On the flip side of losing customization is losing the ability to take advantage of AppLogic upgrades to appliances. For example, presumably if I branch the HLB, it's now a separate class, and the instance in my app is an instance of my own class - not the stock catalog class. Doesn't that mean that I can't really upgrade the hlb without some manual intervention on my part?

brian.

[JosephD]

Brian,

When you branch a class you are separating it from the catalog, there are advantages and disadvantages to this. While it is still part of the catalog you benefit from the security of a catalog piece like the volumes not being writable, the catalog piece not taking up any additional volume resources, and the ease of replacing something you may have mis-configured in a drag and drop environment.

If you need to make changes to an appliance that go beyond what the standard boundaries provide (properties, terminals, volumes), or if you need to increase volume size on an appliance (adding a NAS appliance to you application MAY work around that need on a case by case basis.), or have plans to install new Linux software, are all good reasons to then branch the class.

In any of the cases above, when you have configured your appliance the way you want, You can then drag that appliance into your own catalog (don't forget to give it a new name) for future use in any application you make.

In the case of an HLB appliance You should not have to branch it at all... It has already been configured to work in the environment properly... But that does not mean you can't branch it, if you feel you need to go beyond what the standard properties offer... If that is what you end up doing I recommend a strong knowledge of Linux softwares and the installation and configuration of them.

Joseph
3tera

[PeterNic]

Brian,

Using catalog classes has numerous benefits (enumerated elsewhere, but I will probably post a summary somewhere). To get all these benefits, there is a bit more work involved -- for example, exposing parameters as properties, separating the user data from the boot volumes, optimizing the boot volume size by separating the big read-only piece of it, etc.

In LampCluster, the guiding principle was: anything that most people won't need to change (other than configure through resources/properties) was left as catalog classes -- gateways, load balancers; anything we expect most people to modify -- web servers, database server -- was branched and left as singletons. LampCluster was created as an entry point into AppLogic -- it mimics a physical rack with a cluster: where you might've had phyiscal appliances (gateways, load balancers, NAS boxes) we left our catalog classes; where you would have had a physical server (web servers, database servers) we put in singletons which you can manipulate as physical servers (hopefully, easier).

Some disadvantages compared to Lamp/LampX4:
- just as with physical servers, it is up to you to make sure that the 4 web servers have the same software, configuration and content (assuming that's what you want, considering the HLB in front of them).
- copying or migrating the application creates full copies of the volumes (rather than copying only the user data/content)

For some users and apps, this is OK; others move to Lamp/LampX4-type templates after a while; yet others skip the LampCluster step altogether because they need the catalog class capabilities to start with. There is no best way, there is no one way -- use what fits best; just know that more options and capabilities are available.

In a nutshell: if you don't intend to modify the HLB, don't branch it. (You can always branch it so why do it before you need to modify it.)

On the question of the events that trigger re-instantiation of the class volumes (which causes wiping of any changes made to instance volumes): in theory, any component and/or app restart. In practice, 'app clean', 'app copy' (target only), 'app migrate' (target only); as well as instance rename in the editor. In any case, if you want to modify a class, branch it first. Note that changes made to app volumes (placeholders from appliance's viewpoint) are never wiped. The ability to cleanly -- and in an enforceable way -- separate the user content from the appliance code is a key feature in AppLogic.

Regards,
-- Peter