Open Stack

On 08/01/2013 11:40 AM, Dolph Mathews wrote:
>
> On Wed, Jul 31, 2013 at 5:00 AM, Henry Nash <henryn at linux.vnet.ibm.com 
> <mailto:henryn at linux.vnet.ibm.com>> 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
>
>
> I see the need for quotations here as a big red flag: what exactly is 
> the use case we're solving for? The quotes imply to me that we're 
> simply moving code around within the git repo as a refactor with no 
> real gain.

The code in question was a table that linked endpoints to projects. This 
won't flay, as both endpoints nad projects are in separate backends.  
Theoretically, both could come from a backing store other than SQL.  The 
solution to this particular problem is:

As an extension, put it in a table with values to that point to the 
public IDs for endspoints and projects.
xor
Make the table part of the assignments backend, and give it a fk 
constraint to proejcts
xor
Make the table part of the catalog backend and give it a fk constraint 
to endpoints.

As it is going in as an extension, it has to be the first option.



>
> If the goal is to allow an extension to back to some sql store that is 
> not shared by the rest of keystone (which is I thought how this 
> conversation started?), then I'm not clear on how separate migration 
> repos would be the first step in that direction. If the extension owns 
> it's own sql store and therefore it's sqlalchemy engine, only then 
> does it makes sense (to me) to bundle the extension with it's own 
> migration repo. That would make "private" tables /actually /private, 
> given that they'd be configurable with unique sqlalchemy connection 
> strings, etc.

What it does it splits the migration version for the extension from the 
rest of Keystone.  We could drop the Endpoint table all together, but 
the endpoint-filtering plugin would still work.  Core tables don't care 
about extensions.

It will also greatly reduce the rebase ovehead of database migrations 
patches.

My patch does run the migrations for all extension, but it does not have 
to do so.  It might make sense, either as part of this patch or as a 
follow on, to provide command line switches to show the set of 
extensions that have repos, and to show the versions of those extensions 
in the database pointed to by the connection string. There is another 
blueprint for supporting multiple SQL sources, and, with that, we could 
potentially map extension to different databases than the core repo.  We 
can also add a command line parameter that explicitly specifies the 
extension for which to run the migrations.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130801/b6276d04/attachment.html>