Re: [openstack-dev] This is what disabled-by-policy should look like to the user

[Fox, Kevin M]

+1


From: Adam Young
Sent: Friday, September 04, 2015 7:43:08 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] This is what disabled-by-policy should look like 
to the user

On 09/04/2015 10:04 AM, Monty Taylor wrote:
> mordred@camelot:~$ neutron net-create test-net-mt
> Policy doesn't allow create_network to be performed.
>
> Thank you neutron. Excellent job.
>
> Here's what that looks like at the REST layer:
>
> DEBUG: keystoneclient.session RESP: [403] date: Fri, 04 Sep 2015
> 13:55:47 GMT connection: close content-type: application/json;
> charset=UTF-8 content-length: 130 x-openstack-request-id:
> req-ba05b555-82f4-4aaf-91b2-bae37916498d
> RESP BODY: {"NeutronError": {"message": "Policy doesn't allow
> create_network to be performed.", "type": "PolicyNotAuthorized",
> "detail": ""}}
>
> As a user, I am not confused. I do not think that maybe I made a
> mistake with my credentials. The cloud in question simply does not
> allow user creation of networks. I'm fine with that. (as a user, that
> might make this cloud unusable to me - but that's a choice I can now
> make with solid information easily. Turns out, I don't need to create
> networks for my application, so this actually makes it easier for me
> personally)
>
> In any case- rather than complaining and being a whiny brat about
> something that annoys me - I thought I'd say something nice about
> something that the neutron team has done that especially pleases me.

Then let my Hijack:

Policy is still broken.  We need the pieces of Dynamic policy.

I am going to call for a cross project policy discussion for the
upcoming summit.  Please, please, please all the projects attend. The
operators have made it clear they need better policy support.


> I would love it if this became the experience across the board in
> OpenStack for times when a feature of the API is disabled by local
> policy. It's possible it already is and I just haven't directly
> experienced it - so please don't take this as a backhanded
> condemnation of anyone else.
>
> Monty
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

[Adam Young]

On 09/06/2015 03:31 PM, Duncan Thomas wrote:



On 5 Sep 2015 05:47, "Adam Young" > wrote:


> Then let my Hijack:
>
> Policy is still broken.  We need the pieces of Dynamic policy.
>
> I am going to call for a cross project policy discussion for the 
upcoming summit.  Please, please, please all the projects attend. The 
operators have made it clear they need better policy support.


Can you give us a heads up on the perceived shortcomings, please, 
together with an overview of any proposed changes? Turning up to a 
session to hear, unprepared, something that can be introduced in 
advance over email so that people can ruminate on the details and be 
better prepared to discuss them is probably more productive than 
expecting tired, jet-lagged people to think on their feet.


In general, I think the practice of introducing new things at design 
summits, rather than letting people prepare, is slowing us down as a 
community.




I've been harping o0n this for a while, both at summits and before.

It starts with:

https://bugs.launchpad.net/keystone/+bug/968696

We can't fix that until we have an approach that lets us unstick the 
situations where we need a global admin.


This was the start of it:
https://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/

Submitted this overview spec (which was termed not implementable because 
it was an overview)


https://review.openstack.org/#/c/147651/



and a bunch of supporting specs:

https://review.openstack.org/#/q/status:open+project:openstack/keystone-specs+branch:master+topic:dynamic-policy,n,z

We've m,ade very little progress on this since this point 6 months ago.

Had a cross project policy discussion in Vancouver.  It was almost all 
Keystone folks, with a very few people from other projects.







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

[Duncan Thomas]

On 5 Sep 2015 05:47, "Adam Young"  wrote:

> Then let my Hijack:
>
> Policy is still broken.  We need the pieces of Dynamic policy.
>
> I am going to call for a cross project policy discussion for the upcoming
summit.  Please, please, please all the projects attend. The operators have
made it clear they need better policy support.

Can you give us a heads up on the perceived shortcomings, please, together
with an overview of any proposed changes? Turning up to a session to hear,
unprepared, something that can be introduced in advance over email so that
people can ruminate on the details and be better prepared to discuss them
is probably more productive than expecting tired, jet-lagged people to
think on their feet.

In general, I think the practice of introducing new things at design
summits, rather than letting people prepare, is slowing us down as a
community.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

[John Griffith]

