Re: [openstack-dev] [Neutron] Service Type Framework implementation

[Eugene Nikanorov]

Ok, having so much pressure on db implementation, I think I'm just going to
post in-memory implementation and we'll decide if it will fit our needs.

Thanks,
Eugene.


On Wed, Jul 10, 2013 at 5:56 AM, Nachi Ueno na...@ntti3.com wrote:

 Hi Mark


 2013/7/9 Mark McClain mark.mccl...@dreamhost.com:
 
  On Jul 9, 2013, at 5:37 PM, Nachi Ueno na...@ntti3.com wrote:
 
  We have two suboption for db api based solution
 
  Option4. REST API + DB with Preload with Conf
 
 https://docs.google.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf14b7b30_00
 
  so IMO, we can drop  option3.
 
  I believe option4 is easy to implement.
 
 
  I'm not onboard with option 4 either.  At the last summit, we talked
 about making Neutron easier to deploy.  Using a database to sync
 configuration state adds complexity.  Having some values in a configuration
 and others in the database (even cached) is a recipe for a major headache.
  For the deployments running multiple instances of Neutron, they should be
 using Chef, Chef, Salt, etc for managing their configs anyway.
 
  Using only configuration files (option 1) remains my preference.

 only configuration files (option 1)  is also acceptable for me.
 However, the headache continues even if we choose option1, because
 relation with service type
 and service resources are in the DB.

 Note that we still need to provide way to add or remove service types.

 Option1-1)
Allow to create new relation if it appears in the conf.
Remove the relation if it is disappears from conf.

IMO, This will fall on same problem of current implementation

 https://docs.google.com/a/ntti3.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf0f4e2a2_1136

 Option1-2) Provide admin rest api for enable/disable service types
 Allow to create new relation if it is enabled by API
  Remove the relation if it disabled by API

 This is my preference. And IMO, this is same as option4.

 Best
 Nachi




  mark
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Service Type Framework implementation

[Akihiro MOTOKI]

Hi,

Sorry for late cut-in,

I agree that dynamic configuration through the API is not easy to implement.
At now, conf-based approach without database (option-1) looks the best way
unless we
don't have needs for dynamic configuration thru the API.

 1) From logic perspective service provider could be referenced by
(service_type, name) as it's unique primary key.
 2) From data normalization perspective it's better (and more convenient)
to have an unique ID in resource provider model.
 Obviously having ID works for DB implementation and doesn't work for
in-memory implementation.
 In other words, we can't use ID if we go with in-memory implementation.

I think ID is not necessarily required.
In DB approach, we can specify multiple fields as a primary key.
In in-memory approach, we can use a json-serialized string as a key
like json.dumps({'type': 'xxx', 'name': 'yyy'}).

In typical use cases,
(1) neutron-server retrieves a provider from assocation table
(which is usually implemented on database)
(2) neutron-server determines a driver from a provider.
In this case, dict-based approach does enough I believe.
Is there any other typical access pattern?

 3) From data modelling perspective it's better to have ID in service
provider model as referencing models will be simpler and easier to maintain.

As long as we don't have more keys than type and name to identify providers,
(type, name) combination looks simple enough.

service provider is similar to flavor in nova at some point.
flavor represents a combination of many fields.
If there is a possible case where a provider definition have more unique
keys, ID approach makes sense much.

 4) From CLI perspective it's more convenient if resource has ID, it's a
common way of specifying resource.

API perspective for an association from a resource to a provider,
a type is determined from a resource and what we need to specify is only
name.
As long as we can identify a provider by (type, name),
there is no difference between using ID and using name.

Regarding a possible demerit without ID, it is difficult to specify a
specific provider to show its detail.
At now a provider has only a couple of visible field (type, name, default)
through API, so list-service-providers does enough and show-service-provider
does not provide more. (It just provides API consistency with other
resources.)

 5) From user perspective it's more convenient to specify the name of
service provider.
 But that is usually solved either by Horizon or by cli, like it's done
for networks/subnets where name of the object is specified.


Thanks,
Akihiro



