App Copy but with optional placeholder volume copy

[tmart]

Many times (certainly not always) placeholder volumes represent log volumes for components within an app, etc. -- sometimes these are very large and in the context of an "app copy" (through GUI or CLI) add unnecessary time and I/O for the copy to happen.

Often it is sufficient to create new, freshly-baked filesystems and assign these to the placeholders.

It would be handy to support such cases if there could be a "--noappvols" or "--noplaceholder" flag that would do what "app copy" does now, but it would avoid copying application volumes / volumes assigned to placeholders.

[PeterNic]

Tim,

Thanks. I'll look at this -- we had a similar case where when you provision a new instance from a template, there may be blank volumes that need to get big but there is no need to copy the data; same for swap volumes. I am also guessing that you might want to do this selectively by volume rather than have it apply to all volumes.

In the meantime, you may consider using "app export ... --novols (http://doc.3tera.com/AppLogic24/CliApplication.html#AnchorExport)" and "app import ..."; the result should be the same as what you were looking for.

Best regards,
-- Peter

[tmart]

Thanks, Peter.

The "export --novols" might work -- but here's a question: does this switch only avoid exporting application volumes; or will it also avoid exporting instantiated volumes from branched classes?

...because we branch classes (at least our complicated classes that haven't been 100% instrumented yet) in order to avoid our volumes being rewiped when a "vol clean" happens -- for example during a grid version upgrade. We'd need those volumes as part of the export, but not the application-level vols. I assume from the switch name that this is what happens, but it would help if you could confirm this.

Thanks.

[PeterNic]

Tim,

export --novols will export no volumes whatsoever, just the ADL descriptors (including the application, all singleton descriptors, as well as the descriptors of any local catalog components).

It will not export any volumes, each type for a different reason (other than that the volumes may be in use):

application volumes are excluded by the definition of the --novols option
singleton's class volumes are treated as application volumes, so the switch will apply to them as well and they won't be exported
catalog appliance instance volumes are never exported because they come from the catalog (so the switch does not have any effect on them)


An aside on branched appliances -- Branching is used in two ways:

to temporarily make a catalog appliance class a singleton so you can modify it and create a new/upgraded class; when done with the changes, you put it back in the catalog and the singleton disappears
to keep an appliance in a "virtual server" mode, where the class-specific and instance-specific data is not separated or when you need to frequently and/or automatically modify the application code (e.g., if you have enabled the automatic updates). The appliance remains a singleton forever.


Keeping an appliance a singleton (branched) is one of the intended modes of using appliances. If an appliance will not benefit from being a catalog appliance or you can't cleanly separate the class-specific from the instance-specific data, then it should stay a singleton.

Best regards,
-- Peter

[tmart]

It would be a welcome addition to allow singleton class volumes to be exported, yet hold-back on application volumes. For example, an application having a custom Apache/Web instance not yet checked into the catalog having a large log volume. The log volume could easily be re-created on the target grid yet we would want the singleton class volume (eg. the boot vol for the branched class) copied. Similarly for a database data vol- we might have a 20GB data vol that is initially mostly empty with only static data that can be recreated with ETL processes, DDL scripts or DB-level export/import routines.

Of course we could check the singleton(s) into the catalog, export the catalog, export the app (sans volumes), recreate the placeholder vols on the target grid, etc. --- but sometimes we don't want to check things into the catalog just yet but still need to migrate/export the app (eg. a move to a new data center during the development phase of an application).

[PeterNic]

Tim, maybe we can simply add options to exclude certain volumes from export/migration?

I also think that transient data volumes -- like swap, logs, etc. -- may be actually marked as such and not transferred (or transferred only in certain cases, e.g., for snapshot but not for migration or provisioning of a new instance). This can help -- but for super-fine control, an option to exclude/include the volumes will probably work best.

Agree?

Regards,
-- Peter

[tmart]

Yes, that would be useful indeed.