Re: [Freeipa-devel] [PATCH] Modified ipa help behavior
Jan Zelený wrote: Jakub Hrozek wrote: On 01/05/2011 11:55 AM, Jan Zelený wrote: Jakub Hrozek wrote: Nack, the hbac->hbacrule rename is still not complete. There is still "from ipalib.plugins.hbac import is_all" in ipalib/plugins/netgroup.py and "api.register(hbac)" in ipalib/plugins/hbacrule.py and also "ret = self.failsafe_add(api.Object.hbac," in tests/test_xmlrpc/test_hbac_plugin.py This is final version, all issues have been solved. Jan Ack Can someone please push this? Done, pushed to master rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Modified ipa help behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/05/2011 11:55 AM, Jan Zelený wrote: > Jakub Hrozek wrote: >> Nack, >> >> the hbac->hbacrule rename is still not complete. There is still >> "from ipalib.plugins.hbac import is_all" in ipalib/plugins/netgroup.py >> and "api.register(hbac)" in ipalib/plugins/hbacrule.py and also "ret = >> self.failsafe_add(api.Object.hbac," in >> tests/test_xmlrpc/test_hbac_plugin.py > > This is final version, all issues have been solved. > > Jan > Ack -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0kXpUACgkQHsardTLnvCVP2ACgld4eoNAKeiB07mTql63Lx0C0 kyMAoKl2ruUkNYQbAPXKsY5qEFY5Dl1v =Lrkm -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Modified ipa help behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/20/2010 04:16 PM, Jan Zelený wrote: > Jan Zelený wrote: >> Jakub Hrozek wrote: >>> On 12/09/2010 09:54 AM, Jan Zelený wrote: Jan Zelený wrote: > Jan Zelený wrote: >> Now each plugin can define its topic as a 2-tuple, where the first >> item is the name of topic it belongs to and the second item is >> a description of such topic. Topic descriptions must be the same >> for all modules belonging to the topic. >> >> By using this topics, it is possible to group plugins as we see fit. >> When asking for help for a particular topic, help for all modules >> in given topic is written. >> >> ipa help - show all topics (until now it showed all plugins) >> ipa help - show details to given topic >> >> https://fedorahosted.org/freeipa/ticket/410 > > So here it is: I'm sending couple patches which resolve the ticket and > implement grouping the way we previously discussed. Please feel free > to send me any recommendations if anything should be modified. Here's updated version of 0014 (changed type detection from type(var) is type({}) to type(var) is dict) Jan >>> >>> The first patch in the series does not apply cleanly anymore, can you >>> rebase? >> >>> Also, ipa help gives me a traceback now: >> Both patches are in the attachment >> >> Jan > > One more change to the renaming of hbac to hbacrule. I'm sending all patches > for better lucidity. > > Jan > Nack, the hbac->hbacrule rename is still not complete. There is still "from ipalib.plugins.hbac import is_all" in ipalib/plugins/netgroup.py and "api.register(hbac)" in ipalib/plugins/hbacrule.py and also "ret = self.failsafe_add(api.Object.hbac," in tests/test_xmlrpc/test_hbac_plugin.py Jakub -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0QlrYACgkQHsardTLnvCVW6ACeKTVGIizY9AfoZzVA4zA2yf1H focAni0NUUZwkoPxjZnUveOMOlUAtDeM =XEKr -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Modified ipa help behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/09/2010 09:54 AM, Jan Zelený wrote: > Jan Zelený wrote: >> Jan Zelený wrote: >>> Now each plugin can define its topic as a 2-tuple, where the first >>> item is the name of topic it belongs to and the second item is >>> a description of such topic. Topic descriptions must be the same >>> for all modules belonging to the topic. >>> >>> By using this topics, it is possible to group plugins as we see fit. >>> When asking for help for a particular topic, help for all modules >>> in given topic is written. >>> >>> ipa help - show all topics (until now it showed all plugins) >>> ipa help - show details to given topic >>> >>> https://fedorahosted.org/freeipa/ticket/410 >> >> So here it is: I'm sending couple patches which resolve the ticket and >> implement grouping the way we previously discussed. Please feel free to >> send me any recommendations if anything should be modified. > > Here's updated version of 0014 (changed type detection from type(var) is > type({}) to type(var) is dict) > > Jan The first patch in the series does not apply cleanly anymore, can you rebase? Also, ipa help gives me a traceback now: ipa: ERROR: UnboundLocalError: local variable 'mod_name' referenced before assignment Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1049, in run api.finalize() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 615, in finalize p.instance.finalize() File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 662, in finalize self._count_topic_mcl(topic_name, mod_name) UnboundLocalError: local variable 'mod_name' referenced before assignment ipa: ERROR: an internal error has occurred -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0PLA8ACgkQHsardTLnvCWgIwCeIlMoGGZhbmr0t9aD19L4pBHP rf4AoNrX+TkHlSDfT0BmR3J1MEz7bU5+ =XzUE -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Modified ipa help behavior
On 12/06/2010 07:19 AM, Jan Zelený wrote: Rob Crittenden wrote: Jan Zelený wrote: Jan Zelený wrote: Now each plugin can define its topic as a 2-tuple, where the first item is the name of topic it belongs to and the second item is a description of such topic. Topic descriptions must be the same for all modules belonging to the topic. By using this topics, it is possible to group plugins as we see fit. When asking for help for a particular topic, help for all modules in given topic is written. ipa help - show all topics (until now it showed all plugins) ipa help - show details to given topic https://fedorahosted.org/freeipa/ticket/410 Sorry for the wrong sequence number, sending the correct one now. I think this is a good start but I find the output hard to read, both with a single topic (like user) or multiple (like sudo). The dashed lines and the extra spaces make my eyes cross a bit What I don't have is any good suggestion to change it up. I realize you are jamming together discrete things that may or may not look nice together. I suppose a few suggestions might be: - a SEEALSO-like where you print the topics at the bottom so it is obvious that multiple things are jammed together - A single dashed-line all the way across (more or less) with a single space before and after might be a less jarring separator. IIRC we have some output code that should handle screen sizes for you. - I'm not sure if combining all the commands into a single list is the right thing or not. It may not be necessary with the SEEALSO. So nack for now but this is headed in the right direction. rob After the last discussion at the meeting, I started to work on this again. The goal is to implement suggested idea with SEE ALSO topics. But there is one more issue to solve. It occurred to me that hbac topic would contain 3 subtopics: hbac, hbacsvc and hbacsvcgroup. Now the issue is when I type: ipa help hbac How should the program distinguish the topic hbac from the hbac subtopic? The simplest solution here is to rename the module, but that doesn't seem right to me. Other solution could be to rename the topic, but that would be against the basic reason why we should implement topic grouping. Any suggestions? Frankly, I'm wonder if the topic-based grouping is worth the effort, but I have an idea a little bit different from this approach. When typing ipa help hbac* user would receive a filtered list of topics, where only topics with module name starting with "hbac" would be. The result would look like this: ipa help hbac* That syntax would break in a bASH. It would try to match files in the PWD that start with habc, and report an error if there were none. Usage: ipa [global-options] COMMAND ... Help topics: hbac Host-based access control hbacsvc HBAC Services hbacsvcgroup HBAC Service Groups The only limitation of this concept is that topic groups wouldn't be "stable". For example the result of ipa help hbac would be different from ipa help hbacsvc. Also some incorrect grouping might occur (host and hostgroup at the moment). Before I start working on this, I'd like to know your opinions. Thanks Jan ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Modified ipa help behavior
On 12/06/2010 09:45 AM, Dmitri Pal wrote: Jan Zelený wrote: Rob Crittenden wrote: Jan Zelený wrote: Jan Zelený wrote: Now each plugin can define its topic as a 2-tuple, where the first item is the name of topic it belongs to and the second item is a description of such topic. Topic descriptions must be the same for all modules belonging to the topic. By using this topics, it is possible to group plugins as we see fit. When asking for help for a particular topic, help for all modules in given topic is written. ipa help - show all topics (until now it showed all plugins) ipa help - show details to given topic https://fedorahosted.org/freeipa/ticket/410 Sorry for the wrong sequence number, sending the correct one now. I think this is a good start but I find the output hard to read, both with a single topic (like user) or multiple (like sudo). The dashed lines and the extra spaces make my eyes cross a bit What I don't have is any good suggestion to change it up. I realize you are jamming together discrete things that may or may not look nice together. I suppose a few suggestions might be: - a SEEALSO-like where you print the topics at the bottom so it is obvious that multiple things are jammed together - A single dashed-line all the way across (more or less) with a single space before and after might be a less jarring separator. IIRC we have some output code that should handle screen sizes for you. - I'm not sure if combining all the commands into a single list is the right thing or not. It may not be necessary with the SEEALSO. So nack for now but this is headed in the right direction. rob After the last discussion at the meeting, I started to work on this again. The goal is to implement suggested idea with SEE ALSO topics. But there is one more issue to solve. It occurred to me that hbac topic would contain 3 subtopics: hbac, hbacsvc and hbacsvcgroup. Now the issue is when I type: ipa help hbac How should the program distinguish the topic hbac from the hbac subtopic? The simplest solution here is to rename the module, but that doesn't seem right to me. Other solution could be to rename the topic, but that would be against the basic reason why we should implement topic grouping. Any suggestions? Frankly, I'm wonder if the topic-based grouping is worth the effort, but I have an idea a little bit different from this approach. When typing ipa help hbac* user would receive a filtered list of topics, where only topics with module name starting with "hbac" would be. The result would look like this: ipa help hbac* Usage: ipa [global-options] COMMAND ... Help topics: hbac Host-based access control hbacsvc HBAC Services hbacsvcgroup HBAC Service Groups The only limitation of this concept is that topic groups wouldn't be "stable". For example the result of ipa help hbac would be different from ipa help hbacsvc. Also some incorrect grouping might occur (host and hostgroup at the moment). Before I start working on this, I'd like to know your opinions. May be use hbac for the high level topic group and hbacrule for the hbac rule management? +1. I was going to sugget that myself. We should rename the HBAC entity to HBAC Rule, and that makes Sudo and HBAC consistant. Note that DNS2 does this, with the top level entity being the dnszone. This way there is no name collision. I do not know how big of a change it is and how it would affect UI/CLI/man etc. At this point of the project we need to try to minimize changes. It will affect SUDO too... Other approach might be to allow subtopics as another parameter: Usage: ipa help topic subtopic ipa help hbac hbac May be for the purpose of help we can do: ipa help hbac Usage: ipa [global-options] COMMAND ... Help subtopics: rule Host-based access control rules service HBAC Services group HBAC Service Groups ipa help hbac rule ... ipa help hbac service ... ipa help hbac group ... Will that work? AFAIU this will not have any impact on the commands and would not require any changes to the UI/CLI other than to the help system itself. Thanks Dmitri Thanks Jan ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Modified ipa help behavior
Jan Zelený wrote: > Rob Crittenden wrote: > >> Jan Zelený wrote: >> >>> Jan Zelený wrote: >>> Now each plugin can define its topic as a 2-tuple, where the first item is the name of topic it belongs to and the second item is a description of such topic. Topic descriptions must be the same for all modules belonging to the topic. By using this topics, it is possible to group plugins as we see fit. When asking for help for a particular topic, help for all modules in given topic is written. ipa help - show all topics (until now it showed all plugins) ipa help - show details to given topic https://fedorahosted.org/freeipa/ticket/410 >>> Sorry for the wrong sequence number, sending the correct one now. >>> >> I think this is a good start but I find the output hard to read, both >> with a single topic (like user) or multiple (like sudo). The dashed >> lines and the extra spaces make my eyes cross a bit >> >> What I don't have is any good suggestion to change it up. I realize you >> are jamming together discrete things that may or may not look nice >> together. >> >> I suppose a few suggestions might be: >> >> - a SEEALSO-like where you print the topics at the bottom so it is >> obvious that multiple things are jammed together >> - A single dashed-line all the way across (more or less) with a single >> space before and after might be a less jarring separator. IIRC we have >> some output code that should handle screen sizes for you. >> - I'm not sure if combining all the commands into a single list is the >> right thing or not. It may not be necessary with the SEEALSO. >> >> So nack for now but this is headed in the right direction. >> >> rob >> > > After the last discussion at the meeting, I started to work on this again. > The > goal is to implement suggested idea with SEE ALSO topics. But there is one > more issue to solve. It occurred to me that hbac topic would contain 3 > subtopics: hbac, hbacsvc and hbacsvcgroup. Now the issue is when I type: > > ipa help hbac > > How should the program distinguish the topic hbac from the hbac subtopic? The > simplest solution here is to rename the module, but that doesn't seem right > to > me. Other solution could be to rename the topic, but that would be against > the > basic reason why we should implement topic grouping. Any suggestions? > > Frankly, I'm wonder if the topic-based grouping is worth the effort, but I > have > an idea a little bit different from this approach. When typing > > ipa help hbac* > > user would receive a filtered list of topics, where only topics with module > name starting with "hbac" would be. The result would look like this: > > ipa help hbac* > Usage: ipa [global-options] COMMAND ... > > Help topics: > hbac Host-based access control > hbacsvc HBAC Services > hbacsvcgroup HBAC Service Groups > > The only limitation of this concept is that topic groups wouldn't be > "stable". > For example the result of ipa help hbac would be different from ipa help > hbacsvc. Also some incorrect grouping might occur (host and hostgroup at the > moment). Before I start working on this, I'd like to know your opinions. > > May be use hbac for the high level topic group and hbacrule for the hbac rule management? This way there is no name collision. I do not know how big of a change it is and how it would affect UI/CLI/man etc. At this point of the project we need to try to minimize changes. It will affect SUDO too... Other approach might be to allow subtopics as another parameter: Usage: ipa help topic subtopic ipa help hbac hbac May be for the purpose of help we can do: ipa help hbac Usage: ipa [global-options] COMMAND ... Help subtopics: rule Host-based access control rules service HBAC Services group HBAC Service Groups ipa help hbac rule ... ipa help hbac service ... ipa help hbac group ... Will that work? AFAIU this will not have any impact on the commands and would not require any changes to the UI/CLI other than to the help system itself. Thanks Dmitri > Thanks > Jan > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- 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] Modified ipa help behavior
On Mon, Nov 22, 2010 at 04:14:03PM -0500, Simo Sorce wrote: > On Mon, 22 Nov 2010 11:33:19 -0500 > Rob Crittenden wrote: > > > So I'm wondering if we need to re-think how we'd documenting things. > > > > Right now we have on the order of 178 commands. That is a LOT of man > > pages even if we used some sort of automated XML system. We just need > > to do the right thing before GA. > > > > Rather than combining the help from all the similar commands just > > show the top-level and include a SEEALSO? > > > > So for example for: ipa help hbac > > > > We would just show the hbac top-level help and include a SEEALSO for > > hbacsvc and hbacsvcgroup rather than including those top-level help > > as well? > > > > Similarly for sudo. > > Not saying we should follow example but git seem to just fetch and > popup the man page when you run a --help request. > > So it seem that git upstream decided to document stuff only in the > manpages instead of providing contextual help. > > It seem an interesting option, worth discussing imo. > > Simo. Depends on how verbose the manpage is, I guess. I often run --help just to check the exact syntax of switches -- stuff like does ipa group-add-member take --groups or --group? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Modified ipa help behavior
On Mon, 22 Nov 2010 11:33:19 -0500 Rob Crittenden wrote: > So I'm wondering if we need to re-think how we'd documenting things. > > Right now we have on the order of 178 commands. That is a LOT of man > pages even if we used some sort of automated XML system. We just need > to do the right thing before GA. > > Rather than combining the help from all the similar commands just > show the top-level and include a SEEALSO? > > So for example for: ipa help hbac > > We would just show the hbac top-level help and include a SEEALSO for > hbacsvc and hbacsvcgroup rather than including those top-level help > as well? > > Similarly for sudo. Not saying we should follow example but git seem to just fetch and popup the man page when you run a --help request. So it seem that git upstream decided to document stuff only in the manpages instead of providing contextual help. It seem an interesting option, worth discussing imo. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Modified ipa help behavior
Jan Zelený wrote: Rob Crittenden wrote: Jan Zelený wrote: Jan Zelený wrote: Now each plugin can define its topic as a 2-tuple, where the first item is the name of topic it belongs to and the second item is a description of such topic. Topic descriptions must be the same for all modules belonging to the topic. By using this topics, it is possible to group plugins as we see fit. When asking for help for a particular topic, help for all modules in given topic is written. ipa help - show all topics (until now it showed all plugins) ipa help - show details to given topic https://fedorahosted.org/freeipa/ticket/410 Sorry for the wrong sequence number, sending the correct one now. I think this is a good start but I find the output hard to read, both with a single topic (like user) or multiple (like sudo). The dashed lines and the extra spaces make my eyes cross a bit What I don't have is any good suggestion to change it up. I realize you are jamming together discrete things that may or may not look nice together. I suppose a few suggestions might be: - a SEEALSO-like where you print the topics at the bottom so it is obvious that multiple things are jammed together - A single dashed-line all the way across (more or less) with a single space before and after might be a less jarring separator. IIRC we have some output code that should handle screen sizes for you. - I'm not sure if combining all the commands into a single list is the right thing or not. It may not be necessary with the SEEALSO. So nack for now but this is headed in the right direction. rob I gave this some thought: Output for each single-module topic is given by module's doc string. How good readability it has is not up to help function, but rather up to the developer of that particular module. The only thing I can do is not to display the separator. And as for multiple topics - I can change the concept to support two-level topics. That way when asking for the first level, it would display either entire single-module topic with its commands or it will only display a brief description of the topic and a list of its subtopics (this is based on your suggestion with SEEALSO section). Asking for one of these subtopics will output the same help as it would for single-module topic. I'm not sure about usability of this though. Personally I'd probably be asking who invented a help, which needs 4 shell commands to get to a help of IPA command: ipa help ipa help sudo ipa help sudocmd ipa help sudocmd-add I tried your other suggestions and the result doesn't look significantly better than the current one. What do you think is the best way to proceed? Jan The multiple commands for a given logical topic weren't really a consideration when the framework was created. At that time we were only considering very high-level topics like user, group and host. To example on your comment about the per-module documentation, that seems to be key. We have a separate ticket open against hbac-add to include per-command documentation on access time format. So I'm wondering if we need to re-think how we'd documenting things. Right now we have on the order of 178 commands. That is a LOT of man pages even if we used some sort of automated XML system. We just need to do the right thing before GA. Rather than combining the help from all the similar commands just show the top-level and include a SEEALSO? So for example for: ipa help hbac We would just show the hbac top-level help and include a SEEALSO for hbacsvc and hbacsvcgroup rather than including those top-level help as well? Similarly for sudo. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Modified ipa help behavior
Jan Zelený wrote: Jan Zelený wrote: Now each plugin can define its topic as a 2-tuple, where the first item is the name of topic it belongs to and the second item is a description of such topic. Topic descriptions must be the same for all modules belonging to the topic. By using this topics, it is possible to group plugins as we see fit. When asking for help for a particular topic, help for all modules in given topic is written. ipa help - show all topics (until now it showed all plugins) ipa help - show details to given topic https://fedorahosted.org/freeipa/ticket/410 Sorry for the wrong sequence number, sending the correct one now. I think this is a good start but I find the output hard to read, both with a single topic (like user) or multiple (like sudo). The dashed lines and the extra spaces make my eyes cross a bit What I don't have is any good suggestion to change it up. I realize you are jamming together discrete things that may or may not look nice together. I suppose a few suggestions might be: - a SEEALSO-like where you print the topics at the bottom so it is obvious that multiple things are jammed together - A single dashed-line all the way across (more or less) with a single space before and after might be a less jarring separator. IIRC we have some output code that should handle screen sizes for you. - I'm not sure if combining all the commands into a single list is the right thing or not. It may not be necessary with the SEEALSO. So nack for now but this is headed in the right direction. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel