Editing Custom Classes Added to the Catalog

[kapow]

My application infrastructure consists of 3 branched classes. I want to add these custom appliances to the catalog to be able to instantiate additional appliances for scalability and, more importantly, to be able to edit the catalog classes so that all instances of my application can be upgraded easily with a restart instead of editing each app instance.

I understand how to add my custom appliances to the catalog. What I don't quite understand is how do I update those catalog classes? Let's say I wanted to upgrade a version of our companies software on a catalog class. How do I run the appliance and perform the upgrade so that all applications using that class get upgraded?

[PeterNic]

Kapow,

Here are the steps; they can be modified slightly to fit your operations procedures:

1. Make a copy of your application; you will use the copy to make the changes in and test them prior to getting the new appliance over to all other apps.

2. Branch the appliance you want to modify.

3. Start the application; login to the appliance you want to modify and modify it. (How an appliance is modified, how you bring in your new codebase in several ways, is a separate topic, described elsewhere.)

4. Test the operation of the application with the modified appliance.

5. Stop the application

6. Rename the modified class to the new name (e.g., MYAPPv2); move the appliance to the catalog. (If your appliance had a common volume, make sure it is switched back to read-only/shared prior to moving it into the catalog).

7. Start the application and test again; this ensures that the modified appliance works OK as a catalog class.

8. For any application you want to start using the new appliance version:
- open in editor
- shift-drag the new appliance from the catalog and drop over the instance you want to replace (note: the Shift key must stay down until after you "drop" the new appliance -- release the mouse button first, then release the shift key)
- save the app and restart it

The approach above is the safest -- it allows you to move all application instances one by one to the new class. It is not the most efficient.

Here is a modified procedure starting after step 5 above (that doesn't work in all cases -- see post Apr 16, 2009 (http://forum.3tera.com/showthread.php?p=6951#poststop)):

6. Stop all apps that were using the old class

7. Rename the old class to some other name (e.g., MYAPPold)

8. Move the newly modified appliance into the catalog

9. Restart the apps -- they will all automatically pick up all the new version of the class.

If you need to rollback:
- if you want to rollback in all applications: stop apps, rename the new class; rename back the old class; restart the apps, OR
- if you want to rollback only in one application: stop the app, open it in the editor, drag the old class over the target instance(s); save and restart

One feature we are going to be working on is to avoid the all-stop in step 6 of the second approach, and be able to sequentially restart all the apps.

EDIT: Also, note that you can do the same changes by editing the ADL descriptors -- either interactively or programmatically; see post dated April 16, 2009 (http://forum.3tera.com/showthread.php?p=6951#poststop).

Let me know if this helps.

Regards,
-- Peter

[kapow]

Got it. I will experiment with these procedures. Thanks!

[GDR!]

I tried both methods mentioned above and both fail.

When I try to rename existing class to class_old, the following error appears:
http://amber.leeware.com/wi/tmp/class-update-1.png

Whenever I try to drop a new class onto existing instance, the following happens:
http://amber.leeware.com/wi/tmp/class-update-2.png

Do you have some tips for me?

[PeterNic]

GDR!,

I tried both methods mentioned above and both fail.

When I try to rename existing class to class_old, the following error appears:
http://amber.leeware.com/wi/tmp/class-update-1.png


This was my fault - the "modified" procedure above does not work -- you cannot rename the class of an appliance that has instances. I am not sure but a workaround may be to do that from an empty app - I am not sure how extensive the check is -- but in all cases, the check will fail if any instances of the class are running in any app. In one word, probably not the best method to use; see below.


Whenever I try to drop a new class onto existing instance, the following happens:
http://amber.leeware.com/wi/tmp/class-update-2.png


I have corrected the text in the original description -- if you want to change the appliance class, use Shift-Drag (not just drag). See http://doc.3tera.com/AppLogic24/RefEditor.html#Subordinate_Instances for details and constraints.

I also see on the second snapshot that the editor picture is messed up a bit - I have seen this effect after some time keeping the app open, especially with the latest Firefox 3.0.8. Closing and reopening the editor fixes this -- we will look to see if it is a new FF 3.0.8-specific effect and if we can fix it.

As an alternative to the the shift-drag, there's also a new method available in AppLogic 2.4.7+ -- editing the ADL descriptor directly. To do that, open the app in the editor and select menu "Application | ADL Main Descriptor". Find the entry for the appliance(s) you want to change; in your case, it will look like this:
subordinate srv2 : .class = user.LIGHTTPD
(meaning appliance instance "srv2" of class "LIGHTTPD" from catalog "user")

Replace the class name with the new class name, e.g., user.LIGHTTPD11.

While not as visual, it is probably easier to do, especially if you are replacing the class of multiple appliances in the same app. For more details on ADL, see the ADL spec (http://doc.3tera.com/AppLogic24/AdvADLSpec.html). (Some of our customers have this operation scripted using the get_desc and put_desc commands.)

Best regards, sorry for the misdirection and let me know if any of the approaches above worked out for you.

-- Peter