2013/7/10 Eugene Nikanorov enikano...@mirantis.com

 Ok, having so much pressure on db implementation, I think I'm just going
 to post in-memory implementation and we'll decide if it will fit our needs.

 Thanks,
 Eugene.


 On Wed, Jul 10, 2013 at 5:56 AM, Nachi Ueno na...@ntti3.com wrote:

 Hi Mark


 2013/7/9 Mark McClain mark.mccl...@dreamhost.com:
 
  On Jul 9, 2013, at 5:37 PM, Nachi Ueno na...@ntti3.com wrote:
 
  We have two suboption for db api based solution
 
  Option4. REST API + DB with Preload with Conf
 
 https://docs.google.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf14b7b30_00
 
  so IMO, we can drop  option3.
 
  I believe option4 is easy to implement.
 
 
  I'm not onboard with option 4 either.  At the last summit, we talked
 about making Neutron easier to deploy.  Using a database to sync
 configuration state adds complexity.  Having some values in a configuration
 and others in the database (even cached) is a recipe for a major headache.
  For the deployments running multiple instances of Neutron, they should be
 using Chef, Chef, Salt, etc for managing their configs anyway.
 
  Using only configuration files (option 1) remains my preference.

 only configuration files (option 1)  is also acceptable for me.
 However, the headache continues even if we choose option1, because
 relation with service type
 and service resources are in the DB.

 Note that we still need to provide way to add or remove service types.

 Option1-1)
Allow to create new relation if it appears in the conf.
Remove the relation if it is disappears from conf.

IMO, This will fall on same problem of current implementation

 https://docs.google.com/a/ntti3.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf0f4e2a2_1136

 Option1-2) Provide admin rest api for enable/disable service types
 Allow to create new relation if it is enabled by API
  Remove the relation if it disabled by API

 This is my preference. And IMO, this is same as option4.

 Best
 Nachi




  mark
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 

Re: [openstack-dev] [Neutron] Service Type Framework implementation

[Akihiro MOTOKI]

Thanks Engene,

I have looked at your new patch. It looks nice.
The router-provider association can be merged into service-provider
association,
but it can be done in another patch and I can do it.

I am also working to support multiple router implementations in NEC plugin
using this framework.
It is similar to Salvatore's distribution router patch.

Thanks,
Akihiro

