<HTML>
<HEAD>
<TITLE>Re: [Openstack] db & notification support for API extension?</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Has there been any investigation into using already existing plugin frameworks and just use those (and/or make those better)?<BR>
<BR>
Just from a quick google search:<BR>
<BR>
<a href="http://wehart.blogspot.com/2009/01/python-plugin-frameworks.html">http://wehart.blogspot.com/2009/01/python-plugin-frameworks.html</a><BR>
<BR>
It might be useful to see if we can find one that is generic and well-supported and already works “good enough”??<BR>
<BR>
On 4/25/12 3:04 PM, "Andrew Bogott" <<a href="abogott@wikimedia.org">abogott@wikimedia.org</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>On 4/25/12 4:48 PM, Nathanael Burton wrote:<BR>
> On Thu, Mar 8, 2012 at 11:53 AM, Andrew Bogott<<a href="abogott@wikimedia.org">abogott@wikimedia.org</a>> wrote:<BR>
>> I'm working on an API and implementation to support the creation of<BR>
>> filesystems that are shared among Nova instances.<BR>
>><BR>
>> <a href="http://wiki.openstack.org/SharedFS">http://wiki.openstack.org/SharedFS</a><BR>
>><BR>
>> My hope is to keep this API isolated from core Nova code, partly to avoid<BR>
>> stepping on toes and partly because I hope to be able to drop it into an<BR>
>> existing essex install. There are two things I need which I know how to do<BR>
>> within Nova but am not clear on how to do without modding Nova code:<BR>
>><BR>
>> 1) DB support<BR>
>><BR>
>> I need a database table to keep track of some filesystem metadata. My<BR>
>> current implementation adds the table via nova/db/sqlalchemy/migrate_repo...<BR>
>> but is it really necessary to coordinate this table with the rest of Nova?<BR>
>> Would it be reasonable to maintain the table independently within the<BR>
>> extension code? And, if so, are there any existing extensions that do<BR>
>> something like this?<BR>
> Have you determined a cleaner way of doing this? I have the same<BR>
> issues as you when writing API extensions.<BR>
Nate --<BR>
<BR>
The short answer is: I'm sure that it's straightforward to create a<BR>
'private' table which doesn't collide with existing nova tables, but I<BR>
have yet to do so.<BR>
<BR>
The longer answer is: Everything about that thread is now rolled into<BR>
the topic of 'the plugin framework' which we discussed at the design<BR>
summit and which I'm currently devoted to. Please consider adding your<BR>
use cases to the wiki page at <a href="http://wiki.openstack.org/novaplugin">http://wiki.openstack.org/novaplugin</a>, and<BR>
let me know if you would like me to add you to the list of people I cc:<BR>
when looking for opinions and/or reporting progress.<BR>
<BR>
-Andrew<BR>
<BR>
_______________________________________________<BR>
Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><BR>
Post to : <a href="openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><BR>
Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><BR>
More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>