Open Stack

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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130710/6270bdcc/attachment.html>