vol resize problems, and default vol sizes

[jonesy]

I read the output of 'help vol resize', and according to that output, what I want to do is this:

volume resize my-app:MYSQL.boot size=1G - resize application singleton class volume

Here's my session output:

> vol resize addthis:NAS.boot size=2G
The volume 'addthis:NAS.boot' does not exist.

> vol resize NAS.boot size=2G
The volume 'addthis:NAS.boot' does not exist.

> vol resize main.NAS.boot size=2G
format of the volume name is invalid.

> vol resize addthis:main.NAS.boot size=2G
format of the volume name is invalid.

So... is this a bug in the docs, in the command, or am I missing something? How do I resize the boot volume of this appliance? I've confirmed that it does, indeed, exist.

By the way, what sysadmin in their right mind only leaves 7.4MB available in their /usr partition upon initial install, especially considering that resizing it will mean downtime for the *entire app*? I'm going to have to increase the size of *EVERY* boot volume, because I need to install *one* package (with dependencies), and I can't do that with the current default config.

[jonesy]

I noticed that the scope for the volume in 'vol list' was 'addthis/volcache', so here's more failed attempts:

> vol resize addthis/volcache:NAS.boot size=2G
Volume must specify an application user or singleton class volume.

> vol resize addthis/volcache:main.NAS.boot size=2G
Volume must specify an application user or singleton class volume.

I have no earthly clue what that error means, as there's nothing in the 'vol help list' output about an application user, and I thought I *was* specifying a singleton class volume.

[Chris]

I read the output of 'help vol resize', and according to that output, what I want to do is this:

volume resize my-app:MYSQL.boot size=1G - resize application singleton class volume

Here's my session output:

> vol resize addthis:NAS.boot size=2G
The volume 'addthis:NAS.boot' does not exist.

> vol resize NAS.boot size=2G
The volume 'addthis:NAS.boot' does not exist.

> vol resize main.NAS.boot size=2G
format of the volume name is invalid.

> vol resize addthis:main.NAS.boot size=2G
format of the volume name is invalid.

So... is this a bug in the docs, in the command, or am I missing something? How do I resize the boot volume of this appliance? I've confirmed that it does, indeed, exist.

By the way, what sysadmin in their right mind only leaves 7.4MB available in their /usr partition upon initial install, especially considering that resizing it will mean downtime for the *entire app*? I'm going to have to increase the size of *EVERY* boot volume, because I need to install *one* package (with dependencies), and I can't do that with the current default config.


What application are you working with?

Do the following and paste the results, "vol list appname --all"

[Chris]

Also, once you have the first NAS setup the way you want it just copy it over to the catalog and use this instead of the default nas appliance and you won't have to go resize the boot volume each time.

[PeterNic]

Volume must specify an application user or singleton class volume.

I have no earthly clue what that error means, as there's nothing in the 'vol help list' output about an application user, and I thought I *was* specifying a singleton class volume.

Brian, a class cannot be modified while it is in the catalog -- a number of reasons for this, fragility being the most important.

If you want to change a catalog appliance in any way, branch it (when it becomes a singleton); then you will be able to resize its volume and do pretty much anything you want with it. Once you are happy with the way it works, you can move it into a catalog and use as many instances as you want. Typically, you move it in the 'user' catalog (as opposed to the 'system' catalog) or to the 'proto' catalog; you can also create your own catalog.

If you have an existing application that already uses the appliance from the system catalog (e.g., system.NAS, as shown in appliance instance attributes), you can replace it with your new appliance (IIRC, a shift drag of the new appliance from the catalog and drop over the old appliance will change the class).

Does this help?

Regards,
-- Peter

[acw]

I have same issue with resizing now too... what if the existing appliance (that came from a class) already has some modifications to config files etc that is specific to that appliance? Wouldn't be able to replace it with a class.

[PeterNic]

Albert,

I am not sure I understand the problem... If you have a catalog class appliance, then all changes that are made to config files are done by the appliance itself during startup, right? All persistent data is stored only on placeholder/user volumes, never on the class volumes.

(I know you have migrated applications so unless they were all VPS/singletons, this is something I am sure you are familiar with.)

Have you looked at the Application Model (http://doc.3tera.com/AppLogic23/AdvApplicationModel.html) document?

Regards,
- Peter

[acw]

Hi Peter,

I have 2 appliances where the boot vol are extremely low on space, almost out. The guy who made the appliance is out on vacation for two weeks, and I wasn't sure if there were config changes or not. So, tried to expand the vol on both the cataloged appliance and also the app appliances, which didn't work out. I'm hoping no unique configs in class vol, but I don't know for sure till he comes back to work.

[PeterNic]

Hi Albert,

I would recommend first taking a look whether there are any old log files that could be deleted -- /var/log/messages.*, /var/log/wtmp.

If not, then you can branch the appliances and resize the volumes. When your developer comes back, he can decide whether it is OK to move back to the catalog.

Regards,
-- Peter

[acw]

Hi Peter - yes, we've been clearing out logs and put in some log rotate scripts. Will branch as you suggested. Thanks.