Open Stack

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 <enikanorov at 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 <amotoki at gmail.com> wrote:
>
>> 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 <enikanorov at 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 <nachi at ntti3.com> wrote:
>>>
>>>> Hi Mark
>>>>
>>>>
>>>> 2013/7/9 Mark McClain <mark.mcclain at dreamhost.com>:
>>>> >
>>>> > On Jul 9, 2013, at 5:37 PM, Nachi Ueno <nachi at 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 at lists.openstack.org
>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>> _______________________________________________
>>>> 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
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Akihiro MOTOKI <amotoki at gmail.com>
>>
>> _______________________________________________
>> 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
> 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/20130710/2b674afa/attachment.html>