Comment 5 for bug 1729933

Entities that have supported setting extras we have maintained support for the setting of extras. In the case of Regions, it may have just inherited the bad base-sql object and we never actually set them.

There is a hard "no further extras support" within Keystone. Extras are ugly, can add serious load to the DB and mostly were used for data that belonged in CRMS (e.g. Salesforce) and not in Keystone (some exceptions to this happened, but it was infrequent).

If Region ever supported setting of extras, we need to add support back in. If it didn't we will not add the support for it (all new constructs do not support it, and do not have an extras column).

tl;dr - we would remove extras across all of Keystone if it wouldn't break the API contract. Keystone should not just be a bad key-value store, all entities should have clear defined validation.

--
As an aside, I have proposed adding in an operator/deployment specific area (e.g. User['vendordata'] that may be used like extras; in the way extras was implemented previously any attribute (or structure) not in the model (top level, e.g. User['mycooldData']) would be serialized and shoved into the DB in the extras column. This made it had to add any fields as we may stomp on what folks used. We also continually were asked for ways to search/support indexing on the "whatever we shoved into extras". Extras was/is very sloppy (unfortunately).