Code review comment for lp://qastaging/~vladimir.p/nova/admin-vm

I suppose there are 3 general aspects for categories:
- APIs for setting categories per instance (and everything related to APIs)
- having a separate table where different category-wise settings might be stored
- distinguishing if instance belongs to category or not (where to store this field)

Having a separate table for categories helps to organize things, support different types (categories) of instances and establish better relations between tables. Potentially, we could link categories table to instance_types and set up special configurations/flavors that are applied to particular type of admin instances. In this approach such table has a metadata field, but it may have sense to put it outside in separate table a-la instance_metadata.

It is definitely possible to store this category field in the instance_metadata table as a key/value pair and we were thinking about it at the beginning. But it complicates SQL queries and you can't build normal SQL relations between key/value & categories table.
It will require first to retrieve a value and only after that to perform an additional query to retrieve properties of this category ...
Another use-case - filtering of non-regular instances. Now for each DescribeInstances call we will need to look at meta-data key/value pairs and find out if it should be hidden or not.

But I guess the main question about categories - if we think that it might be one of basic instance parameters that will benefit every installation/customer. Because in general, the instance_metadata table could hold almost all fields from instances table and it will be enough to have only instance_id field there :-)