Upgrading appliances

[mgorman]

There are lots of different ways I can build an app. I can just build it by installing software on Linux appliances and then copy the app as many times as I want to, or I can take time to try to create my own appliances, first, and then build it out of those appliances.

The reason I would want to create my own appliances is so that after I copy my app 30 times, I can upgrade my appliance once and restart the 30 copies so that they all automatically pick up the upgraded appliance.

For example, suppose I don't create an appliance, but just create an app out of Linux appliances, and install Oracle XE version 10.0.1.2.3. I then copy that app 30 times. Now, if I want to upgrade all 30 copies to Oracle XE 10.0.1.2.4, then I basically have to do that 30 times -- your basic IT challenge of upgrading 30 different servers.

On the other hand, if I first create an OracleXE appliance, and build the first app using that appliance, then when I copy it 30 times, when Oracle XE 10.0.1.2.4 comes out, I just go to that catalog appliance and upgrade the Oracle software there, and after I restart my 30 copies, each of them will come back up running the new version of Oracle. Right?

Well that's basically my question. Everything I've written above is my understanding of how AppLogic works and the rationale behind why I am behooved to create applications built on top of my own appliances, but my IT guy who has been diving into this indicates that when you make a copy of the app, it copies all the volumes, or something like that, and they won't get automatically upgraded when I upgrade the underlying OracleXE appliance.

Can someone confirm or deny how this would work, if I build my "baseline" app on top of my own OracleXE appliance, that even if I have copied that app 30 times, I can go back into that OracleXE appliance, and whatever upgrades I perform on the appliance will get propagated to my 30 copies on their next restart?

[PeterNic]

mgorman,

Your understanding is 100% correct. (Also, thanks for the good summary; I think it will be useful to all on the forum).

In fact, when you upgrade AppLogic to a new version, the same mechanism is used to bring the new version of catalog appliances to your apps.

Here is how it works:

When you create an appliance class and put it in the catalog, the class volumes belong to the class itself.

If you then create two apps with this appliance, AppLogic will instantiate a copy of the class volume for each app (you can see those volumes with 'vol list <appname> --all' -- you will see them as <appname>/volcache).

The copies of these volumes, however, are still linked to the class. If you change the class -- i.e., upgrade the Oracle on its volume -- AppLogic will pick up the change on the next app restart and will make complete new copies of the class volume for each app that uses the appliance class.

Voila, you have the new code in the two -- or all 30 -- apps.

Regards,
-- Peter

[Dmitry@Rivermine]

mgorman,

The copies of these volumes, however, are still linked to the class. If you change the class -- i.e., upgrade the Oracle on its volume -- AppLogic will pick up the change on the next app restart and will make complete new copies of the class volume for each app that uses the appliance class.
-- Peter

This is what I'm worried about. Does AppLogic automatically regenerate class volumes when they are updated? Does that mean that any data that's being put on those volumes throughout the operation of the appliance is lost? And does this mean that when we customize appliances we have to utilize placeholder volumes and setup application level volumes to retain our data?

Thank you,
Dmitry

[LeoKalev]

Again, your understanding is correct. Each instance of a class uses a copy of the class volume, and this copy will be replaced if the class volume is updated. In other words, the instances of class volumes are disposable and should be used only to hold code and non-essential data (logs, temporary files, etc.). Databases and any other permanent data should be in application volumes.
Rather than seeing this as a cause for worry or as a restriction, I view this requirement as a benefit - it enforces a practice of keeping the OS (and any add-on software, such as MySQL, HTTPD, etc.) separate from data, allowing you to:
- replace the entire OS without worrying about data loss (useful especially in emergency cases, e.g, corruption of system files, or a security breach)
- back up your data by copying an entire volume, without the overhead of copying the OS with the data.

I know that keeping data and (disposable) code on separate volumes can be a challenge sometimes, but is is usually worth the hassle, even if you are building your applications the old-fashioned way, without using AppLogic at all.

[Dmitry@Rivermine]

This actually makes perfect sense. I guess I was worried because I wasn't understanding the concepts.