Open Stack

On 07/31/2013 06:00 AM, Henry Nash wrote:
> 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?

I think so. I think that if extensions modify core tables it becomes
hard to use more than one of them, and it's also a brittle interface for
the extension author. If there is a capability, as you mention, that the
core tables/objects need, that should totally be landed in core. If core
won't land it, then those pieces of info should just go in a second
table. There's actually no information that you can't stick in a second
table in sql...

> 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 OpenStack-dev at lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>