2013/7/10 Salvatore Orlando sorla...@nicira.com

 Thanks Eugene,

 I am already looking at your new patch.
 Thankfully it seems that keeping providers in configuration files was not
 as hard as anticipated in previous rounds of reviews.

 I don't think what you did is a hack; I will fix rework the
 router-provider association extension in the distributed router patch or
 another patch.
 From my point of view, I think you can even remove altogether that code
 from your patch - if you don't feel happy about it.
 I will take care of restoring that extension afterwards; after all, it is
 outside of the scope of your blueprint.

 Salvatore


 On 10 July 2013 15:49, Eugene Nikanorov enikano...@mirantis.com wrote:

 Folks,

 I have put initial in-memory implementation of service providers on
 review.

 On of the 'hacks' I had to do is decoupling RouterServiceProviderBinding
 from service provider.
 I've just removed foreign key to ServiceProviders table.
 I think this needs to be fixed in the patch which introduces the code
 which uses it (like the one published by Salvatore)

 Thanks,
 Eugene.



 On Wed, Jul 10, 2013 at 2:33 PM, Akihiro MOTOKI amot...@gmail.comwrote:

 Hi,

 Sorry for late cut-in,

 I agree that dynamic configuration through the API is not easy to
 implement.
 At now, conf-based approach without database (option-1) looks the best
 way unless we
 don't have needs for dynamic configuration thru the API.

  1) From logic perspective service provider could be referenced by
 (service_type, name) as it's unique primary key.
   2) From data normalization perspective it's better (and more
 convenient) to have an unique ID in resource provider model.
  Obviously having ID works for DB implementation and doesn't work for
 in-memory implementation.
  In other words, we can't use ID if we go with in-memory implementation.

 I think ID is not necessarily required.
 In DB approach, we can specify multiple fields as a primary key.
 In in-memory approach, we can use a json-serialized string as a key
 like json.dumps({'type': 'xxx', 'name': 'yyy'}).

 In typical use cases,
 (1) neutron-server retrieves a provider from assocation table
 (which is usually implemented on database)
 (2) neutron-server determines a driver from a provider.
 In this case, dict-based approach does enough I believe.
 Is there any other typical access pattern?

  3) From data modelling perspective it's better to have ID in service
 provider model as referencing models will be simpler and easier to maintain.

 As long as we don't have more keys than type and name to identify
 providers,
 (type, name) combination looks simple enough.

 service provider is similar to flavor in nova at some point.
 flavor represents a combination of many fields.
 If there is a possible case where a provider definition have more unique
 keys, ID approach makes sense much.

  4) From CLI perspective it's more convenient if resource has ID, it's
 a common way of specifying resource.

 API perspective for an association from a resource to a provider,
 a type is determined from a resource and what we need to specify is
 only name.
 As long as we can identify a provider by (type, name),
 there is no difference between using ID and using name.

 Regarding a possible demerit without ID, it is difficult to specify a
 specific provider to show its detail.
 At now a provider has only a couple of visible field (type, name,
 default)
 through API, so list-service-providers does enough and
 show-service-provider
 does not provide more. (It just provides API consistency with other
 resources.)

  5) From user perspective it's more convenient to specify the name of
 service provider.
  But that is usually solved either by Horizon or by cli, like it's done
 for networks/subnets where name of the object is specified.
 

 Thanks,
 Akihiro



 2013/7/10 Eugene Nikanorov enikano...@mirantis.com

 Ok, having so much pressure on db implementation, I think I'm just
 going to post in-memory implementation and we'll decide if it will fit our
 needs.

 Thanks,
 Eugene.


 On Wed, Jul 10, 2013 at 5:56 AM, Nachi Ueno na...@ntti3.com wrote:

 Hi Mark


 2013/7/9 Mark McClain mark.mccl...@dreamhost.com:
 
  On Jul 9, 2013, at 5:37 PM, Nachi Ueno na...@ntti3.com wrote:
 
  We have two suboption for db api based solution
 
  Option4. REST API + DB with Preload with Conf
 
 https://docs.google.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf14b7b30_00
 
  so IMO, we can drop  option3.
 
  I believe option4 is easy to implement.
 
 
  I'm not onboard with option 4 either.  At the last summit, 

Re: [openstack-dev] [Neutron] Service Type Framework implementation

[Eugene Nikanorov]

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)

Thanks,
Eugene.


On Tue, Jul 9, 2013 at 3:40 AM, Nachi Ueno na...@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,
 LBaaS,VPN)

 - Remove service type configuration from conf

 Is this OK for you guys?

 Thanks
 Nachi


 2013/7/8 Eugene Nikanorov enikano...@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@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Service Type Framework implementation

[Salvatore Orlando]

Some comments inline.

Salvatore


On 9 July 2013 21:58, Eugene Nikanorov enikano...@mirantis.com wrote:

 Nachi,

 I think that dynamic loading/preloaded modules/REST api analogs of nova
 flavor is a bit too forward looking in comparison to what I'm trying to
 solve right now with existing patch.


Besides, the real issue with this approach is that neutron would be lending
itself to any sort of security exploit. I am not a security expert, so feel
free to disagree if you want.
I would just prefer to not see dynamic loading of python modules of values
which are stored in the db; not in this release, not in the next one.



 I think what really matters is how service providers are referenced from
 other resources.

 1) From logic perspective service provider could be referenced by
 (service_type, name) as it's unique primary key.
 2) From data normalization perspective it's better (and more convenient)
 to have an unique ID in resource provider model.


Adding another primary key were you already identified a couple of
attributes which are a primary key is actually, from what I recall from my
studies, de-normalization.
Sorry, this was just pedant me talking. Feel free to ignore.


 Obviously having ID works for DB implementation and doesn't work for
 in-memory implementation.
 In other words, we can't use ID if we go with in-memory implementation.


You could, but it would not make a lot of sense; and you would have to
store those ids somewhere anyway; so - no it's not a good idea.

