Sam, my POV is that most of typical "functional" config actually should be YANG in DS, clustered and what not.
I prefer defaults in code not in BP XML, just because it means (component) tests wired with Guice instead of BP pick them up as well, but that is a minor point. There are exceptions to this general rule for lower level infrastructure stuff - metrics is one that comes to mind, also the various Karaf system config in etc/ files, as well as probably the DS/cluster config itself. IMHO this is just fine as is (and no plans to do any work in this area, from me) because I don't really see where those system config knobs would have to be touched in a running cluster in prod. An installation orchestator thing (à la TripleO) may set non-defaults in etc/, initially, only. HTH. On 8 Feb 2018 15:59, "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? > > > _______________________________________________ > infrautils-dev mailing list > infrautils-...@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/infrautils-dev > >
_______________________________________________ Discuss mailing list Discuss@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/discuss
