Adam Young wrote: > On 09/10/2010 10:24 AM, Rob Crittenden wrote: >> Dmitri Pal wrote: >>> Adam Young wrote: >>>> Both Automount and DNS are heirarchical entities. >>>> >>>> >>>> DNS starts with a zone. Usually, a zone is a domain name, like >>>> redhat.com. It might be more specific, like devel.redhat.com. >>>> >>>> A DNS setup is going to have at a minimum one zone, and is likely to >>>> only have a single zone. >>>> >>>> A Zone is pretty much just a name, and then a collection of records. >>>> The records are owned by the zone. THere will be very little or no >>>> crossover between zones. Thus, I'm thinking that the most common >>>> thing people are going to want to do is to manage the records for a >>>> single zone. >>>> >>>> >>>> So the question becomes, one tab or two? If we go two, we have DNS >>>> zones and DNS records, with an association facet on the zone that >>>> points to the record. The difference that doesn't map to existing use >>>> cases is that a given record is always associated with a zone, so >>>> creating a records, and then later associating it with a zone does not >>>> make sense. >>>> >>>> We could put a UI element like the finder on the associations page on >>>> the record page. So to create a record, one of the steps you'd do >>>> would be to run a zone search. This seems awkward. >>>> >>>> I'm thinking instead that we should have a single DNS tab. If we have >>>> a single zone, this tab defaults to the finder page for records for >>>> that zone. Clicking add creates a new record form, with the zone >>>> hardcoded already to be the default one. >>>> >>>> In the case where there are more than one zone, the default facet is >>>> the zone search. I suspect that this search should be automatically >>>> executed with a blank filter upon load so that the set of zones is >>>> available. Selecting a zone then goes to the finder page for the >>>> records , again, with the search pre-executed, and the name of the >>>> zone hyperlinked at the top. >>>> >>>> >>>> This approach also works with automounts. The default case for >>>> automounts is a single location. There are two entities beyond >>>> location to manage: maps and keys. These two are hierarchical: >>>> location owns map, map owns key. >>>> >>>> For this entity, I think the default page should be the search page >>>> for maps, with a search that specifies the default location. Each map >>>> entry has a hyperlink to its keys page, again a search pre-executed. >>>> >>>> Once multiple locations are defined, the default page for automount >>>> should be the location search page, pre-executed. >>>> >>>> >>>> Here is the criticisms I've thought of so far. It requires multiple >>>> calls to the server to determine what to display. The second is that >>>> it is more complicated, and will take somewhat more time to >>>> implement. The user will not expect the content of a tab to change >>>> out from under them. >>>> >>>> >>>> An alternative approach is that we can make DNS and Automount top >>>> level tabs, with zone and records tabs under DNS, and locations, maps >>>> and keys as tabs under Automount. Then, all we do is change which is >>>> the default tab based on the above logic. That would make the top >>>> level tabs: >>>> >>>> Identity DNS Automount Config >>>> >>>> I'm not sure if this is a scalable approach, once we add entitlements, >>>> sudo, hbac, hci, and so on. >>>> >>>> >>> >>> I think we need to run this by Ben and make sure we are in agreement. >>> Is this blocking you? >>> >>> I do not like the ideas of DNS and Automount on the top level, sorry. >> >> I'm not sure about this either. I think that as the project continues >> we'll quickly run out of room if we do this. > Yeah, I don't either. I was just offereing it as an alternative. > >> >>> May be we should look at the DNS zones (Z) and automount locations (L) >>> in the following way: >>> 1) The fist page you get two when you go for DNS or Automount is search >>> for Z or L as in all other places. But... >>> 2) At the beginning there are no Z or L so the code instead of >>> displaying the search page will redirect user to the non modal "add Z" >> > or "add L" page respectfully automatically. >> >> Actually there will always be both a Z and an L. The Z is created >> when the server is installed, though we do probably need to handle >> the case where all zones are deleted. >> >> Same for L. We provide one named "default".
Then it even reduces the logic to handling one and more than one and not having to have case for 0. >> >>> 3) If there is just one Z or L entry the search page will automatically >>> redirect user to the Z or L contents page >>> 4) On the Z or L content page we will have a button "add another Z" or >>> "add another L". This will be the way to add second Z or L in the first >>> place. >>> 5) As soon as there are more than 1 Z or L the search page will present >>> the list rather than do automatic redirect. > > That sounds pretty much like what I was recommending. I think we are > in "violent agreement" We were in agreement from the very beginning. It is just that I tried to use the wording that makes more sense for me and present the case in a more algorithmic way. >>> >>> This seems to be a pretty logical and consistent approach. >>> Now if we agree to this one it might make sense to consider doing the >>> same thing for some of the objects that by default will not be >>> prepopulated in the LDAP. For example netgroups or host groups. I am >>> not >>> sure it makes sense for users and groups since there will be at least >>> one user and one group from the installation moment. > Those cases are different, in that the searches will just return 0 > results. I say we leave those as is. > >> >> The thing is this is like a .0001% case. You probably will ever only >> see it once during an install. Assuming it doesn't take a lot of work >> to do it I'm fine with it, otherwise the search box where there is >> nothing to be found is fine by me. > Agreed > >> >> rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- Thank you, Dmitri Pal 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
