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. Converting configuration back to JSON (unparsing)
(Tomek Mrugalski)
2. Re: Converting configuration back to JSON (unparsing)
(Francis Dupont)
3. Re: Converting configuration back to JSON (unparsing)
(Thomas Markwalder)
4. Re: Converting configuration back to JSON (unparsing)
(Francis Dupont)
5. Re: Converting configuration back to JSON (unparsing)
(Tomek Mrugalski)
6. Re: Converting configuration back to JSON (unparsing)
(Thomas Markwalder)
7. Re: Converting configuration back to JSON (unparsing)
(Thomas Markwalder)
----------------------------------------------------------------------
Message: 1
Date: Thu, 23 Feb 2017 16:44:39 +0100
From: Tomek Mrugalski <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [kea-dev] Converting configuration back to JSON (unparsing)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
One of the features of upcoming 1.2 release will be the ability to
retrieve (get-config command) and store (write-config command) current
configuration. This problem is currently scoped to DHCPv4 and DHCPv6,
but the solution should also cover D2 and CA if possible.
There was some discussion in #1205 (http://kea.isc.org/ticket/1205), in
particular Francis said in comment 17:
---------------------------
To summary the current point of the discussion:
- the textual configuration T is a string in JSON format
- the configuration itself is a ConstElementPtr C
- the configuration state is a tree of Cfg structures SrvConfigPtr S
- the parser is a function: C -> S
- a valid configuration is a configuration which can be parsed without
throwing an exception
- we want to define an unparse function: S -> C with the property:
for all valid C parse(unparse(parse(C)) == parse(C)
Even it is not strictly needed a basic JSON pretty printer should output
C in a human readable form (this applies to C -> T)
--------------------------
I discussed this with Thomas and we're leaning towards the unparse
method to return C. The actual method should have the following interface:
ElementPtr toElement() const;
The reason why it should return ElementPtr rather than ConstElementPtr
is that whoever called this, may want to further edit the configuration.
We don't have that capability now, but it seems likely that one day we
will get a hook that handles configuration.
Also, usage of "parser" and "parse" words is overloaded in Kea project.
We use the same word to describe text to Element tree conversion (done
with bison) and also to describe Element tree to configuration
structures (done with SimpleParser derivatives). As such, unparse would
be confusing whether it undoes the second or both steps. Therefore
calling the method toElement() seems better.
Finally, converting from Element to text is trivial, because there are
Element::str() and << operators defined.
Any thoughts? Comments? If I don't hear any objections in couple days,
the 1205 ticket will be closed and we'll start with the implementation.
Tomek
------------------------------
Message: 2
Date: Thu, 23 Feb 2017 17:20:46 +0000
From: Francis Dupont <[email protected]>
To: Tomek Mrugalski <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Converting configuration back to JSON
(unparsing)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Tomek Mrugalski writes:
> One of the features of upcoming 1.2 release will be the ability to
> retrieve (get-config command) and store (write-config command) current
> configuration. This problem is currently scoped to DHCPv4 and DHCPv6,
> but the solution should also cover D2 and CA if possible.
=> if D2 and CA uses Cfg like classes to store configurations
there should be no problem to extend the solution to them.
BTW for DHCPv4 and DHCPv6 configurations were at the right place
(Cfg like classes under SrvConfig class (which is itself Cfg like)
at the exception of a few things directly in the config manager
and hook libraries in the parser itself).
> I discussed this with Thomas and we're leaning towards the unparse
> method to return C. The actual method should have the following interface:
>
> ElementPtr toElement() const;
=> the only open point is the method name. I use(d) unparse,
toElement is a bit better. For the abstract class ToElement seems
good, now I hesitate between cfg_to_element.h or to_element.h
(there are 18 header files using it, 4 only with a name which
don't begin by cfg_ so IMHO cfg_to_element.h is better).
> Also, usage of "parser" and "parse" words is overloaded in Kea project.
> We use the same word to describe text to Element tree conversion (done
> with bison) and also to describe Element tree to configuration
> structures (done with SimpleParser derivatives). As such, unparse would
> be confusing whether it undoes the second or both steps. Therefore
> calling the method toElement() seems better.
=> unparse is ugly so it is good only inside comments...
> Finally, converting from Element to text is trivial, because there are
> Element::str() and << operators defined.
=> there is a planned pretty printer too.
> Any thoughts? Comments? If I don't hear any objections in couple days,
> the 1205 ticket will be closed and we'll start with the implementation.
=> there is already a trac1205 branch so we should recycle the ticket.
And the implementation ticket #5114 will be big (6k lines for the diff)
so I strongly suggest to not put everything in it.
Thanks
Francis Dupont <[email protected]>
------------------------------
Message: 3
Date: Thu, 23 Feb 2017 14:09:59 -0500
From: Thomas Markwalder <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Converting configuration back to JSON
(unparsing)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 2/23/17 12:20 PM, Francis Dupont wrote:
> Tomek Mrugalski writes:
>> One of the features of upcoming 1.2 release will be the ability to
>> retrieve (get-config command) and store (write-config command) current
>> configuration. This problem is currently scoped to DHCPv4 and DHCPv6,
>> but the solution should also cover D2 and CA if possible.
> => if D2 and CA uses Cfg like classes to store configurations
> there should be no problem to extend the solution to them.
> BTW for DHCPv4 and DHCPv6 configurations were at the right place
> (Cfg like classes under SrvConfig class (which is itself Cfg like)
> at the exception of a few things directly in the config manager
> and hook libraries in the parser itself).
Yes, D2 has an object hierarchy constructed from Elements via
SimpleParsers. It is contained
in D2CfgContext.
https://jenkins.isc.org/job/Kea_doc/doxygen/d6/d31/d2.html#d2ProcessDerivation
See the section labeled Configuration Management
>> I discussed this with Thomas and we're leaning towards the unparse
>> method to return C. The actual method should have the following interface:
>>
>> ElementPtr toElement() const;
> => the only open point is the method name. I use(d) unparse,
> toElement is a bit better. For the abstract class ToElement seems
> good, now I hesitate between cfg_to_element.h or to_element.h
> (there are 18 header files using it, 4 only with a name which
> don't begin by cfg_ so IMHO cfg_to_element.h is better).
The class is going to be named ToElement()? Class names should be
nouns, typically.
Having it be ToElement::toElement() seems a bit off.
What about something more like Configurable which defines toElement()
method.
There may come a time when we want Configurable objects to do other things.
In that case, the include file would be configurable.h
>
>> Also, usage of "parser" and "parse" words is overloaded in Kea project.
>> We use the same word to describe text to Element tree conversion (done
>> with bison) and also to describe Element tree to configuration
>> structures (done with SimpleParser derivatives). As such, unparse would
>> be confusing whether it undoes the second or both steps. Therefore
>> calling the method toElement() seems better.
> => unparse is ugly so it is good only inside comments...
>
>> Finally, converting from Element to text is trivial, because there are
>> Element::str() and << operators defined.
> => there is a planned pretty printer too.
>
>> Any thoughts? Comments? If I don't hear any objections in couple days,
>> the 1205 ticket will be closed and we'll start with the implementation.
> => there is already a trac1205 branch so we should recycle the ticket.
> And the implementation ticket #5114 will be big (6k lines for the diff)
> so I strongly suggest to not put everything in it.
>
> Thanks
>
> Francis Dupont <[email protected]>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
Message: 4
Date: Thu, 23 Feb 2017 19:36:02 +0000
From: Francis Dupont <[email protected]>
To: Thomas Markwalder <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Converting configuration back to JSON
(unparsing)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Thomas Markwalder writes:
> Yes, D2 has an object hierarchy constructed from Elements via
> SimpleParsers. It is contained in D2CfgContext.
=> fine!
> The class is going to be named ToElement()?
=> CfgToElement but it is an abstract class so classes will derived
from it.
> Class names should be nouns, typically.
=> boost::noncopyable is a perfect counter-example.
> Having it be ToElement::toElement() seems a bit off.
=> the only place you should get it is in a doxygen comment
(and remember it is an instance method).
> What about something more like Configurable which defines toElement()
> method.
=> it is more Configured than Configurable but this does not catch
the fact the derived class must implement a toElement() method.
So ToElement seems a natural name.
I've just updated fdunparse private branch to these new names.
And BTW there is no ToElement::toElement found by grep (:-).
Thanks
Francis Dupont <[email protected]>
PS: for pretty print I believe a function is better (and less intrusive)
than to extend an existing method. I'll take the corresponding ticket
and change the code (and use it to not write whole configs for unit tests
twice :-).
------------------------------
Message: 5
Date: Thu, 23 Feb 2017 20:53:16 +0100
From: Tomek Mrugalski <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Converting configuration back to JSON
(unparsing)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
W dniu 23.02.2017 o 20:36, Francis Dupont pisze:
>> The class is going to be named ToElement()?
> => CfgToElement but it is an abstract class so classes will derived
> from it.
Huh? I thought toElement will be a method that will be implemented in
each existing class, so no extra classes needed at all.
>> Having it be ToElement::toElement() seems a bit off.
>
> => the only place you should get it is in a doxygen comment
> (and remember it is an instance method).
There should be no extra class. There should be CfgMgr::toElement() that
creates map element, puts all parameters it stores and then call
toElement() on all of its children (CfgOpionDef::toElement(),
CfgSubnets4::toElement(), etc.).
>> What about something more like Configurable which defines toElement()
>> method.
> => it is more Configured than Configurable but this does not catch
> the fact the derived class must implement a toElement() method.
> So ToElement seems a natural name.
>
> I've just updated fdunparse private branch to these new names.
> And BTW there is no ToElement::toElement found by grep (:-).
That's the problem of implementing code before there's an agreement how
the code should look like.
When we planned the work, it was decided on a meeting to use 1205 for
mini-design (that's what we're doing right now) and #5114 for the actual
implementation.
> PS: for pretty print I believe a function is better (and less intrusive)
> than to extend an existing method. I'll take the corresponding ticket
> and change the code (and use it to not write whole configs for unit tests
> twice :-).
If it wasn't clear from the meeting, we do not need pretty print right
now. Sure, it would be nice if the JSON returned was nicely indented,
but that is not something that is really needed. We're short on time and
we can't spend time on things that are nice to have, but not necessary.
Even if you write it, nobody would be able to review it. That's sad, but
true. We have very limited manpower right now and we need to be careful,
which tickets we spend time on.
Tomek
------------------------------
Message: 6
Date: Thu, 23 Feb 2017 14:55:11 -0500
From: Thomas Markwalder <[email protected]>
To: Francis Dupont <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Converting configuration back to JSON
(unparsing)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 2/23/17 2:36 PM, Francis Dupont wrote:
> Thomas Markwalder writes:
>> Yes, D2 has an object hierarchy constructed from Elements via
>> SimpleParsers. It is contained in D2CfgContext.
> => fine!
>
>> The class is going to be named ToElement()?
> => CfgToElement but it is an abstract class so classes will derived
> from it.
>
>> Class names should be nouns, typically.
> => boost::noncopyable is a perfect counter-example.
Ok, yes they are also adjectives, which just lends credence to
Configurable for a class name.
My point is that objects that embody our configuration may have other
things in common
eventually besides just implementing a toElement() method.
>> Having it be ToElement::toElement() seems a bit off.
> => the only place you should get it is in a doxygen comment
> (and remember it is an instance method).
>
>> What about something more like Configurable which defines toElement()
>> method.
> => it is more Configured than Configurable but this does not catch
> the fact the derived class must implement a toElement() method.
> So ToElement seems a natural name.
If Configurable::toElement() is an abstract method it would be pretty
clear that anything deriving from it has to implement it. If that's the
criteria you would need a separate base class for every abstract method.
>
> I've just updated fdunparse private branch to these new names.
> And BTW there is no ToElement::toElement found by grep (:-).
>
> Thanks
>
> Francis Dupont <[email protected]>
>
> PS: for pretty print I believe a function is better (and less intrusive)
> than to extend an existing method. I'll take the corresponding ticket
> and change the code (and use it to not write whole configs for unit tests
> twice :-).
------------------------------
Message: 7
Date: Thu, 23 Feb 2017 14:58:31 -0500
From: Thomas Markwalder <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Converting configuration back to JSON
(unparsing)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 2/23/17 2:53 PM, Tomek Mrugalski wrote:
> W dniu 23.02.2017 o 20:36, Francis Dupont pisze:
>>> The class is going to be named ToElement()?
>> => CfgToElement but it is an abstract class so classes will derived
>> from it.
> Huh? I thought toElement will be a method that will be implemented in
> each existing class, so no extra classes needed at all.
>
>>> Having it be ToElement::toElement() seems a bit off.
>> => the only place you should get it is in a doxygen comment
>> (and remember it is an instance method).
> There should be no extra class. There should be CfgMgr::toElement() that
> creates map element, puts all parameters it stores and then call
> toElement() on all of its children (CfgOpionDef::toElement(),
> CfgSubnets4::toElement(), etc.).
That works also.
>>> What about something more like Configurable which defines toElement()
>>> method.
>> => it is more Configured than Configurable but this does not catch
>> the fact the derived class must implement a toElement() method.
>> So ToElement seems a natural name.
>>
>> I've just updated fdunparse private branch to these new names.
>> And BTW there is no ToElement::toElement found by grep (:-).
> That's the problem of implementing code before there's an agreement how
> the code should look like.
>
> When we planned the work, it was decided on a meeting to use 1205 for
> mini-design (that's what we're doing right now) and #5114 for the actual
> implementation.
Good point, coding before design will get you everytime ;)
>> PS: for pretty print I believe a function is better (and less intrusive)
>> than to extend an existing method. I'll take the corresponding ticket
>> and change the code (and use it to not write whole configs for unit tests
>> twice :-).
> If it wasn't clear from the meeting, we do not need pretty print right
> now. Sure, it would be nice if the JSON returned was nicely indented,
> but that is not something that is really needed. We're short on time and
> we can't spend time on things that are nice to have, but not necessary.
> Even if you write it, nobody would be able to review it. That's sad, but
> true. We have very limited manpower right now and we need to be careful,
> which tickets we spend time on.
>
> Tomek
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
Subject: Digest Footer
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
End of kea-dev Digest, Vol 35, Issue 3
**************************************
