Re: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API
Dne 14.12.2011 07:53, Martin Kosek napsal(a): On Fri, 2011-12-09 at 15:55 -0500, Rob Crittenden wrote: Martin Kosek wrote: On Thu, 2011-12-01 at 17:18 -0500, Rob Crittenden wrote: Martin Kosek wrote: On Mon, 2011-11-28 at 17:35 +0100, Martin Kosek wrote: I have prepared a working prototype of the new structured DNS API. It may still have rough edges (and unit tests are not ready), but it will provide a base for discussion and for WebUI folks - so that they can start development of the new DNS WebUI API. The patch takes advantage of the DNS refactor I did in 172. For all supported non-DNSSEC RR types, the following commands are available: dnsrecordRRTYPE-show ZONE NAME dnsrecordRRTYPE-add ZONE NAME dnsrecordRRTYPE-mod ZONE NAME VALUE This is an example of the new API in action: # ipa dnsrecord-show example.com foo Record name: foo A record: 10.0.0.1 # ipa dnsrecordmx-add example.com foo --exchanger=foo.example.com. MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. Number of entries returned 1 # ipa dnsrecordmx-add example.com foo --preference=1 --exchanger=foo.example.com. MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. MX record: 1 foo.example.com. Preference: 1 Exchanger: foo.example.com. Number of entries returned 2 # ipa dnsrecordmx-show example.com foo MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. MX record: 1 foo.example.com. Preference: 1 Exchanger: foo.example.com. Number of entries returned 2 There is an interactive wizard to help user modify a record without specifying an updated value first. If there is just one (MX) record, no wizard would be run. # ipa dnsrecordmx-mod example.com foo --preference=2 Which MX record would you like to modify? [1]: 0 foo.example.com. [2]: 1 foo.example.com. DNS record number: 2 MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. MX record: 2 foo.example.com. Preference: 2 Exchanger: foo.example.com. Number of entries returned 2 # ipa dnsrecordmx-mod example.com foo 2 foo.example.com. --preference=3 MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. MX record: 3 foo.example.com. Preference: 3 Exchanger: foo.example.com. Number of entries returned 2 There are few open questions I am still thinking about: 1) The commands return a list of structured records (just like *-find commands) instead of returning just one record. I thought that it may be more usable this way and consistent with dnsrecord-add/mod/show commands behavior which returns all records too. Otherwise, we would have to change the show command API and add VALUE argument, which would specify a value to be displayed: dnsrecordRRTYPE-show ZONE NAME VALUE 2) Raw DNS record value is in the output too. I though it would be useful to see the raw DNS record value + its parts at one place. 3) The commands are in format dnsrecordRRTYPE-cmd, for example dnsrecordmx-add. I think dnsrecord-mx-add may be more readable. If we want to go this way, I would have to bend the server framework a little which parses an LDAP object from the command name (LDAP object name is dnsrecordmx in this case). This is doable, although I am not sure if this does not have some implications in WebUI side. Martin I rebased both patches to the most recent master. Adding CSVs now works ok again (with the fix in 175): # ipa dnsrecord-mod example.com foo --a-rec=10.0.0.1,10.0.0.2 Record name: foo A record: 10.0.0.1, 10.0.0.2 Martin Rob, thank you for the review! What do you think about the 3 open questions I posted above? I think some abbreviations can be eliminated: siz - size alt - altitude Sure, this can be fixed. For MX record (and probably KX) you can make preference required. It should fill in without prompting since it has a default. This way it will show as required in the UI. Right, we don't want to run into issues we had with user fields. PTRRecord doc I think would read better as The hostname this reverse record points to Ok. Btw do you think it would be good to document this way all these new DNSRecord part parameters? As I checked with Petr, these would be shown in the UI - so the UI user would benefit from it. But it will require a lot of writing and RFC study :-) I'm not sure I follow the makeapi change. I see the new entry types in API.txt but this makeapi seems to suggest the DNS api is not checked. This fix is in validate_doc(), which tries to check that all our commands have proper __doc__ string. It fails with the
Re: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API
On 12/14/2011 12:53 AM, Martin Kosek wrote:
I found this works ok and adding records is definitely clearer but it
seems odd to add with one command and delete/find with another. I could
get used to it I suppose.
Hm, we could add dnsrecord-rr-del ZONE RECORD VALUE command, but this
would increase the already high number of DNS commands.
As suggested in the meeting, instead of having a separate command for
each type:
dnsrecordsrv-add ZONE NAME [srv-specific parameters...]
dnsrecordmx-add ZONE NAME [mx-specific parameters...]
we could use the same command but we specify the type as a parameter:
dnsrecord-add ZONE NAME --rec-type=srv [srv-specific parameters...]
dnsrecord-add ZONE NAME --rec-type=mx [mx-specific parameters...]
This will keep the number of commands low regardless of the number of
rrtypes we support now or in the future. Same thing for mod and del.
All type-specific options can be made optional, or we can require some
options depending on the type specified. The doc needs to specify which
options are needed for each type.
The interactive mode should still work too based on the type specified.
If the user doesn't specify a type the command can even ask for it.
Endi and Petr had an idea to add a new --structured option for
dnsrecord-find/dnsrecord-show which would show structured DNS records
instead of raw DNS records. But I think our current framework is not
ready for this. While a raw DNS record is basically one entry item
(label : value), structured DNS record is an entry on its own
({label1:value1, label2:value2, ...}):
- dnsrecord-find's output is ListOfEntries, but with use of
--structured option it would have to be changed to something like
ListOfListsOfEntries
- dnsrecord-show's output would have to be changed with a use of
--structured option from Entry to ListOfEntries
I think we're mixing up several alternatives in the discussion. Never
mind about dnsrecordrrtype-find/show returning record data in separate
entries. I don't think right now it will be a good idea since they are
actually attributes (no filter for certain param in the type, no primary
key).
What we're suggesting is the find command should always return a
ListOfEntries and the show command should always return an Entry, which
will be consistent with other commands. So when you call dnsrecord-show
ZONE NAME without --structured, it will return a single Entry like before:
{
idnsname: 'foo',
arecord: [
'10.10.10.10'
],
cnamerecord: [
'bar.example.com.',
'bar2.example.com.'
]
}
But when you specify --structured, it still returns a single Entry 'foo'
but the structure of the attributes will change like this (or like the
one suggested by Petr):
{
idnsname: 'foo',
records: [
{
type: 'a',
data: '10.10.10.10',
ip_address: '10.10.10.10'
},
{
type: 'cname',
data: 'bar.example.com.',
hostname: 'bar.example.com.'
},
{
type: 'cname',
data: 'bar2.example.com.',
hostname: 'bar2.example.com.'
},
]
}
If you call dnsrecord-find ZONE --structured the output will be a
ListOfEntries like before, but each Entry will have a structure like above.
Another problem I see is that different RR types have parts with the
same name (e.g. preference is both in MX, KX and NAPTR records). If
any record could appear in an output entry, we would break current rule
that every output parameter in an entry is uniquely defined. Though this
issue could be solved with a prefix for every structured DNS record
part, i.e. KX record would have kxpreference and kxechanger parts.
Since the 'records' attribute is an array in an Entry, there shouldn't
be any issue about uniqueness.
Also as suggested in my previous email, we can also add a --rec-types
parameter to the find/show command to select which rrtypes we want to
see in the result. If not specified it should return all types.
--
Endi S. Dewata
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API
On 12/14/2011 01:43 PM, Endi Sukma Dewata wrote:
On 12/14/2011 12:53 AM, Martin Kosek wrote:
I found this works ok and adding records is definitely clearer but it
seems odd to add with one command and delete/find with another. I could
get used to it I suppose.
Hm, we could add dnsrecord-rr-del ZONE RECORD VALUE command, but this
would increase the already high number of DNS commands.
As suggested in the meeting, instead of having a separate command for
each type:
dnsrecordsrv-add ZONE NAME [srv-specific parameters...]
dnsrecordmx-add ZONE NAME [mx-specific parameters...]
we could use the same command but we specify the type as a parameter:
dnsrecord-add ZONE NAME --rec-type=srv [srv-specific parameters...]
dnsrecord-add ZONE NAME --rec-type=mx [mx-specific parameters...]
This will keep the number of commands low regardless of the number of
rrtypes we support now or in the future. Same thing for mod and del.
All type-specific options can be made optional, or we can require some
options depending on the type specified. The doc needs to specify
which options are needed for each type.
The interactive mode should still work too based on the type
specified. If the user doesn't specify a type the command can even ask
for it.
Endi and Petr had an idea to add a new --structured option for
dnsrecord-find/dnsrecord-show which would show structured DNS records
instead of raw DNS records. But I think our current framework is not
ready for this. While a raw DNS record is basically one entry item
(label : value), structured DNS record is an entry on its own
({label1:value1, label2:value2, ...}):
- dnsrecord-find's output is ListOfEntries, but with use of
--structured option it would have to be changed to something like
ListOfListsOfEntries
- dnsrecord-show's output would have to be changed with a use of
--structured option from Entry to ListOfEntries
I think we're mixing up several alternatives in the discussion. Never
mind about dnsrecordrrtype-find/show returning record data in
separate entries. I don't think right now it will be a good idea since
they are actually attributes (no filter for certain param in the type,
no primary key).
What we're suggesting is the find command should always return a
ListOfEntries and the show command should always return an Entry,
which will be consistent with other commands. So when you call
dnsrecord-show ZONE NAME without --structured, it will return a single
Entry like before:
{
idnsname: 'foo',
arecord: [
'10.10.10.10'
],
cnamerecord: [
'bar.example.com.',
'bar2.example.com.'
]
}
But when you specify --structured, it still returns a single Entry
'foo' but the structure of the attributes will change like this (or
like the one suggested by Petr):
{
idnsname: 'foo',
records: [
{
type: 'a',
data: '10.10.10.10',
ip_address: '10.10.10.10'
},
{
type: 'cname',
data: 'bar.example.com.',
hostname: 'bar.example.com.'
},
{
type: 'cname',
data: 'bar2.example.com.',
hostname: 'bar2.example.com.'
},
]
}
If you call dnsrecord-find ZONE --structured the output will be a
ListOfEntries like before, but each Entry will have a structure like
above.
Another problem I see is that different RR types have parts with the
same name (e.g. preference is both in MX, KX and NAPTR records). If
any record could appear in an output entry, we would break current rule
that every output parameter in an entry is uniquely defined. Though this
issue could be solved with a prefix for every structured DNS record
part, i.e. KX record would have kxpreference and kxechanger parts.
Since the 'records' attribute is an array in an Entry, there shouldn't
be any issue about uniqueness.
Also as suggested in my previous email, we can also add a --rec-types
parameter to the find/show command to select which rrtypes we want to
see in the result. If not specified it should return all types.
But as Martin mentioned on the call we loose help capabilities and make
things really more complex.
My vote would be to have separate commands. IMO it is better from
usability point of view.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API
- Original Message -
On 12/14/2011 01:43 PM, Endi Sukma Dewata wrote:
On 12/14/2011 12:53 AM, Martin Kosek wrote:
I found this works ok and adding records is definitely clearer
but it
seems odd to add with one command and delete/find with another. I
could
get used to it I suppose.
Hm, we could add dnsrecord-rr-del ZONE RECORD VALUE command, but
this
would increase the already high number of DNS commands.
As suggested in the meeting, instead of having a separate command
for
each type:
dnsrecordsrv-add ZONE NAME [srv-specific parameters...]
dnsrecordmx-add ZONE NAME [mx-specific parameters...]
we could use the same command but we specify the type as a
parameter:
dnsrecord-add ZONE NAME --rec-type=srv [srv-specific
parameters...]
dnsrecord-add ZONE NAME --rec-type=mx [mx-specific parameters...]
This will keep the number of commands low regardless of the number
of
rrtypes we support now or in the future. Same thing for mod and
del.
All type-specific options can be made optional, or we can require
some
options depending on the type specified. The doc needs to specify
which options are needed for each type.
The interactive mode should still work too based on the type
specified. If the user doesn't specify a type the command can even
ask
for it.
Endi and Petr had an idea to add a new --structured option for
dnsrecord-find/dnsrecord-show which would show structured DNS
records
instead of raw DNS records. But I think our current framework is
not
ready for this. While a raw DNS record is basically one entry item
(label : value), structured DNS record is an entry on its own
({label1:value1, label2:value2, ...}):
- dnsrecord-find's output is ListOfEntries, but with use of
--structured option it would have to be changed to something like
ListOfListsOfEntries
- dnsrecord-show's output would have to be changed with a use of
--structured option from Entry to ListOfEntries
I think we're mixing up several alternatives in the discussion.
Never
mind about dnsrecordrrtype-find/show returning record data in
separate entries. I don't think right now it will be a good idea
since
they are actually attributes (no filter for certain param in the
type,
no primary key).
What we're suggesting is the find command should always return a
ListOfEntries and the show command should always return an Entry,
which will be consistent with other commands. So when you call
dnsrecord-show ZONE NAME without --structured, it will return a
single
Entry like before:
{
idnsname: 'foo',
arecord: [
'10.10.10.10'
],
cnamerecord: [
'bar.example.com.',
'bar2.example.com.'
]
}
But when you specify --structured, it still returns a single Entry
'foo' but the structure of the attributes will change like this (or
like the one suggested by Petr):
{
idnsname: 'foo',
records: [
{
type: 'a',
data: '10.10.10.10',
ip_address: '10.10.10.10'
},
{
type: 'cname',
data: 'bar.example.com.',
hostname: 'bar.example.com.'
},
{
type: 'cname',
data: 'bar2.example.com.',
hostname: 'bar2.example.com.'
},
]
}
If you call dnsrecord-find ZONE --structured the output will be a
ListOfEntries like before, but each Entry will have a structure
like
above.
Another problem I see is that different RR types have parts with
the
same name (e.g. preference is both in MX, KX and NAPTR records).
If
any record could appear in an output entry, we would break current
rule
that every output parameter in an entry is uniquely defined.
Though this
issue could be solved with a prefix for every structured DNS
record
part, i.e. KX record would have kxpreference and kxechanger
parts.
Since the 'records' attribute is an array in an Entry, there
shouldn't
be any issue about uniqueness.
Also as suggested in my previous email, we can also add a
--rec-types
parameter to the find/show command to select which rrtypes we want
to
see in the result. If not specified it should return all types.
But as Martin mentioned on the call we loose help capabilities and
make
things really more complex.
My vote would be to have separate commands. IMO it is better from
usability point of view.
I disagree, it will make things a lot more cumbersome and will require
entire new commands if we want to add new types in future. It does not
scale well and it is potentially open bounded.
For the help issue I am sure we can figure out a way to pass --rec-type
to help if really needed, otherwise help can simply list all know syntaxes.
Simo.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
Re: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API
On 12/14/2011 03:02 PM, Simo Sorce wrote:
- Original Message -
On 12/14/2011 01:43 PM, Endi Sukma Dewata wrote:
On 12/14/2011 12:53 AM, Martin Kosek wrote:
I found this works ok and adding records is definitely clearer
but it
seems odd to add with one command and delete/find with another. I
could
get used to it I suppose.
Hm, we could add dnsrecord-rr-del ZONE RECORD VALUE command, but
this
would increase the already high number of DNS commands.
As suggested in the meeting, instead of having a separate command
for
each type:
dnsrecordsrv-add ZONE NAME [srv-specific parameters...]
dnsrecordmx-add ZONE NAME [mx-specific parameters...]
we could use the same command but we specify the type as a
parameter:
dnsrecord-add ZONE NAME --rec-type=srv [srv-specific
parameters...]
dnsrecord-add ZONE NAME --rec-type=mx [mx-specific parameters...]
This will keep the number of commands low regardless of the number
of
rrtypes we support now or in the future. Same thing for mod and
del.
All type-specific options can be made optional, or we can require
some
options depending on the type specified. The doc needs to specify
which options are needed for each type.
The interactive mode should still work too based on the type
specified. If the user doesn't specify a type the command can even
ask
for it.
Endi and Petr had an idea to add a new --structured option for
dnsrecord-find/dnsrecord-show which would show structured DNS
records
instead of raw DNS records. But I think our current framework is
not
ready for this. While a raw DNS record is basically one entry item
(label : value), structured DNS record is an entry on its own
({label1:value1, label2:value2, ...}):
- dnsrecord-find's output is ListOfEntries, but with use of
--structured option it would have to be changed to something like
ListOfListsOfEntries
- dnsrecord-show's output would have to be changed with a use of
--structured option from Entry to ListOfEntries
I think we're mixing up several alternatives in the discussion.
Never
mind about dnsrecordrrtype-find/show returning record data in
separate entries. I don't think right now it will be a good idea
since
they are actually attributes (no filter for certain param in the
type,
no primary key).
What we're suggesting is the find command should always return a
ListOfEntries and the show command should always return an Entry,
which will be consistent with other commands. So when you call
dnsrecord-show ZONE NAME without --structured, it will return a
single
Entry like before:
{
idnsname: 'foo',
arecord: [
'10.10.10.10'
],
cnamerecord: [
'bar.example.com.',
'bar2.example.com.'
]
}
But when you specify --structured, it still returns a single Entry
'foo' but the structure of the attributes will change like this (or
like the one suggested by Petr):
{
idnsname: 'foo',
records: [
{
type: 'a',
data: '10.10.10.10',
ip_address: '10.10.10.10'
},
{
type: 'cname',
data: 'bar.example.com.',
hostname: 'bar.example.com.'
},
{
type: 'cname',
data: 'bar2.example.com.',
hostname: 'bar2.example.com.'
},
]
}
If you call dnsrecord-find ZONE --structured the output will be a
ListOfEntries like before, but each Entry will have a structure
like
above.
Another problem I see is that different RR types have parts with
the
same name (e.g. preference is both in MX, KX and NAPTR records).
If
any record could appear in an output entry, we would break current
rule
that every output parameter in an entry is uniquely defined.
Though this
issue could be solved with a prefix for every structured DNS
record
part, i.e. KX record would have kxpreference and kxechanger
parts.
Since the 'records' attribute is an array in an Entry, there
shouldn't
be any issue about uniqueness.
Also as suggested in my previous email, we can also add a
--rec-types
parameter to the find/show command to select which rrtypes we want
to
see in the result. If not specified it should return all types.
But as Martin mentioned on the call we loose help capabilities and
make
things really more complex.
My vote would be to have separate commands. IMO it is better from
usability point of view.
I disagree, it will make things a lot more cumbersome and will require
entire new commands if we want to add new types in future. It does not
scale well and it is potentially open bounded.
For the help issue I am sure we can figure out a way to pass --rec-type
to help if really needed, otherwise help can simply list all know syntaxes.
The whole point of this work to decompose things and make them simpler.
One command with dozens of options is much harder to use.
I stand on my own point but we should ask community.
Simo.
Re: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API
On Wed, 2011-12-14 at 12:43 -0600, Endi Sukma Dewata wrote:
On 12/14/2011 12:53 AM, Martin Kosek wrote:
I found this works ok and adding records is definitely clearer but it
seems odd to add with one command and delete/find with another. I could
get used to it I suppose.
Hm, we could add dnsrecord-rr-del ZONE RECORD VALUE command, but this
would increase the already high number of DNS commands.
As suggested in the meeting, instead of having a separate command for
each type:
dnsrecordsrv-add ZONE NAME [srv-specific parameters...]
dnsrecordmx-add ZONE NAME [mx-specific parameters...]
we could use the same command but we specify the type as a parameter:
dnsrecord-add ZONE NAME --rec-type=srv [srv-specific parameters...]
dnsrecord-add ZONE NAME --rec-type=mx [mx-specific parameters...]
This will keep the number of commands low regardless of the number of
rrtypes we support now or in the future. Same thing for mod and del.
All type-specific options can be made optional, or we can require some
options depending on the type specified. The doc needs to specify which
options are needed for each type.
The interactive mode should still work too based on the type specified.
If the user doesn't specify a type the command can even ask for it.
Endi and Petr had an idea to add a new --structured option for
dnsrecord-find/dnsrecord-show which would show structured DNS records
instead of raw DNS records. But I think our current framework is not
ready for this. While a raw DNS record is basically one entry item
(label : value), structured DNS record is an entry on its own
({label1:value1, label2:value2, ...}):
- dnsrecord-find's output is ListOfEntries, but with use of
--structured option it would have to be changed to something like
ListOfListsOfEntries
- dnsrecord-show's output would have to be changed with a use of
--structured option from Entry to ListOfEntries
I think we're mixing up several alternatives in the discussion. Never
mind about dnsrecordrrtype-find/show returning record data in separate
entries. I don't think right now it will be a good idea since they are
actually attributes (no filter for certain param in the type, no primary
key).
What we're suggesting is the find command should always return a
ListOfEntries and the show command should always return an Entry, which
will be consistent with other commands. So when you call dnsrecord-show
ZONE NAME without --structured, it will return a single Entry like before:
{
idnsname: 'foo',
arecord: [
'10.10.10.10'
],
cnamerecord: [
'bar.example.com.',
'bar2.example.com.'
]
}
But when you specify --structured, it still returns a single Entry 'foo'
but the structure of the attributes will change like this (or like the
one suggested by Petr):
{
idnsname: 'foo',
records: [
{
type: 'a',
data: '10.10.10.10',
ip_address: '10.10.10.10'
},
{
type: 'cname',
data: 'bar.example.com.',
hostname: 'bar.example.com.'
},
{
type: 'cname',
data: 'bar2.example.com.',
hostname: 'bar2.example.com.'
},
]
}
If you call dnsrecord-find ZONE --structured the output will be a
ListOfEntries like before, but each Entry will have a structure like above.
Another problem I see is that different RR types have parts with the
same name (e.g. preference is both in MX, KX and NAPTR records). If
any record could appear in an output entry, we would break current rule
that every output parameter in an entry is uniquely defined. Though this
issue could be solved with a prefix for every structured DNS record
part, i.e. KX record would have kxpreference and kxechanger parts.
Since the 'records' attribute is an array in an Entry, there shouldn't
be any issue about uniqueness.
Also as suggested in my previous email, we can also add a --rec-types
parameter to the find/show command to select which rrtypes we want to
see in the result. If not specified it should return all types.
I think this all are valid points, I will summarize the proposad
approach to DNS API based on options instead of commands to separate
mail. It is too important to get lost in this long thread :-)
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API
On Wed, 2011-12-14 at 15:31 -0500, Dmitri Pal wrote: The whole point of this work to decompose things and make them simpler. One command with dozens of options is much harder to use. I stand on my own point but we should ask community. Lets see what the community would say about the API based on new options instead of new commands. I proposed an API based on the discussion with Rob and Endi in a new thread sent both to freeipa-devel and freeipa-users. This new way would require more changes to our framework which is not ready for such interface yet but if the interface is accepted it should be doable. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API
Martin Kosek wrote: On Thu, 2011-12-01 at 17:18 -0500, Rob Crittenden wrote: Martin Kosek wrote: On Mon, 2011-11-28 at 17:35 +0100, Martin Kosek wrote: I have prepared a working prototype of the new structured DNS API. It may still have rough edges (and unit tests are not ready), but it will provide a base for discussion and for WebUI folks - so that they can start development of the new DNS WebUI API. The patch takes advantage of the DNS refactor I did in 172. For all supported non-DNSSEC RR types, the following commands are available: dnsrecordRRTYPE-show ZONE NAME dnsrecordRRTYPE-add ZONE NAME dnsrecordRRTYPE-mod ZONE NAME VALUE This is an example of the new API in action: # ipa dnsrecord-show example.com foo Record name: foo A record: 10.0.0.1 # ipa dnsrecordmx-add example.com foo --exchanger=foo.example.com. MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. Number of entries returned 1 # ipa dnsrecordmx-add example.com foo --preference=1 --exchanger=foo.example.com. MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. MX record: 1 foo.example.com. Preference: 1 Exchanger: foo.example.com. Number of entries returned 2 # ipa dnsrecordmx-show example.com foo MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. MX record: 1 foo.example.com. Preference: 1 Exchanger: foo.example.com. Number of entries returned 2 There is an interactive wizard to help user modify a record without specifying an updated value first. If there is just one (MX) record, no wizard would be run. # ipa dnsrecordmx-mod example.com foo --preference=2 Which MX record would you like to modify? [1]: 0 foo.example.com. [2]: 1 foo.example.com. DNS record number: 2 MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. MX record: 2 foo.example.com. Preference: 2 Exchanger: foo.example.com. Number of entries returned 2 # ipa dnsrecordmx-mod example.com foo 2 foo.example.com. --preference=3 MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. MX record: 3 foo.example.com. Preference: 3 Exchanger: foo.example.com. Number of entries returned 2 There are few open questions I am still thinking about: 1) The commands return a list of structured records (just like *-find commands) instead of returning just one record. I thought that it may be more usable this way and consistent with dnsrecord-add/mod/show commands behavior which returns all records too. Otherwise, we would have to change the show command API and add VALUE argument, which would specify a value to be displayed: dnsrecordRRTYPE-show ZONE NAME VALUE 2) Raw DNS record value is in the output too. I though it would be useful to see the raw DNS record value + its parts at one place. 3) The commands are in format dnsrecordRRTYPE-cmd, for example dnsrecordmx-add. I think dnsrecord-mx-add may be more readable. If we want to go this way, I would have to bend the server framework a little which parses an LDAP object from the command name (LDAP object name is dnsrecordmx in this case). This is doable, although I am not sure if this does not have some implications in WebUI side. Martin I rebased both patches to the most recent master. Adding CSVs now works ok again (with the fix in 175): # ipa dnsrecord-mod example.com foo --a-rec=10.0.0.1,10.0.0.2 Record name: foo A record: 10.0.0.1, 10.0.0.2 Martin Rob, thank you for the review! What do you think about the 3 open questions I posted above? I think some abbreviations can be eliminated: siz - size alt - altitude Sure, this can be fixed. For MX record (and probably KX) you can make preference required. It should fill in without prompting since it has a default. This way it will show as required in the UI. Right, we don't want to run into issues we had with user fields. PTRRecord doc I think would read better as The hostname this reverse record points to Ok. Btw do you think it would be good to document this way all these new DNSRecord part parameters? As I checked with Petr, these would be shown in the UI - so the UI user would benefit from it. But it will require a lot of writing and RFC study :-) I'm not sure I follow the makeapi change. I see the new entry types in API.txt but this makeapi seems to suggest the DNS api is not checked. This fix is in validate_doc(), which tries to check that all our commands have proper __doc__ string. It fails with the new DNS API commands (dnsrecordmx-add etc.) because it cannot find class definitions in dns.py. This is expected as I generate all these
Re: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API
On Thu, 2011-12-01 at 17:18 -0500, Rob Crittenden wrote: Martin Kosek wrote: On Mon, 2011-11-28 at 17:35 +0100, Martin Kosek wrote: I have prepared a working prototype of the new structured DNS API. It may still have rough edges (and unit tests are not ready), but it will provide a base for discussion and for WebUI folks - so that they can start development of the new DNS WebUI API. The patch takes advantage of the DNS refactor I did in 172. For all supported non-DNSSEC RR types, the following commands are available: dnsrecordRRTYPE-show ZONE NAME dnsrecordRRTYPE-add ZONE NAME dnsrecordRRTYPE-mod ZONE NAME VALUE This is an example of the new API in action: # ipa dnsrecord-show example.com foo Record name: foo A record: 10.0.0.1 # ipa dnsrecordmx-add example.com foo --exchanger=foo.example.com. MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. Number of entries returned 1 # ipa dnsrecordmx-add example.com foo --preference=1 --exchanger=foo.example.com. MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. MX record: 1 foo.example.com. Preference: 1 Exchanger: foo.example.com. Number of entries returned 2 # ipa dnsrecordmx-show example.com foo MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. MX record: 1 foo.example.com. Preference: 1 Exchanger: foo.example.com. Number of entries returned 2 There is an interactive wizard to help user modify a record without specifying an updated value first. If there is just one (MX) record, no wizard would be run. # ipa dnsrecordmx-mod example.com foo --preference=2 Which MX record would you like to modify? [1]: 0 foo.example.com. [2]: 1 foo.example.com. DNS record number: 2 MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. MX record: 2 foo.example.com. Preference: 2 Exchanger: foo.example.com. Number of entries returned 2 # ipa dnsrecordmx-mod example.com foo 2 foo.example.com. --preference=3 MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. MX record: 3 foo.example.com. Preference: 3 Exchanger: foo.example.com. Number of entries returned 2 There are few open questions I am still thinking about: 1) The commands return a list of structured records (just like *-find commands) instead of returning just one record. I thought that it may be more usable this way and consistent with dnsrecord-add/mod/show commands behavior which returns all records too. Otherwise, we would have to change the show command API and add VALUE argument, which would specify a value to be displayed: dnsrecordRRTYPE-show ZONE NAME VALUE 2) Raw DNS record value is in the output too. I though it would be useful to see the raw DNS record value + its parts at one place. 3) The commands are in format dnsrecordRRTYPE-cmd, for example dnsrecordmx-add. I think dnsrecord-mx-add may be more readable. If we want to go this way, I would have to bend the server framework a little which parses an LDAP object from the command name (LDAP object name is dnsrecordmx in this case). This is doable, although I am not sure if this does not have some implications in WebUI side. Martin I rebased both patches to the most recent master. Adding CSVs now works ok again (with the fix in 175): # ipa dnsrecord-mod example.com foo --a-rec=10.0.0.1,10.0.0.2 Record name: foo A record: 10.0.0.1, 10.0.0.2 Martin Rob, thank you for the review! What do you think about the 3 open questions I posted above? I think some abbreviations can be eliminated: siz - size alt - altitude Sure, this can be fixed. For MX record (and probably KX) you can make preference required. It should fill in without prompting since it has a default. This way it will show as required in the UI. Right, we don't want to run into issues we had with user fields. PTRRecord doc I think would read better as The hostname this reverse record points to Ok. Btw do you think it would be good to document this way all these new DNSRecord part parameters? As I checked with Petr, these would be shown in the UI - so the UI user would benefit from it. But it will require a lot of writing and RFC study :-) I'm not sure I follow the makeapi change. I see the new entry types in API.txt but this makeapi seems to suggest the DNS api is not checked. This fix is in validate_doc(), which tries to check that all our commands have proper __doc__
Re: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API
Martin Kosek wrote: On Thu, 2011-12-01 at 17:18 -0500, Rob Crittenden wrote: Martin Kosek wrote: On Mon, 2011-11-28 at 17:35 +0100, Martin Kosek wrote: I have prepared a working prototype of the new structured DNS API. It may still have rough edges (and unit tests are not ready), but it will provide a base for discussion and for WebUI folks - so that they can start development of the new DNS WebUI API. The patch takes advantage of the DNS refactor I did in 172. For all supported non-DNSSEC RR types, the following commands are available: dnsrecordRRTYPE-show ZONE NAME dnsrecordRRTYPE-add ZONE NAME dnsrecordRRTYPE-mod ZONE NAME VALUE This is an example of the new API in action: # ipa dnsrecord-show example.com foo Record name: foo A record: 10.0.0.1 # ipa dnsrecordmx-add example.com foo --exchanger=foo.example.com. MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. Number of entries returned 1 # ipa dnsrecordmx-add example.com foo --preference=1 --exchanger=foo.example.com. MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. MX record: 1 foo.example.com. Preference: 1 Exchanger: foo.example.com. Number of entries returned 2 # ipa dnsrecordmx-show example.com foo MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. MX record: 1 foo.example.com. Preference: 1 Exchanger: foo.example.com. Number of entries returned 2 There is an interactive wizard to help user modify a record without specifying an updated value first. If there is just one (MX) record, no wizard would be run. # ipa dnsrecordmx-mod example.com foo --preference=2 Which MX record would you like to modify? [1]: 0 foo.example.com. [2]: 1 foo.example.com. DNS record number: 2 MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. MX record: 2 foo.example.com. Preference: 2 Exchanger: foo.example.com. Number of entries returned 2 # ipa dnsrecordmx-mod example.com foo 2 foo.example.com. --preference=3 MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. MX record: 3 foo.example.com. Preference: 3 Exchanger: foo.example.com. Number of entries returned 2 There are few open questions I am still thinking about: 1) The commands return a list of structured records (just like *-find commands) instead of returning just one record. I thought that it may be more usable this way and consistent with dnsrecord-add/mod/show commands behavior which returns all records too. Otherwise, we would have to change the show command API and add VALUE argument, which would specify a value to be displayed: dnsrecordRRTYPE-show ZONE NAME VALUE 2) Raw DNS record value is in the output too. I though it would be useful to see the raw DNS record value + its parts at one place. 3) The commands are in format dnsrecordRRTYPE-cmd, for example dnsrecordmx-add. I think dnsrecord-mx-add may be more readable. If we want to go this way, I would have to bend the server framework a little which parses an LDAP object from the command name (LDAP object name is dnsrecordmx in this case). This is doable, although I am not sure if this does not have some implications in WebUI side. Martin I rebased both patches to the most recent master. Adding CSVs now works ok again (with the fix in 175): # ipa dnsrecord-mod example.com foo --a-rec=10.0.0.1,10.0.0.2 Record name: foo A record: 10.0.0.1, 10.0.0.2 Martin Rob, thank you for the review! What do you think about the 3 open questions I posted above? I haven't applied the patches to see what the output looks like yet so can't really comment on the first two. I think the extra dash would make the command line easier to grok, or at least read, but it isn't a show stopper for me. I'd be interested in feedback from the UI guys but they may have to start poking at it to really know for sure how much of an issue it would be. I think some abbreviations can be eliminated: siz - size alt - altitude Sure, this can be fixed. For MX record (and probably KX) you can make preference required. It should fill in without prompting since it has a default. This way it will show as required in the UI. Right, we don't want to run into issues we had with user fields. PTRRecord doc I think would read better as The hostname this reverse record points to Ok. Btw do you think it would be good to document this way all these new DNSRecord part parameters? As I checked with Petr, these would be shown in the UI - so the UI user would benefit from it. But it will require a lot of writing and RFC study :-) I was wondering
Re: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API
On 12/02/2011 03:33 PM, Rob Crittenden wrote: Martin Kosek wrote: On Thu, 2011-12-01 at 17:18 -0500, Rob Crittenden wrote: Martin Kosek wrote: On Mon, 2011-11-28 at 17:35 +0100, Martin Kosek wrote: 3) The commands are in format dnsrecordRRTYPE-cmd, for example dnsrecordmx-add. I think dnsrecord-mx-add may be more readable. If we want to go this way, I would have to bend the server framework a little which parses an LDAP object from the command name (LDAP object name is dnsrecordmx in this case). This is doable, although I am not sure if this does not have some implications in WebUI side. Martin Rob, thank you for the review! What do you think about the 3 open questions I posted above? I haven't applied the patches to see what the output looks like yet so can't really comment on the first two. I think the extra dash would make the command line easier to grok, or at least read, but it isn't a show stopper for me. I'd be interested in feedback from the UI guys but they may have to start poking at it to really know for sure how much of an issue it would be. For UI it is better without the dash. With dash it breaks the entity-method naming, which is default behavior for creating commands to the server. But it is quite easy to implement it with the dash too. If it makes the CLI more usable we should add the dash - it may save users more time. PTRRecord doc I think would read better as The hostname this reverse record points to Ok. Btw do you think it would be good to document this way all these new DNSRecord part parameters? As I checked with Petr, these would be shown in the UI - so the UI user would benefit from it. But it will require a lot of writing and RFC study :-) I was wondering that myself. The labels can be rather terse, I wasn't sure how much more a _doc() would add. I was also wondering if we should include some of the limits within the doc, esp the 0-64k ones since those are smaller. It would make it somewhat inconsistent which is why I didn't raise it. The label for attributes is very useful, without it we would have to add the label into internal.py which would only complicate things. The doc can be the same as the label as it is now for many attributes. Anyway special doc is useful if something is not clear. Martin rob -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API
Martin Kosek wrote: On Mon, 2011-11-28 at 17:35 +0100, Martin Kosek wrote: I have prepared a working prototype of the new structured DNS API. It may still have rough edges (and unit tests are not ready), but it will provide a base for discussion and for WebUI folks - so that they can start development of the new DNS WebUI API. The patch takes advantage of the DNS refactor I did in 172. For all supported non-DNSSEC RR types, the following commands are available: dnsrecordRRTYPE-show ZONE NAME dnsrecordRRTYPE-add ZONE NAME dnsrecordRRTYPE-mod ZONE NAME VALUE This is an example of the new API in action: # ipa dnsrecord-show example.com foo Record name: foo A record: 10.0.0.1 # ipa dnsrecordmx-add example.com foo --exchanger=foo.example.com. MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. Number of entries returned 1 # ipa dnsrecordmx-add example.com foo --preference=1 --exchanger=foo.example.com. MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. MX record: 1 foo.example.com. Preference: 1 Exchanger: foo.example.com. Number of entries returned 2 # ipa dnsrecordmx-show example.com foo MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. MX record: 1 foo.example.com. Preference: 1 Exchanger: foo.example.com. Number of entries returned 2 There is an interactive wizard to help user modify a record without specifying an updated value first. If there is just one (MX) record, no wizard would be run. # ipa dnsrecordmx-mod example.com foo --preference=2 Which MX record would you like to modify? [1]: 0 foo.example.com. [2]: 1 foo.example.com. DNS record number: 2 MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. MX record: 2 foo.example.com. Preference: 2 Exchanger: foo.example.com. Number of entries returned 2 # ipa dnsrecordmx-mod example.com foo 2 foo.example.com. --preference=3 MX record: 0 foo.example.com. Preference: 0 Exchanger: foo.example.com. MX record: 3 foo.example.com. Preference: 3 Exchanger: foo.example.com. Number of entries returned 2 There are few open questions I am still thinking about: 1) The commands return a list of structured records (just like *-find commands) instead of returning just one record. I thought that it may be more usable this way and consistent with dnsrecord-add/mod/show commands behavior which returns all records too. Otherwise, we would have to change the show command API and add VALUE argument, which would specify a value to be displayed: dnsrecordRRTYPE-show ZONE NAME VALUE 2) Raw DNS record value is in the output too. I though it would be useful to see the raw DNS record value + its parts at one place. 3) The commands are in format dnsrecordRRTYPE-cmd, for example dnsrecordmx-add. I think dnsrecord-mx-add may be more readable. If we want to go this way, I would have to bend the server framework a little which parses an LDAP object from the command name (LDAP object name is dnsrecordmx in this case). This is doable, although I am not sure if this does not have some implications in WebUI side. Martin I rebased both patches to the most recent master. Adding CSVs now works ok again (with the fix in 175): # ipa dnsrecord-mod example.com foo --a-rec=10.0.0.1,10.0.0.2 Record name: foo A record: 10.0.0.1, 10.0.0.2 Martin I think some abbreviations can be eliminated: siz - size alt - altitude For MX record (and probably KX) you can make preference required. It should fill in without prompting since it has a default. This way it will show as required in the UI. PTRRecord doc I think would read better as The hostname this reverse record points to I'm not sure I follow the makeapi change. I see the new entry types in API.txt but this makeapi seems to suggest the DNS api is not checked. Otherwise generally looks good. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