When you associate an instance of a service to a provider, you might think
that the fact that they key is (type, name) will force you to use two
attributes. This would be true if you think about the corresponding E-R
model. However, in the case of the APIs we're dealing with, the resource
type itself identifies the first bit of the (type, name) pair. So one might
as well associate only the service provider name to the service instance.


 3) From data modelling perspective it's better to have ID in service
 provider model as referencing models will be simpler and easier to maintain.
 4) From CLI perspective it's more convenient if resource has ID, it's a
 common way of specifying resource.


We already clarified that for referencing items in the CLI (or horizon) we
can use either name or id. It's a consolidated practice in both of them.


 5) From user perspective it's more convenient to specify the name of
 service provider.
 But that is usually solved either by Horizon or by cli, like it's done for
 networks/subnets where name of the object is specified.

 Resuming all this I see significant benefits of using ID (and hence, db
 implementation) over not using it.
 Also, I don't think storing immutable data in db is any kind of a bad
 design: it's just a storage anyway.


As Mark has rightly pointed out, it's generally not a great idea to store
configuration data in the db.
However in this case it is worth mentioning that the data in the db is
exactly the same as the data in the config files.


 DB storage offers better integration with other objects stored in db, and
 saves some code lines doing stuff which DB normally does.
 That lines will stack up in case we add more objects (like service
 offerings) on top of in-memory storage.



 Thanks,
 Eugene.







 On Tue, Jul 9, 2013 at 11:00 PM, Nachi Ueno na...@ntti3.com wrote:

 Hi Eugene

 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


 https://docs.google.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf14b7b30_00

 NOTE: I updated the style of doc

 Best
 Nachi


 2013/7/9 Eugene Nikanorov enikano...@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)
 
  Thanks,
  Eugene.
 
 
  On Tue, Jul 9, 2013 at 3:40 AM, Nachi Ueno na...@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,
  LBaaS,VPN)
 
  - Remove 

Re: [openstack-dev] [Neutron] Service Type Framework implementation

[Nachi Ueno]

Hi folks

Replied Inline

2013/7/9 Salvatore Orlando sorla...@nicira.com:
 Some comments inline.

 Salvatore


 On 9 July 2013 21:58, Eugene Nikanorov enikano...@mirantis.com wrote:

 Nachi,

 I think that dynamic loading/preloaded modules/REST api analogs of nova
 flavor is a bit too forward looking in comparison to what I'm trying to
 solve right now with existing patch.


 Besides, the real issue with this approach is that neutron would be lending
 itself to any sort of security exploit. I am not a security expert, so feel
 free to disagree if you want.
 I would just prefer to not see dynamic loading of python modules of values
 which are stored in the db; not in this release, not in the next one.

We have two suboption for db api based solution

Option3. DB API + Dynamic module load (many guys are saying no for this option3)
https://docs.google.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf0f4e2a2_1163

Option4. REST API + DB with Preload with Conf
https://docs.google.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf14b7b30_00

so IMO, we can drop  option3.

I believe option4 is easy to implement.



 I think what really matters is how service providers are referenced from
 other resources.

 1) From logic perspective service provider could be referenced by
 (service_type, name) as it's unique primary key.
 2) From data normalization perspective it's better (and more convenient)
 to have an unique ID in resource provider model.


 Adding another primary key were you already identified a couple of
 attributes which are a primary key is actually, from what I recall from my
 studies, de-normalization.
 Sorry, this was just pedant me talking. Feel free to ignore.


 Obviously having ID works for DB implementation and doesn't work for
 in-memory implementation.
 In other words, we can't use ID if we go with in-memory implementation.


 You could, but it would not make a lot of sense; and you would have to store
 those ids somewhere anyway; so - no it's not a good idea.

 When you associate an instance of a service to a provider, you might think
 that the fact that they key is (type, name) will force you to use two
 attributes. This would be true if you think about the corresponding E-R
 model. However, in the case of the APIs we're dealing with, the resource
 type itself identifies the first bit of the (type, name) pair. So one might
 as well associate only the service provider name to the service instance.


 3) From data modelling perspective it's better to have ID in service
 provider model as referencing models will be simpler and easier to maintain.
 4) From CLI perspective it's more convenient if resource has ID, it's a
 common way of specifying resource.


 We already clarified that for referencing items in the CLI (or horizon) we
 can use either name or id. It's a consolidated practice in both of them.


 5) From user perspective it's more convenient to specify the name of
 service provider.
 But that is usually solved either by Horizon or by cli, like it's done for
 networks/subnets where name of the object is specified.

 Resuming all this I see significant benefits of using ID (and hence, db
 implementation) over not using it.
 Also, I don't think storing immutable data in db is any kind of a bad
 design: it's just a storage anyway.


 As Mark has rightly pointed out, it's generally not a great idea to store
 configuration data in the db.
 However in this case it is worth mentioning that the data in the db is
 exactly the same as the data in the config files.

