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?
_______________________________________________ Discuss mailing list Discuss@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/discuss