On Fri, Sep 4, 2015 at 8:04 AM, Monty Taylor  wrote:

> mordred@camelot:~$ neutron net-create test-net-mt
> Policy doesn't allow create_network to be performed.
>
> Thank you neutron. Excellent job.
>
> Here's what that looks like at the REST layer:
>
> DEBUG: keystoneclient.session RESP: [403] date: Fri, 04 Sep 2015 13:55:47
> GMT connection: close content-type: application/json; charset=UTF-8
> content-length: 130 x-openstack-request-id:
> req-ba05b555-82f4-4aaf-91b2-bae37916498d
> RESP BODY: {"NeutronError": {"message": "Policy doesn't allow
> create_network to be performed.", "type": "PolicyNotAuthorized", "detail":
> ""}}
>
> As a user, I am not confused. I do not think that maybe I made a mistake
> with my credentials. The cloud in question simply does not allow user
> creation of networks. I'm fine with that. (as a user, that might make this
> cloud unusable to me - but that's a choice I can now make with solid
> information easily. Turns out, I don't need to create networks for my
> application, so this actually makes it easier for me personally)
>
> In any case- rather than complaining and being a whiny brat about
> something that annoys me - I thought I'd say something nice about something
> that the neutron team has done that especially pleases me. I would love it
> if this became the experience across the board in OpenStack for times when
> a feature of the API is disabled by local policy. It's possible it already
> is and I just haven't directly experienced it - so please don't take this
> as a backhanded condemnation of anyone else.
>

​By the way, I think feedback is good and pointing out positive feedback
for something isn't as frequent as it probably should be.  So before the
sentiment gets completely lost...

"Cool, thanks for pointing it out and yeah; maybe we can look at some
improvements in Cinder and other projects".
​


>
> Monty
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] This is what disabled-by-policy should look like to the user

[Monty Taylor]

mordred@camelot:~$ neutron net-create test-net-mt
Policy doesn't allow create_network to be performed.

Thank you neutron. Excellent job.

Here's what that looks like at the REST layer:

DEBUG: keystoneclient.session RESP: [403] date: Fri, 04 Sep 2015 
13:55:47 GMT connection: close content-type: application/json; 
charset=UTF-8 content-length: 130 x-openstack-request-id: 
req-ba05b555-82f4-4aaf-91b2-bae37916498d
RESP BODY: {"NeutronError": {"message": "Policy doesn't allow 
create_network to be performed.", "type": "PolicyNotAuthorized", 
"detail": ""}}


As a user, I am not confused. I do not think that maybe I made a mistake 
with my credentials. The cloud in question simply does not allow user 
creation of networks. I'm fine with that. (as a user, that might make 
this cloud unusable to me - but that's a choice I can now make with 
solid information easily. Turns out, I don't need to create networks for 
my application, so this actually makes it easier for me personally)


In any case- rather than complaining and being a whiny brat about 
something that annoys me - I thought I'd say something nice about 
something that the neutron team has done that especially pleases me. I 
would love it if this became the experience across the board in 
OpenStack for times when a feature of the API is disabled by local 
policy. It's possible it already is and I just haven't directly 
experienced it - so please don't take this as a backhanded condemnation 
of anyone else.


Monty

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

[Monty Taylor]

On 09/04/2015 10:55 AM, Morgan Fainberg wrote:




On Sep 4, 2015, at 07:04, Monty Taylor 
wrote:

mordred@camelot:~$ neutron net-create test-net-mt Policy doesn't
allow create_network to be performed.

Thank you neutron. Excellent job.

Here's what that looks like at the REST layer:

