<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 31, 2013 at 5:00 AM, Henry Nash <span dir="ltr"><<a href="mailto:henryn@linux.vnet.ibm.com" target="_blank">henryn@linux.vnet.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Adam,<br>
<br>
Wanted to just give you more detail on the issue I keep pressing on for your change (<a href="https://review.openstack.org/#/c/36731/" target="_blank">https://review.openstack.org/#/c/36731/</a>).<br>
<br>
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:<br>

<br>
1) It adds or changes the use of some columns in existing core tables, and has migrations and code that goes along with that.<br>
2) It adds a new "private" table, and has all the code to handle that<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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 <i>actually </i>private, given that they'd be configurable with unique sqlalchemy connection strings, etc.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) New APIs etc. to create new REST calls to drive the extension<br>
<br>
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?<br>

<br>
This hypothetical example is, of course, not too far from reality - the recent change I did for  inherited roles (<a href="https://review.openstack.org/#/c/35986/" target="_blank">https://review.openstack.org/#/c/35986/</a>) 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.<br>

<br>
Henry<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>