Re: [openstack-dev] usability anti-pattern, part 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/19/2014 09:01 PM, Monty Taylor wrote: except exc.Unauthorized: raise exc.CommandError(Invalid OpenStack credentials.) except exc.AuthorizationFailure: raise exc.CommandError(Unable to authorize user) This is pervasive enough that both of those exceptions come from openstack.common. Anyone? Please. Explain the difference. In words. I think that there are two problems here: first, the message for Unauthorized is wrong; it should be something like You are not authorized to do X. The second exception should most likely be 'AuthenticationFailure', and should have the error text from the Authentication exception. I've seen confusion between authz and authn in many projects; looks like OpenStack is no different, unfortunately. - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAEBAgAGBQJUIxi+AAoJEKMgtcocwZqLiq0P/j77O9jrXRBfz/2tEVTbKk0D xAO1Ol2wwgJgekqokhecQrNlqc4PajzQdlEb0fg497GzjErWvPfHRhHATkSm19M7 z6SLbhtx4G+u/v79p3hoEkfFOEcCgnQU/ZFQ2r5XhVljO12Fo+I6vBprqUhekyMO bhpVzFyjMifEDoO/C/GrNRY3QdfhkZuQO40Y9fcDlPQADykEghGXNnBx6aFyMARZ DJL6zcKwX3tMYR68cNMXdHF18Aue/U9wvVlhrw8uFa3qwT8IpJrelRZteNG+oZ0o ig4J5BDs3Mi/chNWIG7fNlCZ1OMGPT4Zn1tAitHESONme55M0Djc5N7/lizgewzb VMGkwOrpzDvpbZYZRtUpdiN8LMYEwYjIZpMRG4PO+5Roy2XNkPT8UOSWhc4Xq3ct vWA7ToBL1k0DzIs5Db0qoz1bdc31BeS3gcX+C5rLQQO/DQ45Au2mtK/yyrwmvtZB SyplnysiBhHgh6/KhuFnA4pfW5mRMfh+hb9cNyqyVldTDZDyUV4c+Xoh3rGDMlSj Lr6Gc8y16l/QgAIQZvbb2Z1MbMH5vSkRP8BNUkdhPfrB64ykiso4J4h1ftUEySJR GM6SpYzJ4tVy6o3XZajEvRJoMZZ09/3Qk/5n0QmwZOy/R6EgfO/8YfyRfGw4Rlvn zM2SySZlUhnAHfb5CYAT =f8fm -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] usability anti-pattern
Monty, your messages are always super-entertaining to read. They also generally have very good points, which is an added bonus :-P - Original Message - From: Monty Taylor mord...@inaugust.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Friday, September 19, 2014 9:52:46 PM Subject: [openstack-dev] usability anti-pattern Hey, Not to name names, but some of our client libs do this: client.Client(API_VERSION, os_username, ... ) I'm pretty sure they got the idea from python-glanceclient, so I blame Brian Waldon, since he left us for CoreOS. PLEASE STOP DOING THIS - IT CAUSES BABIES TO CRY. MORE. As a developer, I have no way of knowing what to put here. Also, imagine I'm writing a script that wants to talk to more than one cloud to do things - like, say, nodepool for Infra, or an ansible openstack inventory module. NOW WHAT? What do I put??? How do I discover that? Let me make a suggestion... Default it to something. Make it an optional parameter for experts. THEN - when the client lib talks to keystone, check the service catalog for the API version. What's this you say? Sometimes your service doesn't expose a version in the keystone catalog? PLEASE STOP DOING THIS - IT CAUSES DOLPHINS TO WEEP If you have versioned APIs, put the version in keystone. Because otherwise, as as a developer have absolutely zero way to figure it out. Well, except for the algorithm jeblair suggested: just start with 11 and count backwards until a number works This message brought to you by frustrated humans trying to use the cloud. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] usability anti-pattern
Hey, Not to name names, but some of our client libs do this: client.Client(API_VERSION, os_username, ... ) I'm pretty sure they got the idea from python-glanceclient, so I blame Brian Waldon, since he left us for CoreOS. PLEASE STOP DOING THIS - IT CAUSES BABIES TO CRY. MORE. As a developer, I have no way of knowing what to put here. Also, imagine I'm writing a script that wants to talk to more than one cloud to do things - like, say, nodepool for Infra, or an ansible openstack inventory module. NOW WHAT? What do I put??? How do I discover that? Let me make a suggestion... Default it to something. Make it an optional parameter for experts. THEN - when the client lib talks to keystone, check the service catalog for the API version. What's this you say? Sometimes your service doesn't expose a version in the keystone catalog? PLEASE STOP DOING THIS - IT CAUSES DOLPHINS TO WEEP If you have versioned APIs, put the version in keystone. Because otherwise, as as a developer have absolutely zero way to figure it out. Well, except for the algorithm jeblair suggested: just start with 11 and count backwards until a number works This message brought to you by frustrated humans trying to use the cloud. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] usability anti-pattern, part 2
except exc.Unauthorized: raise exc.CommandError(Invalid OpenStack credentials.) except exc.AuthorizationFailure: raise exc.CommandError(Unable to authorize user) This is pervasive enough that both of those exceptions come from openstack.common. Anyone? Please. Explain the difference. In words. Here's what I'm hoping. I'm hoping that AuthorizationFailure is just an old deprecated thing. I'm hoping the difference is NOT that one is I know you but you're not allowed and the other is I don't know you - because that's actually insecure. I'm guessing that what it actually is is that randomly some things return one, some things return the other, and there is absolutely no rhyme nor reason. Or, more likely, that termie liked the spelling of one of them better. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] usability anti-pattern, part 2
[OK, I'll bite...just once more...because dammit I want this crap fixed too.] I know you know this Monty, but for the benefit of the folks who don't, the client library situation is a result of them belonging to the projects they serve, each one[0] forked from a different one forked from jkm's original, without having any sort of mechanism to stay in sync, like a cross-project (BINGO!) effort to keep things consistent. We may not want a BDFL, but we NEED someone to say NO when necessary for the sake of the entire project. Jeez, now I'm sounding all enterprisey. On Fri, Sep 19, 2014 at 9:01 PM, Monty Taylor mord...@inaugust.com wrote: except exc.Unauthorized: raise exc.CommandError(Invalid OpenStack credentials.) except exc.AuthorizationFailure: raise exc.CommandError(Unable to authorize user) This is pervasive enough that both of those exceptions come from openstack.common. If thats from apiclient, I have a guess. apiclient was an attempt (by someone who got frustrated and left us) to build a common core for the clients. However, in many ways wound up being a UNION of them. And scene. I'm guessing that what it actually is is that randomly some things return one, some things return the other, and there is absolutely no rhyme nor reason. Or, more likely, that termie liked the spelling of one of them better. I like that explanation but this isn't from OCL. Actually we'd have been much farther down the road if we had used Termie's bits a year ago. Whether that is a bug or a feature is left to the reader to decide. Code speaks, sometimes, so I'm going back to writing some more client bits. Someone come help. dt [0] except swift and glance, both of which were originally in the server repo. -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] usability anti-pattern, part 2
On 09/19/2014 10:05 PM, Dean Troyer wrote: [OK, I'll bite...just once more...because dammit I want this crap fixed too.] It's tough to avoid when I toss you such juicy bones isn't it? I know you know this Monty, but for the benefit of the folks who don't, the client library situation is a result of them belonging to the projects they serve, each one[0] forked from a different one forked from jkm's original, without having any sort of mechanism to stay in sync, like a cross-project (BINGO!) effort to keep things consistent. We may not want a BDFL, but we NEED someone to say NO when necessary for the sake of the entire project. Jeez, now I'm sounding all enterprisey. On Fri, Sep 19, 2014 at 9:01 PM, Monty Taylor mord...@inaugust.com wrote: except exc.Unauthorized: raise exc.CommandError(Invalid OpenStack credentials.) except exc.AuthorizationFailure: raise exc.CommandError(Unable to authorize user) This is pervasive enough that both of those exceptions come from openstack.common. If thats from apiclient, I have a guess. apiclient was an attempt (by someone who got frustrated and left us) to build a common core for the clients. However, in many ways wound up being a UNION of them. And scene. I'm guessing that what it actually is is that randomly some things return one, some things return the other, and there is absolutely no rhyme nor reason. Or, more likely, that termie liked the spelling of one of them better. I like that explanation but this isn't from OCL. Actually we'd have been much farther down the road if we had used Termie's bits a year ago. Whether that is a bug or a feature is left to the reader to decide. Code speaks, sometimes, so I'm going back to writing some more client bits. Someone come help. ++ I'm looking forward very much to openstacksdk, btw... dt [0] except swift and glance, both of which were originally in the server repo. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
