)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"24c6ee2266455269ecd032521172a1424bafc076","unresolved":false,"context_lines":[{"line_number":10,"context_line":""},{"line_number":11,"context_line":"added [oslo_limit] group."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"keystoneauth options and \"service_id\", \"region_id\""},{"line_number":14,"context_line":"are in this group."},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Change-Id: I31e8f7c9f97b7175a7580f720383228e6f355f9a"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":8,"id":"3f79a3b5_e851b463","line":13,"range":{"start_line":13,"start_character":25,"end_line":13,"end_character":50},"updated":"2018-09-05 14:46:53.000000000","message":"We\u0027ll need to update this since we\u0027re only using `endpiont_id` now as opposed to `service_id` and `region_id`.","commit_id":"4c68c455ba0891b6c3c239f377f3a46fb662668f"}],"oslo_limit/limit.py":[{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"2307da05944c060a044dce51f3e4d08a63696d1e","unresolved":false,"context_lines":[{"line_number":48,"context_line":""},{"line_number":49,"context_line":"class Enforcer(object):"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"    def __init__(self, conf, claim, callback\u003dNone, verify\u003dTrue):"},{"line_number":52,"context_line":"        \"\"\"Context manager for checking usage against resource claims."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"        :param conf: A configuration object."}],"source_content_type":"text/x-python","patch_set":7,"id":"3f79a3b5_376795ed","line":51,"range":{"start_line":51,"start_character":23,"end_line":51,"end_character":27},"updated":"2018-08-29 14:51:17.000000000","message":"While this is pretty similar to oslo.policy\u0027s Enforcer object, I wonder if this is going to be too verbose given the usage we\u0027re going for with oslo.limit.\n\nFor example, oslo.policy exposes an Enforcer object that services can treat as a global variable, thus instantiating it once. We do this in keystone [0]. From there, the service just needs to call enforcement using that object and is never required to reconfigure the Enforcer with the CONF object.\n\nWith oslo.limit we will be using a context manager to abstract the complexity of connecting to keystone and race conditions in the __enter__ and __exit__ methods(). Setting up the configuration object here might be redundant since it\u0027s going to need to be passed into the Enforcer every time the service implements quota or limits on a resource\n\n  with limit.Enforcer(claim, callback\u003dcb):\n      # do things with a resource\n\nas opposed to the proposed way of:\n\n  with limit.Enforcer(CONF, claim, callback\u003dcb):\n      # do things with a resource\n\nI don\u0027t think we\u0027ll be able to get away without having the CONF object, since we\u0027ll need options from it for keystoneauth and querying limits. But maybe we need to refactor the Enforcer to hand back a context manager instead of a *being* the context manager? Then services only need a single enforcer instantiated with the CONF object that they can use to generate context managers to do the limit work?\n\nThoughts?\n\n[0] https://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/rbac_enforcer/enforcer.py#n109","commit_id":"93c92ebe4c78928a86d85fbadc329832606e185c"}],"oslo_limit/opts.py":[{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"2307da05944c060a044dce51f3e4d08a63696d1e","unresolved":false,"context_lines":[{"line_number":28,"context_line":"    \u0027service_id\u0027,"},{"line_number":29,"context_line":"    help\u003d_(\"The service\u0027s id which is registered in Keystone.\"))"},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"region_id \u003d cfg.StrOpt("},{"line_number":32,"context_line":"    \u0027region_id\u0027,"},{"line_number":33,"context_line":"    help\u003d_(\"The region which the service is located in. It\u0027s from the service\""},{"line_number":34,"context_line":"           \"endpoint in Keystone.\"))"},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"_options \u003d ["},{"line_number":37,"context_line":"    service_id,"}],"source_content_type":"text/x-python","patch_set":7,"id":"3f79a3b5_b7d0852d","line":34,"range":{"start_line":31,"start_character":0,"end_line":34,"end_character":36},"updated":"2018-08-29 14:51:17.000000000","message":"Would it make sense to use the endpoint ID here instead? The region ID is already associated to the endpoint in keystone. \n\nJust to clarify, we need this information so that we can query keystone for the right limits, yeah?","commit_id":"93c92ebe4c78928a86d85fbadc329832606e185c"},{"author":{"_account_id":15054,"name":"wangxiyuan","email":"wangxiyuan1007@gmail.com","username":"wangxiyuan"},"change_message_id":"af03b0ffcc29ecf6d030aa5e590fde916dd47a45","unresolved":false,"context_lines":[{"line_number":28,"context_line":"    \u0027service_id\u0027,"},{"line_number":29,"context_line":"    help\u003d_(\"The service\u0027s id which is registered in Keystone.\"))"},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"region_id \u003d cfg.StrOpt("},{"line_number":32,"context_line":"    \u0027region_id\u0027,"},{"line_number":33,"context_line":"    help\u003d_(\"The region which the service is located in. It\u0027s from the service\""},{"line_number":34,"context_line":"           \"endpoint in Keystone.\"))"},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"_options \u003d ["},{"line_number":37,"context_line":"    service_id,"}],"source_content_type":"text/x-python","patch_set":7,"id":"3f79a3b5_0e7cb8e9","line":34,"range":{"start_line":31,"start_character":0,"end_line":34,"end_character":36},"in_reply_to":"3f79a3b5_b7d0852d","updated":"2018-08-30 08:41:04.000000000","message":"yeah, we need service_id and region_id to query limits.\n\nEndpoint_id is better. I think it\u0027s most clear for service to use.","commit_id":"93c92ebe4c78928a86d85fbadc329832606e185c"}]}