Hi Adam, Wanted to just give you more detail on the issue I keep pressing on for your change (https://review.openstack.org/#/c/36731/).
For extensions which create their own "private" tables, I totally get it. I'd like, however, to understand what happens for a more complex extension. Let's imagine an (only-partially) hypothetical example of an extension that does (all of) the following: 1) It adds or changes the use of some columns in existing core tables, and has migrations and code that goes along with that. 2) It adds a new "private" table, and has all the code to handle that 3) New APIs etc. to create new REST calls to drive the extension It is part 1) in the above that I am trying to understand how we would implement in this new model. What I am imagining is that the best way to do 1) is that you would break (at least part of it) out of the extension and it would be a core patch. This would cover modifications to core columns and changing any core code to make sure that such changes were benign to the rest of core (and indeed any other extensions). Migrations for this part of the schema change would be in the core repo. Our new extension would then build on this, have its private new table in its own repo and any unique code in contrib. Is that how you imagined this working? This hypothetical example is, of course, not too far from reality - the recent change I did for inherited roles (https://review.openstack.org/#/c/35986/) is an example that comes close to the above - and it would seem to me that it would be much safer (from a code dependency point of view) to have the DB changes done separately and integrated into core - and the extensions just, in this case, use the advantages of the new schema to provide its functionality. Henry _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