If same data are stored in the multiple place, IMO it is not good idea.
In current implementation, the data is stored in DB + on each neutron
servers conf.
Who's master in this case??
In current implementation, recent load of conf wins, so it could be
disaster for operators.

(I draw figure for this case)
https://docs.google.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf0f4e2a2_1136



 DB storage offers better integration with other objects stored in db, and
 saves some code lines doing stuff which DB normally does.
 That lines will stack up in case we add more objects (like service
 offerings) on top of in-memory storage.

so how about this option?

Option4. REST API + DB with Preload with Conf
https://docs.google.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf14b7b30_00

Best
Nachi



 Thanks,
 Eugene.







 On Tue, Jul 9, 2013 at 11:00 PM, Nachi Ueno na...@ntti3.com wrote:

 Hi Eugene

 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


 https://docs.google.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf14b7b30_00

 NOTE: I updated the 

Re: [openstack-dev] [Neutron] Service Type Framework implementation

[Mark McClain]

On Jul 9, 2013, at 5:37 PM, Nachi Ueno na...@ntti3.com wrote:
 
 We have two suboption for db api based solution
 
 Option4. REST API + DB with Preload with Conf
 https://docs.google.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf14b7b30_00
 
 so IMO, we can drop  option3.
 
 I believe option4 is easy to implement.
 

I'm not onboard with option 4 either.  At the last summit, we talked about 
making Neutron easier to deploy.  Using a database to sync configuration state 
adds complexity.  Having some values in a configuration and others in the 
database (even cached) is a recipe for a major headache.  For the deployments 
running multiple instances of Neutron, they should be using Chef, Chef, Salt, 
etc for managing their configs anyway.

Using only configuration files (option 1) remains my preference.

mark 
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Service Type Framework implementation

[Nachi Ueno]

Hi Mark


2013/7/9 Mark McClain mark.mccl...@dreamhost.com:

 On Jul 9, 2013, at 5:37 PM, Nachi Ueno na...@ntti3.com wrote:

 We have two suboption for db api based solution

 Option4. REST API + DB with Preload with Conf
 https://docs.google.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf14b7b30_00

 so IMO, we can drop  option3.

 I believe option4 is easy to implement.


 I'm not onboard with option 4 either.  At the last summit, we talked about 
 making Neutron easier to deploy.  Using a database to sync configuration 
 state adds complexity.  Having some values in a configuration and others in 
 the database (even cached) is a recipe for a major headache.  For the 
 deployments running multiple instances of Neutron, they should be using Chef, 
 Chef, Salt, etc for managing their configs anyway.

 Using only configuration files (option 1) remains my preference.

only configuration files (option 1)  is also acceptable for me.
However, the headache continues even if we choose option1, because
relation with service type
and service resources are in the DB.

Note that we still need to provide way to add or remove service types.

Option1-1)
   Allow to create new relation if it appears in the conf.
   Remove the relation if it is disappears from conf.

   IMO, This will fall on same problem of current implementation
   
https://docs.google.com/a/ntti3.com/presentation/d/1v0nLTEsFOwWeYpYjpw4qe3QHB5lLZEE_b0TmmR5b7ic/edit#slide=id.gf0f4e2a2_1136

Option1-2) Provide admin rest api for enable/disable service types
Allow to create new relation if it is enabled by API
 Remove the relation if it disabled by API

This is my preference. And IMO, this is same as option4.

Best
Nachi




 mark
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Service Type Framework implementation

[Nachi Ueno]

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, LBaaS,VPN)

- Remove service type configuration from conf

Is this OK for you guys?

Thanks
Nachi


2013/7/8 Eugene Nikanorov enikano...@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@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev