[openstack-dev] [Neutron] Service Type Framework implementation
nachi at ntti3.com
Tue Jul 9 19:00:22 UTC 2013
I agree for dynamic loading is difficult to implement.
(mainly for security perspective)
Salvatore looks clearly for no for dynamic loading.
So I added another option.
how about have list of preloaded module in the conf?
and setup service type from REST API such as nova flavor api
NOTE: I updated the style of doc
2013/7/9 Eugene Nikanorov <enikanorov at mirantis.com>:
> Hi Nachi,
> I agree on the future plan.
> However, dynamic loading/unloading of provider drivers will require
> additional code in service plugins, I'm not sure this will be fully
> supported in Havana (while I'm totally agree on implementing it)
> On Tue, Jul 9, 2013 at 3:40 AM, Nachi Ueno <nachi at ntti3.com> wrote:
>> Hi Eugene
>> It still not make sense for me to store static configuration on the DB
>> just for easy implementation.
>> However if the service type will support creation and deletion REST
>> api in future, I would like to approve this patch
>> as a first step of it.
>> You answered "I think it's doable but I'd still consider current
>> implementation as a first step - enikanorov. "
>> in the googled docs. so I believe we are in the same boat now.
>> I wanna make it clear future work.
>> - Service Type REST API (for admin) will add supports
>> - Ceate Service Type
>> - Delete Service Type
>> - Each driver users will lazy load the library if it is not loaded.
>> (may be this should be implemented on service side such as FW,
>> - Remove service type configuration from conf
>> Is this OK for you guys?
>> 2013/7/8 Eugene Nikanorov <enikanorov at mirantis.com>:
>> > Hi neutron folks,
>> > There has been a discussion around this patch
>> > https://review.openstack.org/#/c/29750/ that introduces configuration
>> > options and db table for storing service providers.
>> > The discussion is about whether we should store configuration in the db
>> > or
>> > not.
>> > The brief of discussion has been saved here:
>> > https://docs.google.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gefc32ecf_00
>> > Please share your thoughts on this.
>> > While we may continue to discuss the best approach to this, I'd like to
>> > see
>> > the patch to be committed first (it seems to be ready) as there are
>> > other
>> > features depending on it (NSX distributed router, lbaas, fwaas and
>> > vpnaas
>> > possibly).
>> > Thanks,
>> > Eugene.
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev