<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 22, 2016 at 4:14 PM, Tomek Mrugalski <span dir="ltr"><<a href="mailto:tomasz@isc.org" target="_blank">tomasz@isc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">W dniu 22.08.2016 o 07:08, phirince philip pisze:<br>
<span class="">> I've been experimenting with the KEA code to develop an API similar<br>
> to OMAPI of ISC dhcpd. I require that feature to write a plugin for<br>
> the foreman smart-proxy (<a href="https://github.com/theforeman/smart-proxy" rel="noreferrer" target="_blank">https://github.com/<wbr>theforeman/smart-proxy</a><br>
</span>> <<a href="https://github.com/theforeman/smart-proxy" rel="noreferrer" target="_blank">https://github.com/<wbr>theforeman/smart-proxy</a>>). So far, my<br>
<span class="">> experimentation has been using the hooks api of KEA. I used the<br>
> load() entry point to register a control channel command "get-host"<br>
> which then queries for the host reservation using HostMgr instance. I<br>
> also want to work on a "add-host" command which will help in adding<br>
> host reservations dynamically to the alternate source.<br>
</span>Seems like an awesome project!<br>
<br>
Although so far we haven't made any explicit provisions for the hook<br>
libs to register their own commands, what you did seems like the best<br>
way to go.<br>
<span class=""><br>
> But before investing too much time, I just wanted to check a couple<br>
> of things with you guys.<br>
<br>
> 1. Is anybody already working on these features?<br>
</span>We're planning to. So far we made the first step, which is to write<br>
requirements. Have you seen it?<br>
<br>
<a href="http://kea.isc.org/wiki/ControlAPIRequirements" rel="noreferrer" target="_blank">http://kea.isc.org/wiki/<wbr>ControlAPIRequirements</a></blockquote><div><br></div><div>Ah, I didn't see that. That's really useful and detailed. Thanks. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
We hope to start internal discussion (in 2 weeks maybe?) about the scope<br>
for Kea 1.2, which will be our next release after 1.1 goes out. We<br>
haven't made any decisions yet, but it seems likely that we'll pick<br>
major parts of the API and will start implementing it when 1.2 milestone<br>
starts.<br></blockquote><div><br></div><div>Cool. So should I stop the development work for now? Will I be able to contribute? This will solve a huge pain point for my company and I'm eager to get this implemented.</div><div><br></div><div>How does it work?  Do you open tickets and assign it among yourself? Or will I be able to pick up tickets which are more important to us?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> 2. Do you think it will be a good idea to incorporate these into the<br>
> codebase instead of writing it as a hook?<br>
</span>Yes. This is somewhat trickier than it looks at the first glance,<br>
though. Make sure you read the Contributor's Guide (<a href="http://kea.isc.org" rel="noreferrer" target="_blank">kea.isc.org</a> -><br>
Developer's Guide -> Contributor's Guide, or use the direct link:<br>
<a href="http://git.kea.isc.org/~tester/kea/doxygen/d7/df4/contributorGuide.html" rel="noreferrer" target="_blank">http://git.kea.isc.org/~<wbr>tester/kea/doxygen/d7/df4/<wbr>contributorGuide.html</a>)<br>
<br>
In particular, we will not be able to merge a patch that comes without<br>
unit-tests. If we receive a patch that looks good, but does not have<br>
unit-tests, we will have to write them on our own, but that may take a<br>
lot of time until we get around to it.<br></blockquote><div><br></div><div>I understand. I'm a big fan of TDD myself. I'll make sure I submit unit tests along with code.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Since we have requirements for the feature you'd like to develop, make<br>
sure your code adheres to it.<br>
<span class=""><br>
> 3. Any other feedback/suggestions/tips for me?<br>
</span>Sure. If you could go over the requirements document and tell which of<br>
those calls are important, which are nice to have and which not<br>
interesting for you would be a great feedback. If you have any other<br>
comments or proposals for calls that we have missed, I'd love to hear<br>
about that, too.<br></blockquote><div><br></div><div>I think you have already covered much more than I expected. </div><div>But the most important calls to me would be "add-reservation", "delete-reservation" and "get-reservation". "update-reservation" would be useful, but not absolutely required.</div><div><br></div><div>Thanks,</div><div>-PP </div></div><br></div></div>