DEBUG: keystoneclient.session RESP: [403] date: Fri, 04 Sep 2015
13:55:47 GMT connection: close content-type: application/json;
charset=UTF-8 content-length: 130 x-openstack-request-id:
req-ba05b555-82f4-4aaf-91b2-bae37916498d RESP BODY:
{"NeutronError": {"message": "Policy doesn't allow create_network
to be performed.", "type": "PolicyNotAuthorized", "detail": ""}}

As a user, I am not confused. I do not think that maybe I made a
mistake with my credentials. The cloud in question simply does not
allow user creation of networks. I'm fine with that. (as a user,
that might make this cloud unusable to me - but that's a choice I
can now make with solid information easily. Turns out, I don't need
to create networks for my application, so this actually makes it
easier for me personally)



The 403 (yay good HTTP error choice) and message is great here.

We should make this the default (I think we can do something like
this baking it into the enforcer in oslo.policy so that it is
consistent across openstack).


Great idea!


Obviously the translation of errors
would be more difficult if the enforcer is generating messages.


The type: "PolicyNotAuthorized" is a good general key. Also - even 
though the command I sent was:


neutron net-create

On the command line, the entry in the policy_file is "create_network" - 
so honestly I think that policy.json and oslo.policy should have (or be 
able to have) all of the info needed to create almost the exact same 
message. Perhaps "NeutronError" would just need to be 
"OpenStackPolicyError"?


Oh. Wait. You meant translation like i18n translation. In that case, I 
think it's easy:


message=_("Policy doesn't allow %(policy_key)s to be performed", 
policy_key="create_network")


/me waves hands


--Morgan



__



OpenStack Development Mailing List (not for usage questions)

Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

[Morgan Fainberg]

> On Sep 4, 2015, at 07:04, Monty Taylor  wrote:
> 
> mordred@camelot:~$ neutron net-create test-net-mt
> Policy doesn't allow create_network to be performed.
> 
> Thank you neutron. Excellent job.
> 
> Here's what that looks like at the REST layer:
> 
> DEBUG: keystoneclient.session RESP: [403] date: Fri, 04 Sep 2015 13:55:47 GMT 
> connection: close content-type: application/json; charset=UTF-8 
> content-length: 130 x-openstack-request-id: 
> req-ba05b555-82f4-4aaf-91b2-bae37916498d
> RESP BODY: {"NeutronError": {"message": "Policy doesn't allow create_network 
> to be performed.", "type": "PolicyNotAuthorized", "detail": ""}}
> 
> As a user, I am not confused. I do not think that maybe I made a mistake with 
> my credentials. The cloud in question simply does not allow user creation of 
> networks. I'm fine with that. (as a user, that might make this cloud unusable 
> to me - but that's a choice I can now make with solid information easily. 
> Turns out, I don't need to create networks for my application, so this 
> actually makes it easier for me personally)
> 

The 403 (yay good HTTP error choice) and message is great here.

We should make this the default (I think we can do something like this baking 
it into the enforcer in oslo.policy so that it is consistent across openstack). 
Obviously the translation of errors would be more difficult if the enforcer is 
generating messages. 

--Morgan



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

[Mathieu Gagné]

On 2015-09-04 12:50 PM, Monty Taylor wrote:
> On 09/04/2015 10:55 AM, Morgan Fainberg wrote:
>>
>> Obviously the translation of errors
>> would be more difficult if the enforcer is generating messages.
> 
> The type: "PolicyNotAuthorized" is a good general key. Also - even
> though the command I sent was:
> 
> neutron net-create
> 
> On the command line, the entry in the policy_file is "create_network" -
> so honestly I think that policy.json and oslo.policy should have (or be
> able to have) all of the info needed to create almost the exact same
> message. Perhaps "NeutronError" would just need to be
> "OpenStackPolicyError"?
> 
> Oh. Wait. You meant translation like i18n translation. In that case, I
> think it's easy:
> 
> message=_("Policy doesn't allow %(policy_key)s to be performed",
> policy_key="create_network")
> 
> /me waves hands
> 

I don't feel like this error message would be user-friendly:

"Policy doesn't allow os_compute_api:os-instance-actions to be performed"

Policy name aren't human readable and match nothing on the client side.

-- 
Mathieu

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

[John Griffith]

On Fri, Sep 4, 2015 at 11:35 AM, Mathieu Gagné  wrote:

> On 2015-09-04 12:50 PM, Monty Taylor wrote:
> > On 09/04/2015 10:55 AM, Morgan Fainberg wrote:
> >>
> >> Obviously the translation of errors
> >> would be more difficult if the enforcer is generating messages.
> >
> > The type: "PolicyNotAuthorized" is a good general key. Also - even
> > though the command I sent was:
> >
> > neutron net-create
> >
> > On the command line, the entry in the policy_file is "create_network" -
> > so honestly I think that policy.json and oslo.policy should have (or be
> > able to have) all of the info needed to create almost the exact same
> > message. Perhaps "NeutronError" would just need to be
> > "OpenStackPolicyError"?
> >
> > Oh. Wait. You meant translation like i18n translation. In that case, I
> > think it's easy:
> >
> > message=_("Policy doesn't allow %(policy_key)s to be performed",
> > policy_key="create_network")
> >
> > /me waves hands
> >
>
> I don't feel like this error message would be user-friendly:
>
> "Policy doesn't allow os_compute_api:os-instance-actions to be performed"
>
> Policy name aren't human readable and match nothing on the client side.
>
> --
> Mathieu
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

​Ok, so this:

ubuntu@devbox:~$ cinder reset-state 9dee0fae-864c-44f9-bdd7-3330a0f4e899
Reset state for volume 9dee0fae-864c-44f9-bdd7-3330a0f4e899 failed: Policy
doesn't allow volume_extension:volume_admin_actions:reset_status to be
performed. (HTTP 403) (Request-ID: req-8ed2c895-0d1f-4b2c-9859-ee15c19267de)
ERROR: Unable to reset the state for the specified volume(s).
ubuntu@devbox:~$​

​Is no good?  You would like to see "less" in the output; like just the
command name itself and "Policy doesn't allow"?

To Mathieu's point, fair statement WRT the visibility of the policy name.

​
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

[Morgan Fainberg]

On Fri, Sep 4, 2015 at 10:35 AM, Mathieu Gagné  wrote:

> On 2015-09-04 12:50 PM, Monty Taylor wrote:
> > On 09/04/2015 10:55 AM, Morgan Fainberg wrote:
> >>
> >> Obviously the translation of errors
> >> would be more difficult if the enforcer is generating messages.
> >
> > The type: "PolicyNotAuthorized" is a good general key. Also - even
> > though the command I sent was:
> >
> > neutron net-create
> >
> > On the command line, the entry in the policy_file is "create_network" -
> > so honestly I think that policy.json and oslo.policy should have (or be
> > able to have) all of the info needed to create almost the exact same
> > message. Perhaps "NeutronError" would just need to be
> > "OpenStackPolicyError"?
> >
> > Oh. Wait. You meant translation like i18n translation. In that case, I
> > think it's easy:
> >
> > message=_("Policy doesn't allow %(policy_key)s to be performed",
> > policy_key="create_network")
> >
> > /me waves hands
> >
>
> I don't feel like this error message would be user-friendly:
>
> "Policy doesn't allow os_compute_api:os-instance-actions to be performed"
>
> Policy name aren't human readable and match nothing on the client side.
>
>
To be fair the message can be improved. Right now this is so far above what
you get in most cases. Digging a bit deeper, a lot of this is in
oslo.policy but it appears we have projects doing custom layers of
enforcement that change the results. The short solution is to clean up and
consistently raise an exception up and then work on the messaging.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

[Monty Taylor]

On 09/04/2015 01:42 PM, John Griffith wrote:

On Fri, Sep 4, 2015 at 11:35 AM, Mathieu Gagné  wrote:


On 2015-09-04 12:50 PM, Monty Taylor wrote:

On 09/04/2015 10:55 AM, Morgan Fainberg wrote:


Obviously the translation of errors
would be more difficult if the enforcer is generating messages.


The type: "PolicyNotAuthorized" is a good general key. Also - even
though the command I sent was:

neutron net-create

On the command line, the entry in the policy_file is "create_network" -
so honestly I think that policy.json and oslo.policy should have (or be
able to have) all of the info needed to create almost the exact same
message. Perhaps "NeutronError" would just need to be
"OpenStackPolicyError"?

Oh. Wait. You meant translation like i18n translation. In that case, I
think it's easy:

message=_("Policy doesn't allow %(policy_key)s to be performed",
policy_key="create_network")

/me waves hands



I don't feel like this error message would be user-friendly:

"Policy doesn't allow os_compute_api:os-instance-actions to be performed"

Policy name aren't human readable and match nothing on the client side.

--
Mathieu

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



​Ok, so this:

ubuntu@devbox:~$ cinder reset-state 9dee0fae-864c-44f9-bdd7-3330a0f4e899
Reset state for volume 9dee0fae-864c-44f9-bdd7-3330a0f4e899 failed: Policy
doesn't allow volume_extension:volume_admin_actions:reset_status to be
performed. (HTTP 403) (Request-ID: req-8ed2c895-0d1f-4b2c-9859-ee15c19267de)
ERROR: Unable to reset the state for the specified volume(s).
ubuntu@devbox:~$​

​Is no good?  You would like to see "less" in the output; like just the
command name itself and "Policy doesn't allow"?

To Mathieu's point, fair statement WRT the visibility of the policy name.


Totally agree on the policy name. The one I did happened to be clear - 
that is not always the case. I'd love to see that.


But more to your question - yes, as an end user, I do't know what a 
volume_extension:volume_admin_actions:reset_status is - but I do know 
that I ran "cinder reset-state" - so getting:


'Cloud policy does not allow you to run reset_status"

would be fairly clear to me.

The other bits, the 403, the request-id and then the additional error 
message are a bit too busy. (they seem like output for a debug or 
verbose flag IMHO)


NOW -

 ERROR: Unable to reset the state for the specified volume(s) - Policy 
does not allow reset_status


would also work and would also be clear "this did not occur, the reason 
is that you are not allowed to do this because the cloud admin has set a 
policy.


Now that I'm talking out loud though - I'm policy is a little confusing 
- because policy is not an end-user concept in any way.


"Your cloud administrator has disabled this API function"

is clearer and more to the point with less jargon.

I think the key points to communicate (verbally or through crafting):

- Yes, you logged in
- Yes, the API you called is a correct and real API
- No, you did not make a syntax error
- No, you are not allowed to call that real API on _this_ cloud

(without knowing those things, I tend to debug a TON of things before 
figuring out "oh, the cloud admin turned off part of the API)



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

[Mathieu Gagné]

On 2015-09-04 2:41 PM, Monty Taylor wrote:
> On 09/04/2015 01:42 PM, John Griffith wrote:
>>
>> ​Is no good?  You would like to see "less" in the output; like just the
>> command name itself and "Policy doesn't allow"?
>>
>> To Mathieu's point, fair statement WRT the visibility of the policy name.
> 
> Totally agree on the policy name. The one I did happened to be clear -
> that is not always the case. I'd love to see that.
> 
> But more to your question - yes, as an end user, I do't know what a
> volume_extension:volume_admin_actions:reset_status is - but I do know
> that I ran "cinder reset-state" - so getting:
> 
> 'Cloud policy does not allow you to run reset_status"
> 
> would be fairly clear to me.

Don't assume the user will run it from the (supposedly) deprecated
Cinder CLI. It could be from the new openstackclient or even an SDK
written in Ruby which might not name it "reset_status".

I would prefer a generic message over an overly specific message which
makes a lot of wrong assumption about the consumer.

-- 
Mathieu

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

[Adam Young]

On 09/04/2015 10:04 AM, Monty Taylor wrote:

mordred@camelot:~$ neutron net-create test-net-mt
Policy doesn't allow create_network to be performed.

Thank you neutron. Excellent job.

Here's what that looks like at the REST layer:

DEBUG: keystoneclient.session RESP: [403] date: Fri, 04 Sep 2015 
13:55:47 GMT connection: close content-type: application/json; 
charset=UTF-8 content-length: 130 x-openstack-request-id: 
req-ba05b555-82f4-4aaf-91b2-bae37916498d
RESP BODY: {"NeutronError": {"message": "Policy doesn't allow 
create_network to be performed.", "type": "PolicyNotAuthorized", 
"detail": ""}}


As a user, I am not confused. I do not think that maybe I made a 
mistake with my credentials. The cloud in question simply does not 
allow user creation of networks. I'm fine with that. (as a user, that 
might make this cloud unusable to me - but that's a choice I can now 
make with solid information easily. Turns out, I don't need to create 
networks for my application, so this actually makes it easier for me 
personally)


In any case- rather than complaining and being a whiny brat about 
something that annoys me - I thought I'd say something nice about 
something that the neutron team has done that especially pleases me.


Then let my Hijack:

Policy is still broken.  We need the pieces of Dynamic policy.

I am going to call for a cross project policy discussion for the 
upcoming summit.  Please, please, please all the projects attend. The 
operators have made it clear they need better policy support.



I would love it if this became the experience across the board in 
OpenStack for times when a feature of the API is disabled by local 
policy. It's possible it already is and I just haven't directly 
experienced it - so please don't take this as a backhanded 
condemnation of anyone else.


Monty

__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev