On Thu, Feb 8, 2018 at 9:59 AM, Sam Hague <sha...@redhat.com> wrote:

>
>
> On Thu, Feb 8, 2018 at 9:38 AM, Tom Pantelis <tompante...@gmail.com>
> wrote:
>
>>
>>
>> On Thu, Feb 8, 2018 at 9:24 AM, Sam Hague <sha...@redhat.com> wrote:
>>
>>>
>>>
>>> On Thu, Feb 8, 2018 at 9:08 AM, Tom Pantelis <tompante...@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Feb 8, 2018 at 8:56 AM, Sam Hague <sha...@redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Feb 8, 2018 at 8:54 AM, Sam Hague <sha...@redhat.com> wrote:
>>>>>
>>>>>> What is the preferred or suggested best practice for service level
>>>>>> configuration? There are two methods we have been using and would like to
>>>>>> know the pros and cons of each. Genius and NetVirt went with the 
>>>>>> blueprint
>>>>>> xmls and openflowplugin and ovsdb went with the cfg's.
>>>>>>
>>>>> This seems confusing to end users to have two different methods of
>>>>> configuration.
>>>>>
>>>>
>>>> The clustered-app-config has advantages outlined in
>>>> https://wiki.opendaylight.org/view/Using_Blueprint#Applic
>>>> ation_configuration. However it does require the data store so in some
>>>> cases may not want that dependency or can't, like infrautls.   Not sure why
>>>> OFP and ovsdb opted for cfg files - perhaps that was before
>>>> clustered-app-config?
>>>>
>>> Adding Anil for why ofp and ovsdb used cfg's as he drove that at the
>>> same time. I thought it was because he thought it was easiest to implement
>>> but that we would migrate to xml later.
>>>
>>> That is a good point on the extra dependencies. Seems like xml is better
>>> if you have mdsal and restconf, but you don't have those dependencies in
>>> projects like infrautils. Would it make sense to have some kind of cfg
>>> adapter/wrapper to five capabilities to the cfg users?
>>>
>>>>
>>>>
>>>
>> So define a yang model for the cfg options in infrautils in some other
>> project with a DTCL that writes to the cfg file? That seems doable but what
>> project (genius I guess)?  And what happens if someone edits the file
>> locally....
>>
> Yes, this is what I was thinking - in genius and it gives the cfg users
> the benefits of the xml stuff. If used, then I think it means the cfg's
> should not be manually modified - all modifications should come through the
> genius xml wrapper. If editted locally, maybe we could write it to mdsal
> also, though I agree it gets messy, so maybe just don't allow that if
> possible.
>
> What happens now if you have multiple ODL nodes and someone edits a cfg on
> one node - does it only impact that node? guess that is the main benefit of
> xml that it is cluster aware. But if the user did do this, it is somewhat
> like your case of if a cfg is manually editted. Seems like you would need
> to update all cfg's right?
>

Yes you do although I think karaf has a way of distributing cfgs (I recall
a component called "cellar") - but, with the advent of
clustered-app-config,  I never researched it so not sure how it works.
_______________________________________________
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Reply via email to