[Freeipa-devel] Structured DNS record API proposal

[Jan Cholasta]

On 21.9.2011 23:55, Dmitri Pal wrote:
> On 09/21/2011 10:27 AM, Adam Young wrote:
>> On 09/20/2011 11:11 AM, Martin Kosek wrote:
>>> On Tue, 2011-09-20 at 10:02 -0400, Adam Young wrote:
>>>> This discussion got me thinking, always a dangerous proposal:
>>>>
>>>> We are currently exposing record add with the lie  that  when you add a
>>>> record, it has a type.  THe reality is that a record is just this big
>>>> collection of multi value attributes, and each of those  is the "type"
>>>> of the record.
>>> The way I see it is that we have different types of Resource Records
>>> with a (domain) name that can be shared.
>>>
>>>>
>>>> If all of the 'records'  have the same idnsname, then they really fall
>>>> under the same Record object in LDAP.
>>> Yes.
>>>
>>>> What if we focuses on the attribtutes themselves, and add the type info
>>>> there.
>>> I thought we do this already.
>>>
>>>>
>>>> Pie in the sky proposal.   Treat it as a starting point:
>>>>
>>>>    From the webui perspective
>>>> dnsrecord-add   allows the case where it just has the the idnsname with
>>>> no "records"
>>>>
>>>> dnsrecordattr-mod  takes record type specific values.
>>>>
>>>> To add a location entry:
>>>>
>>>> ipa dnsrecordattr-mod --append location --lat-deg=INT --lat-min=INT
>>>> --lat-sec=FLOAT --lat-dir=ENUM --lon-deg=INT --lon-min=INT
>>>> --lon-sec=FLOAT --lon-dir=ENUM --alt=FLOAT --h-precision=FLOAT
>>>> --v-precision=FLOAT
>>>>
>>>>
>>>> And to remove it
>>>>
>>>> ipa dnsrecordattr-mod --remove location --lat-deg=INT --lat-min=INT
>>>> --lat-sec=FLOAT --lat-dir=ENUM --lon-deg=INT --lon-min=INT
>>>> --lon-sec=FLOAT --lon-dir=ENUM --alt=FLOAT --h-precision=FLOAT
>>>> --v-precision=FLOAT
>>> So if user would want to remove a LOC record, he would have to pass all
>>> these attributes to refer which attribute value to remove?
>> I think that is the case anyway.  Since a DNS record is really just an
>> multivalue attribute,   you would now have to do  a dns-record-mod
>> with the list of all LOC records that you don't want to delete.  I
>> used this as an example because it is the most complex case.
>>
>> Just thinking it through...I'm not certain I like the "one command per
>> record type"  as it changes a lot of other assumptions.  DNS is a
>> wierd beast already.
>>
>> I've spent a lot of time on the DNS ui, and it is pretty tricky  to
>> get right.  I'm trying to balance the PI against efficient usage.
>>
>> What we really need for the fields is a way to specify the format for
>> a given field, much like the format strings used for group names.  For
>> example, the LOC  record  is really
>>
>> <owner>   <TTL>   <class>   LOC d1 [m1 [s1]] {"N"|"S"}  d2 [m2 [s2]]
>> {"E"|"W"}
>>                            alt["m"] [siz["m"]     [hp["m"] [vp["m"]]]]
>>
>>
>> And all the WebUI needs is a way to specify that format  to validate.
>>
>
> Can we use augeas for this?
> Augeas lenses use this kind of the validation and there is python
> binding so may be we should use augeas as an inspiration or ask for an
> augeas Javascript solution?

We can't. Augeas knows how to manipulate config files and only that, 
there is no API for anything else.

>
>>
>>
>> We need a better approach than setattr/add attr, but it should  not be
>> specific to the DNS use case.    Let me frame the problem this way:
>>
>> Extend the IPA plugin API to allow for multivalue attributes, composed
>> of multiple fields, where the fields can have format strings.
>>
>> Solve this design issue, and the DNS design becomes an application of it.
>>
>>
>>
>> _______________________________________________
>> Freeipa-devel mailing list
>> Freeipa-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>
>


-- 
Jan Cholasta