On Wed, 2016-02-24 at 10:00 +0100, Martin Kosek wrote:
> On 02/23/2016 06:59 PM, Petr Spacek wrote:
> > On 23.2.2016 18:14, Simo Sorce wrote:
> >> More seriously I think it is a great idea, but too premature to get all
> >> the way there now. We need to build schema and CLI that will allow us to
> >> get there without having to completely change interfaces if at all
> >> possible or minimizing any disruption in the tools.
> > Actually the backwards compatibility is the main worry which led to this
> > idea
> > with links.
> > If we release first version of locations with custom priorities etc. we will
> > have support the schema (which will be different) and API (which will be
> > later
> > unnecessary) forever.
> > If we skip this intermediate phase with hand-made configuration we can save
> > all the headache with upgrades to more automatic solution later on.
> > Maybe we should invert the order:
> > Start with locations + links with administrative metric and add
> > hand-tweaking
> > capabilities later (if necessary).
> > IMHO locations + links with administrative metric will be easier to
> > implement
> > than the first version.
> > Just thinking aloud ...
> Makes sense to me, I would have the same worry as Petr, that we would break
> something if we decide moving to links based solution later.
Maybe I am missing something, but in order to generate the proper SRV
records we need priority and weights anyway, either by entering them
manually or by autogenerating them from some other piece of information
in the framework. So given this information is needed anyway why would
it become a problem to retain it in the future if we enable a tool the
simply autogenerates this information ?
Simo Sorce * Red Hat, Inc * New York
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code