[kea-dev] OpenBSD: Kea 1.2.0

[Marcin Siodelski]

On 26.07.2017 17:13, Patrik Lundin wrote:
> On Mon, Jul 24, 2017 at 12:52:01PM +0200, Marcin Siodelski wrote:
>>>
>>> As mentioned in
>>> https://lists.isc.org/pipermail/kea-users/2017-July/001050.html I am
>>> currently updating the Kea port in OpenBSD to 1.2.0.
>>>
>>> First of all I notice that while the majority of the shared libraries
>>> have an explicit version configured using the "-version-info" flag in
>>> the Makefiles, there are a few that do not:
>>> ===
>>> kea-asiodns (src/lib/asiodns/Makefile.am)
>>> kea-exceptions (src/lib/exceptions/Makefile.am)
>>> kea-util-io (src/lib/util/io/Makefile.am)
>>> ===
>>>
>>
>> We leave them in their defaults which is 0:0:0 and that's what we
>> consider is their current version. None of these libraries have been
>> recently updated and they will rarely be.
>>
>>> Is there a reason for this or is it just an oversight? In general it
>>> seems the other ones have settings along these lines:
>>> ===
>>> libkea_cfgclient_la_LDFLAGS = -no-undefined -version-info 3:0:0
>>> ===
>>>
>>
>> The other libraries have explicit versions added because they are
>> updated from the release to release and for each library which code have
>> been updated we bump up version numbers prior to a Kea release. If a
>> library is at version 0:0:0 and its code haven't been updated we just
>> leave the implicit version. If we happen to update the code in any of
>> those libs in the future it will be followed by a version bump, so it
>> will be given an explicit version-info, e.g. 1:0:0.
>>
> 
> The main thing that makes this a bit confusing is that there are
> currently two libraries that are explicitly configured to 0:0:0:
> ===
> src/lib/http/Makefile.am:libkea_http_la_LDFLAGS += -no-undefined -version-info 0:0:0
> src/lib/process/Makefile.am:libkea_process_la_LDFLAGS += -no-undefined -version-info 0:0:0
> ===
> 
> This makes it difficult to understand if a library that is missing a
> explicit version string is doing so because it is "supposed to
> default to 0:0:0" or if it has been forgotten.
> 
> Would it hurt to always be explicit? If nothing else it makes it easy to
> update once it is suppused to be incremented in the future.
> 
>>> The reason I ask about this is that port Makefiles in OpenBSD keep track
>>> of SHARED_LIBS version numbers. It helps me out a lot when there is clear
>>> indication that a library version needs to be bumped because of changes by
>>> upstream.
>>>
>>
>> Is it possible for the port Makefiles to simply assume that no
>> version-info means version 0?
>>
> 
> The reported result currently lists the unconfigured libraries as
> version "unknown". This will be treated as 0:0:0.
> 
>>> I also noticed one of the version numbers went backwards in 1.2.0 in
>>> comparision to 1.1.0. kea-dns++ went from 2.0 to 1.1. It can be seen in
>>> src/lib/dns/Makefile.am, git commit 88d32454640a1f5f80fc4cd75339647be0210426.
>>> Was this a mistake or am I missing something?
>>>
>>
>> Yes, we had made some mistakes in the versioning of this library in the
>> past, i.e. the version number had been bumped too high. In one of the
>> recent releases we amended this version number to what it should be. I
>> realize it is strange to go backwards but the current version is what it
>> should be.
>>
> 
> Thanks for the info. I guess this is the reason the Makefile keeps it's
> own versioning scheme since I can then increment it to reflect a later
> version even if upstream jumps back and forth :).
> 
>>> As Mike noted in the above mentioned thread Kea 1.2.0 requires a more
>>> modern compiler and because of that I am using clang. The build fails in
>>> the following way without patches:
> [...]
>>>
>>> This was fixed by Marc Espie (espie@) prior to me starting to look at
>>> 1.2.0 here:
>>> http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/kea/patches/patch-src_lib_util_watch_socket_cc
>>>
>>> I'm thinking it is a good candidate for being merged upstream.
>>>
>>
>> I agree. I don't see any problem with porting this fix into Kea. In fact
>> I have just done it.
>>
> 
> Great, then I can drop the patch in a later version.
> 
>>> I also noticed that while a ticket i previously filed
>>> (https://kea.isc.org/ticket/5072) has been solved, and the lfc-interval
>>> has been added to a bunch of places in the repo, it has not been added
>>> to the src/bin/keactrl/kea.conf.pre file which ends up as the default
>>> kea.conf. Is this intentional? I also notice "persist" is not configured
>>> by default, even if this seems to be strongly encouraged in the
>>> documentation.
>>>
>>
>> Kea configuration allows for omission of some of the configuration
>> parameters causing the servers to fallback to the defaults. For the sake
>> of config readability we purposely omit some of the parameters in the
>> default configuration file.
>>
>> As for "persist", we don't specify it explicitly in the default config
>> file and let be the default true (enabled). Note that if we put the
>> "persist": true into the default config we'd give an impression that
>> this is a parameter that can be controlled just like other parameters,
>> while we rather want people to not disable it.
>>
> 
> That makes sense for the persist keyword, thanks. I still wonder about
> lfc-interval though. It appears to default to 0, and has been explicitly
> set to 3600 in example configs (though not in src/bin/keactrl/kea.conf.pre).
> 
> This makes me wonder if either "kea.conf.pre" should be updated with an
> explicit lfc-interval of 3600, or if the default should be changed from
> 0 to 3600 and the lines removed from all example configurations again.
> 


Patrik,

I have created two Kea tickets:

- http://kea.isc.org/ticket/5341
- http://kea.isc.org/ticket/5342

to address those issues. We're going to discuss them on our regular Kea
team calls and we'll see where they end up. We don't seem to have any
disagreement about the first one. It is only a matter when it will be
released. We haven't discussed the #5342 but I don't personally see why
we couldn't do it.

Marcin