Re: [Freeipa-devel] Optimizing for the common case: automount and DNS
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
Re: [Freeipa-devel] Optimizing for the common case: automount and DNS
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". 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" 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 t
Re: [Freeipa-devel] Optimizing for the common case: automount and DNS
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. 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". 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. 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. 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. rob ___ Freei
Re: [Freeipa-devel] Optimizing for the common case: automount and DNS
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. 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. 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. 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. > > > > > > > ___ > 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
