Question on Common Volumes

[digerata]

We have some custom appliances (of course) and just ran into our first problem with updating an appliance with a common and shared /usr volume.

After I branched an existing appliance in the catalog, updated some files, and attempted to add it back to the catalog (as the same name), I get the error that it can't be done because the /usr volume is in use.

I assume that this is because there are 8 running applications all using this appliance, all off the same /usr volume.

I have two questions:

- What is the difference between Common and Shared? It seems they are synonymous from the documentation. If I mark the /usr volume as common but not shared, AppLogic won't let me add the appliance to the catalog. (Even though the documentation says that shared is not required for common volumes.) Why the distinction here between common and shared?

- If I create an appliance that I might to need to modify in the future, I must change all common/shared volumes to instantiable? If I want to keep the common volume, I have to create a new version of the appliance?

(well, a few more than 2 questions...)

Thanks!

-Mike

[PeterNic]

Mike,


What is the difference between Common and Shared? It seems they are synonymous from the documentation. If I mark the /usr volume as common but not shared, AppLogic won't let me add the appliance to the catalog. (Even though the documentation says that shared is not required for common volumes.) Why the distinction here between common and shared?


The shared (and read-only) attributes apply to all types of volumes, including placeholder (aka application or user volumes). The common attribute applies only to class volumes. All common volumes should be shared and read-only when the appliance goes to the catalog; while the appliance is branched (singleton), the common volumes may or may not be read-only -- read below why; also singleton's volumes are never really shared, so the shared attribute is moot for class volumes of a singleton and matters only when you're about to move the appliance to the catalog.

[The documentation I found says that common implies shared -- is that what you saw in the docs but it is not working?] I guess we will end up moving the shared/read-only attributes to be valid only for placeholder volumes and leaving instantiable/common to be valid only for class volumes.]

Further references (the ADL spec describes how it really works; the GUI is a bit simplified to eliminate some of the invalid combinations):

http://doc.3tera.com/AppLogic24/AdvADLSpec.html
http://doc.3tera.com/AppLogic24/RefEditorClassEditorSimple.html



If I create an appliance that I might to need to modify in the future, I must change all common/shared volumes to instantiable?

When you branch the appliance, the distinction between common and instantiable is moot, since both types of volumes belong to the single instance of the appliance (branched appliances are also known as singletons). The distinction is kept, however, so that if/when you decide to put it in the catalog, you don't have to mark them up again.

You don't have to change common to instantiable in order to modify it; however, you have to turn off the read-only attribute if you intend to change what's on the common volume. The reason we left the control of the read-only attribute for singleton's common volumes is that you need both modes: you need it read-write in order to modify it (e.g., to install the next version of the application software on it), and then you need it read-only in order to be able to test the appliance in the same configuration it will have in the catalog (where the common volume must be read-only).

So, when you are modifying a catalog class, the stepts are:

branch the class
mark the common volume(s) as not read-only
start and modify the appliance as you want to
stop and mark common volume(s) as read-only again
test the appliance (final test)
move it into a catalog



If I want to keep the common volume, I have to create a new version of the appliance?


If you want to create a new version of a catalog appliance with common volumes that is in use, you will either need to stop all applications that use the old appliance before you can put the new one in the catalog (since otherwise we cannot overwrite the common volume of the old appliance), or simply to put the new appliance into the catalog with a different name (e.g., ver2).

[As we add more support for explicit appliance versions, you will be able to add a new version without stopping the instances of the old and without renaming. Keep in mind that you can do appliance class change with shift-drag and with ADL edit (including scripted).]


(well, a few more than 2 questions...)

Forum's weekend special -- 3 for the price of 2 :)

Best regards,
-- Peter