Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: Redesigning Configuration Manager (CfgMgr) class
(Stephen Morris)
2. Re: Kea 0.9 tarball and docs for sanity checks (Jiri Popelka)
3. Re: Kea 0.9 tarball and docs for sanity checks (Jeremy C. Reed)
4. Kea 0.9 tarball and docs for sanity checks (last run)
(Wlodek Wencel)
----------------------------------------------------------------------
Message: 1
Date: Thu, 28 Aug 2014 15:52:20 +0100
From: Stephen Morris <[email protected]>
To: [email protected]
Subject: Re: Redesigning Configuration Manager (CfgMgr) class
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 27/08/14 09:10, Marcin Siodelski wrote:
> : :
So if I understand it right, the idea is that each configuration item
(e.g. list of Subnet4) has two objects:
1) A parser that interprets the data.
2) Objects that store the value of the configuration elements.
We still execute a two-phase approach: in the build() method, the
parser interprets the data, validates it and places it into a copy of
the data object (known as a "staging" object). When commit() is
executed, the parser changes a pointer, so what was "staging" data
becomes the "current" data. The original "current" data is retained
and becomes "old" data. We also add a rollback() method that will
move "old" data back to "current" data.
That seems reasonable (although I doubt we will need more than one
level of rollback).
> Note that the use of "staging" configuration eliminates a need for
> keeping an additional parser context which we currently use for
> keeping data integrity. This also eliminates a need for parsers to
> have build and commit phases. The commit is an atomic operation
> executed at the very end of the configuration parsing and it is
> always exception free. In build phase exceptions are possible and
> build() functions of configruation parsers operate on the "staging"
> configuration which they query from the CfgMgr. There will also be
> no need to provide storages for configuration parsers because
> configuration parsers will use the "staging" configuration as a
> storage.
I see that commit() and rollback() are likely to be methods in the
base class of parsers, but I would not remove the ability of parsers
to override them; some parsers may need to do additional work on a
commit() call (e.g. the hooks subsystem should load the new libraries
when commit() is called).
> Overall, I am pretty confident that those simple changes will
> reduce the complexity of the configuration parsers which is a pain
> in the back right now.
>
> Feedback appreciated as well as additional requirements.
Additional requirements:
1) The parser code should be moved out of dhcpsrv and into a separate
library.
2) Parsers should be registered with the configuration manager rather
than be built into it. So if we add a new feature to the code, the
parser for it can be in the same module/library as the feature. (This
has the implication that the parser needs to be able to specify the
part of the configuration file it is parsing, rather than the
configuration manager "knowing" it and calling the parser at the right
time.)
Stephen
------------------------------
Message: 2
Date: Thu, 28 Aug 2014 17:40:52 +0200
From: Jiri Popelka <[email protected]>
To: Wlodek Wencel <[email protected]>, [email protected]
Subject: Re: Kea 0.9 tarball and docs for sanity checks
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 08/28/2014 11:29 AM, Wlodek Wencel wrote:
> Hello,
>
> Kea 0.9 tarball and docs ready for sanity checks, thank you for help!
> Everything available on: http://kea.isc.org/~wlodek/
>
> sha256 checksums:
> 8d371e8ec2cbda1677c4543a1c14a5fc8f8f33b596f1d6d7a58de8d5e93361e1
> kea-0.9.tar.gz
No problems spotted, builds OK on Fedora:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7475406
--
Jiri
------------------------------
Message: 3
Date: Thu, 28 Aug 2014 10:53:47 -0500 (CDT)
From: "Jeremy C. Reed" <[email protected]>
To: Jiri Popelka <[email protected]>
Cc: [email protected]
Subject: Re: Kea 0.9 tarball and docs for sanity checks
Message-ID: <[email protected]>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 28 Aug 2014, Jiri Popelka wrote:
> No problems spotted, builds OK on Fedora:
Thank you much Jiri!
Wlodek: the tarball didn't include the generated docs. Add
--enable-generate-docs to your the automated release builder. (Maybe
need to add to DISTCHECK_CONFIGURE_FLAGS.)
I also did some trivial updates to master you may want to consider.
I am also going to remove the "beta1" reference from docs and the BIND10
note from "make install" output. You may want to consider these also.
------------------------------
Message: 4
Date: Thu, 28 Aug 2014 23:54:57 +0200
From: Wlodek Wencel <[email protected]>
To: [email protected]
Subject: Kea 0.9 tarball and docs for sanity checks (last run)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hello,
Kea 0.9 tarball and docs ready for sanity checks, thank you for help!
Everything available on: http://kea.isc.org/~wlodek/
sha256 checksums:
517fc4d6a7c2dcc06f906a09b9cfdf68ffe6d457c369502cd043e8efe636c82b kea-0.9.tar.gz
33cf33f185157185526a09696d37496199c8e235309926b97b59a454921dcdcf kea-guide.css
5d74fa383272b3d5382a32474b72b465bef4d2ae911ca3c32e0e54f870e0c551 kea-guide.html
163019f86ff4a0c2057b6230e70613df6964d76fc48aa8a76bcd95c61368acf6 kea-guide.pdf
f21791569220e8b1555a4a10f2d63b1d9b5ced21f54e528a3384fc530d9d9b29 kea-guide.txt
cbe4f2c72e64e37f3d91af078ff107c6e724c3211715e44e01caad578c002ad8
kea-messages.html
ca7e5dbf9c4f7823c2522526c68fc0cdb541d203979a215f1d3d1a8cf984c760
kea-messages.pdf
Regards
W?odek
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 5, Issue 8
*************************************
