)]}'
{"doc/source/specs/ussuri/flexible-reservation-usage-enforcement.rst":[{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"717fe035bd5f2d41fe891443af1e7c2969a8a40c","unresolved":false,"context_lines":[{"line_number":32,"context_line":"Use Cases"},{"line_number":33,"context_line":"---------"},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"To ensure good resource sharing between users, an operator may want to apply"},{"line_number":36,"context_line":"policies such as:"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"* limiting the duration of reservations"},{"line_number":39,"context_line":"* limiting the size (number of hosts, instances, floating IPs) of reservations"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_9cfc8bbd","line":36,"range":{"start_line":35,"start_character":47,"end_line":36,"end_character":8},"updated":"2020-02-18 06:40:37.000000000","message":"How does the operator change their custom policies? It should be in scope of this spec but I\u0027m not sure if it Is already written in this proposed spec.","commit_id":"728d3c9322e1cbe7541fe3994a1f0a2fb6f0c912"},{"author":{"_account_id":29100,"name":"Jason Anderson","email":"jasonanderson@uchicago.edu","username":"jasonanderson"},"change_message_id":"3bcc345089801a7f6f97741335c6c8121a6c05e8","unresolved":false,"context_lines":[{"line_number":32,"context_line":"Use Cases"},{"line_number":33,"context_line":"---------"},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"To ensure good resource sharing between users, an operator may want to apply"},{"line_number":36,"context_line":"policies such as:"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"* limiting the duration of reservations"},{"line_number":39,"context_line":"* limiting the size (number of hosts, instances, floating IPs) of reservations"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_6c647621","line":36,"range":{"start_line":35,"start_character":47,"end_line":36,"end_character":8},"in_reply_to":"3fa7e38b_9cfc8bbd","updated":"2020-02-18 17:26:07.000000000","message":"I think this became more clear later, but the policies are changed by the operator changing the code or configuration of their externally-provided policy service.","commit_id":"728d3c9322e1cbe7541fe3994a1f0a2fb6f0c912"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"717fe035bd5f2d41fe891443af1e7c2969a8a40c","unresolved":false,"context_lines":[{"line_number":80,"context_line":"3. On lease end, send the lease and its reservations and current allocated"},{"line_number":81,"context_line":"   resources to the usage service. The response in this case does not affect"},{"line_number":82,"context_line":"   the rest of the lease lifecycle and the lease should continue its on_end"},{"line_number":83,"context_line":"   actions. This integration point acts more like a notification."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Usage service API"},{"line_number":86,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_bc0147b7","line":83,"range":{"start_line":83,"start_character":35,"end_line":83,"end_character":64},"updated":"2020-02-18 06:40:37.000000000","message":"So, I guess you assumed the proposed usage service could *NOT* access to the blazar DB. Is that right? If so, I think this can be implemented out of Blazar project.\nIOW, I could not get what is the proposed change to Blazar from this spec.\n\n[later]\nAh, I think I got it. You are going to have your own usage service completely *EXTERNALLY* deployed so that the blazar\u0027s change would be only several changes to call that usage service. So the proposed three APIs are not for blazar itself but for the usage service. And that usage service has several interface for operators to change the custom policies which is not written in the spec, right?\n\nHowever, I don\u0027t think we want every operator who use Blazar to develop such a usage service, so I think it is better to implement the proposed checks within Blazar without external service and instead we can change Blazar to have additional APIs to get operators\u0027 custom policies, no?","commit_id":"728d3c9322e1cbe7541fe3994a1f0a2fb6f0c912"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"48d759abda3ed417f2b3d5bb8c2356e93fab8af4","unresolved":false,"context_lines":[{"line_number":80,"context_line":"3. On lease end, send the lease and its reservations and current allocated"},{"line_number":81,"context_line":"   resources to the usage service. The response in this case does not affect"},{"line_number":82,"context_line":"   the rest of the lease lifecycle and the lease should continue its on_end"},{"line_number":83,"context_line":"   actions. This integration point acts more like a notification."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Usage service API"},{"line_number":86,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_cffd5271","line":83,"range":{"start_line":83,"start_character":35,"end_line":83,"end_character":64},"in_reply_to":"3fa7e38b_826c19d0","updated":"2020-02-19 05:47:38.000000000","message":"\u003e 1. The types of policies can be incredibly varied and are difficult\n \u003e to model generically. \n\nRight, then I would take the second alternative. See below.","commit_id":"728d3c9322e1cbe7541fe3994a1f0a2fb6f0c912"},{"author":{"_account_id":29100,"name":"Jason Anderson","email":"jasonanderson@uchicago.edu","username":"jasonanderson"},"change_message_id":"3bcc345089801a7f6f97741335c6c8121a6c05e8","unresolved":false,"context_lines":[{"line_number":80,"context_line":"3. On lease end, send the lease and its reservations and current allocated"},{"line_number":81,"context_line":"   resources to the usage service. The response in this case does not affect"},{"line_number":82,"context_line":"   the rest of the lease lifecycle and the lease should continue its on_end"},{"line_number":83,"context_line":"   actions. This integration point acts more like a notification."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Usage service API"},{"line_number":86,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_826c19d0","line":83,"range":{"start_line":83,"start_character":35,"end_line":83,"end_character":64},"in_reply_to":"3fa7e38b_bc0147b7","updated":"2020-02-18 17:26:07.000000000","message":"\u003e Ah, I think I got it. You are going to have your own usage service\n \u003e completely *EXTERNALLY* deployed so that the blazar\u0027s change would\n \u003e be only several changes to call that usage service. So the proposed\n \u003e three APIs are not for blazar itself but for the usage service. And\n \u003e that usage service has several interface for operators to change\n \u003e the custom policies which is not written in the spec, right?\n\nYes, exactly. The interface for the operator to change their custom policies is left unspecified as it is the operator\u0027s decision. It could be as simple as hard-coding in a service or as complex as building a full UI that allows another employee to manage. This also allows integration against existing external services, e.g. an HPC allocation tracker.\n\n \u003e However, I don\u0027t think we want every operator who use Blazar to\n \u003e develop such a usage service, so I think it is better to implement\n \u003e the proposed checks within Blazar without external service and\n \u003e instead we can change Blazar to have additional APIs to get\n \u003e operators\u0027 custom policies, no?\n\nWhat form do the policies take in this scenario? We initially discussed such an idea and it is presented later in the spec as an alternative, though perhaps without much elaboration.\n\nI agree that requiring the development of such a service puts additional implementation burden on operators. That\u0027s why I think a future spec should be created to develop an example/default implementation of this service that can be deployed alongside (or within) Blazar. However, I think ultimately supporting an external service is the right choice for a few reasons:\n\n1. The types of policies can be incredibly varied and are difficult to model generically. Consider policies around # of simultaneous reservations allowed, or # of simultaneous nodes allowed, or maybe some users are allowed to reserve from a specific IP range but others are not. Then there are limits on reservation length or under what circumstances a lease can be prolonged. We have implemented most of the above at some point as part of our efforts to manage demand for resources on our cloud (via patches to Blazar and more \"hacky\" solutions where leases are \"reaped\" after they are created). There are likely other scenarios that would be useful or obvious to other operators, which are not yet obvious to us.\n\n2. External services are already used in many HPC centers. Central accounting is a pattern in use by e.g., European Grid Infrastructure (EGI) and XSEDE/Jetstream. Central accounting is important because there may be multiple OpenStack clouds that can be used by a single user/project, but there is one budget that applies to them all. In this case, a policy should not be managed solely by a single Blazar deployment, as it doesn\u0027t have the \"full picture.\"","commit_id":"728d3c9322e1cbe7541fe3994a1f0a2fb6f0c912"},{"author":{"_account_id":15197,"name":"Pierre Riteau","email":"pierre@stackhpc.com","username":"priteau","status":"StackHPC"},"change_message_id":"80609e2f3aa598c51dae00ced13721c759bfc502","unresolved":false,"context_lines":[{"line_number":99,"context_line":"A Keystone token for the ``blazar`` service user will be sent to the usage"},{"line_number":100,"context_line":"service via the ``X-Auth-Token`` header for all endpoints."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Lease, reservation, and allocation information will be passed to each endpoint."},{"line_number":103,"context_line":"For leases and reservations, the subset of user-controllable attributes (e.g.,"},{"line_number":104,"context_line":"``start_date``, ``end_date``, ``resource_type`` and plugin-specific reservation"},{"line_number":105,"context_line":"attributes) will be passed to the usage service; UUIDs and other internal"},{"line_number":106,"context_line":"bookkeeping attributes such as ``created_at`` will not be sent. Each allocation"},{"line_number":107,"context_line":"object will similarly contain the relevant operator-defined attributes, e.g.,"},{"line_number":108,"context_line":"``hypervisor_properties`` for ``physical:host`` reservations and"},{"line_number":109,"context_line":"``floating_network_id`` for ``virtual:floatingip`` reservations. If extra"},{"line_number":110,"context_line":"capabilities are defined for the resource, they will additionally be sent. This"},{"line_number":111,"context_line":"allows for operator-defined custom metadata to be tagged to resources and later"},{"line_number":112,"context_line":"utilized when determining policy decisions."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"* ``POST /v1/check-create``"},{"line_number":115,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"1fa4df85_97442f1d","line":112,"range":{"start_line":102,"start_character":0,"end_line":112,"end_character":43},"updated":"2020-02-27 14:03:35.000000000","message":"If the usage service is meant to be shared by multiple Blazar deployments, whether from the same cloud (in different regions) or from multiple clouds, there should be some way to identify where the request came from.\n\nI would include region_name and some way to identify the cloud, maybe via its auth_url.","commit_id":"728d3c9322e1cbe7541fe3994a1f0a2fb6f0c912"},{"author":{"_account_id":15197,"name":"Pierre Riteau","email":"pierre@stackhpc.com","username":"priteau","status":"StackHPC"},"change_message_id":"f75c69f3fef4a5abd7c094a9bc3f3d3d0bc8d06b","unresolved":false,"context_lines":[{"line_number":220,"context_line":"          }"},{"line_number":221,"context_line":"        ]"},{"line_number":222,"context_line":"      },"},{"line_number":223,"context_line":"      \"next_state\": {"},{"line_number":224,"context_line":"        \"start_date\": \"2020-05-13 00:00\","},{"line_number":225,"context_line":"        \"end_time\": \"2020-05-14 23:59\","},{"line_number":226,"context_line":"        \"reservations\": ["}],"source_content_type":"text/x-rst","patch_set":3,"id":"1fa4df85_680e7233","line":223,"range":{"start_line":223,"start_character":0,"end_line":223,"end_character":21},"updated":"2020-02-27 16:09:01.000000000","message":"Nit: I would call this and the state key:\n\ncurrent_state / requested_state","commit_id":"728d3c9322e1cbe7541fe3994a1f0a2fb6f0c912"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"48d759abda3ed417f2b3d5bb8c2356e93fab8af4","unresolved":false,"context_lines":[{"line_number":326,"context_line":"The advantage of this approach is that it doesn\u0027t require to operate a separate"},{"line_number":327,"context_line":"web service."},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"The disadvantage is that the tighter coupling of Python code may require more"},{"line_number":330,"context_line":"effort from operators to keep up to date when upgrading to new Blazar releases."},{"line_number":331,"context_line":"It also makes it more complex to use deploy Blazar, particularly when using"},{"line_number":332,"context_line":"containers."},{"line_number":333,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_cf22320f","line":330,"range":{"start_line":329,"start_character":25,"end_line":330,"end_character":79},"updated":"2020-02-19 05:47:38.000000000","message":"I think this is only the case when you implement this out of the Blazar master branch, isn\u0027t it? As long as this is in Blazar\u0027s master, we take care not to break the interface and points to take care is just the format of contents of passed arguments (reservation/lease dictionary) and in this aspect the service/plugin update is necessary regardless of whether the interface is RESTful (service) or a function (plugin). I even  think changing the REST API needs more work than function-API change.\n\nAnd another reason why I\u0027m reluctant is it results in database duplication between the usage and blazar service, which would lead to a lot of codes to avoid inconsistency and would be bugbear.\n\nThoughts?","commit_id":"728d3c9322e1cbe7541fe3994a1f0a2fb6f0c912"},{"author":{"_account_id":15197,"name":"Pierre Riteau","email":"pierre@stackhpc.com","username":"priteau","status":"StackHPC"},"change_message_id":"80609e2f3aa598c51dae00ced13721c759bfc502","unresolved":false,"context_lines":[{"line_number":326,"context_line":"The advantage of this approach is that it doesn\u0027t require to operate a separate"},{"line_number":327,"context_line":"web service."},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"The disadvantage is that the tighter coupling of Python code may require more"},{"line_number":330,"context_line":"effort from operators to keep up to date when upgrading to new Blazar releases."},{"line_number":331,"context_line":"It also makes it more complex to use deploy Blazar, particularly when using"},{"line_number":332,"context_line":"containers."},{"line_number":333,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"1fa4df85_b7d28b5b","line":330,"range":{"start_line":329,"start_character":25,"end_line":330,"end_character":79},"in_reply_to":"1fa4df85_74219f9f","updated":"2020-02-27 14:03:35.000000000","message":"\u003e TL; DR: I think the discussion for service or plugin topic needs\n \u003e more opinion from other reviewers.\n\nHaving implemented the plugin approach before for Chameleon, I lean towards the service approach. I believe it will provide a better separation of concerns and make it easier to deploy Blazar (no need to ship extra code).\n\nOne middle ground could be to have calls to the external service implemented as a plugin. This way it would be possible to override it with a custom plugin if that is what operators want to do.","commit_id":"728d3c9322e1cbe7541fe3994a1f0a2fb6f0c912"},{"author":{"_account_id":15197,"name":"Pierre Riteau","email":"pierre@stackhpc.com","username":"priteau","status":"StackHPC"},"change_message_id":"9c01175ca52bcb45d90723892e2a05e7e81cb6be","unresolved":false,"context_lines":[{"line_number":326,"context_line":"The advantage of this approach is that it doesn\u0027t require to operate a separate"},{"line_number":327,"context_line":"web service."},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"The disadvantage is that the tighter coupling of Python code may require more"},{"line_number":330,"context_line":"effort from operators to keep up to date when upgrading to new Blazar releases."},{"line_number":331,"context_line":"It also makes it more complex to use deploy Blazar, particularly when using"},{"line_number":332,"context_line":"containers."},{"line_number":333,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"1fa4df85_f44fa1ba","line":330,"range":{"start_line":329,"start_character":25,"end_line":330,"end_character":79},"in_reply_to":"1fa4df85_74219f9f","updated":"2020-02-27 13:35:21.000000000","message":"\u003e Totally agreed with this. But if it doesn\u0027t have a database, I\n \u003e don\u0027t get why such \"POST /v1/on-end\" API is needed. I thought this\n \u003e is needed just to update and synchronize the usage database with\n \u003e Blazar\u0027s. Maybe I\u0027m missing something... I\u0027d like this spec to\n \u003e clear which part of usage service part and blazar part it describes\n \u003e so that I can see what is necessary for community and what is\n \u003e necessary for operators.\n\nThe external service may be tracking some other information, for example the credit balance of each project. As mentioned elsewhere in the spec, if each reservation takes away credit from the balance, an early end would need to refund the unused credits.","commit_id":"728d3c9322e1cbe7541fe3994a1f0a2fb6f0c912"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"485de9b9832ac3e976f5bfb91e80644952f635e5","unresolved":false,"context_lines":[{"line_number":326,"context_line":"The advantage of this approach is that it doesn\u0027t require to operate a separate"},{"line_number":327,"context_line":"web service."},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"The disadvantage is that the tighter coupling of Python code may require more"},{"line_number":330,"context_line":"effort from operators to keep up to date when upgrading to new Blazar releases."},{"line_number":331,"context_line":"It also makes it more complex to use deploy Blazar, particularly when using"},{"line_number":332,"context_line":"containers."},{"line_number":333,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"1fa4df85_74219f9f","line":330,"range":{"start_line":329,"start_character":25,"end_line":330,"end_character":79},"in_reply_to":"3fa7e38b_6f82e804","updated":"2020-02-25 05:01:14.000000000","message":"TL; DR: I think the discussion for service or plugin topic needs more opinion from other reviewers.\n\n \u003e Each major release would require rebasing or cherry-picking any commits that touch the usage enforcement layer. \n\nAs long as it is designed as a plugin with a clear interface, this efforts can be kept small. On the other hand, with the usage service architecture, the json scheme for the new usage service, e.g. for /v1/check-update API, should catch up with a new scheme when new features (query parameters) are added to Blazar. This means we need to take care of (IOW: document, test and review) the REST API of the usage service as well as Blazar\u0027s REST API every time we add a feature into Blazar.\n\n \u003e Any function/module could be imported and referenced, meaning future changes to unrelated Blazar functionality can break enforcement. \n\nAny function/module could be imported and referenced, letting operators easily catch up with new features. What we need is to have CI tests not to break the enforcement. Having another service makes it more difficult to test and debug the failure that happens in the Zuul gate.\n\n \u003e it could pause execution if implemented poorly\n\nI think this is a bug to be fixed. As long as we use that usage check and the usage check fails due to unknown issue, fail first is the right thing to do. If operators don\u0027t think so and if it is plugin-designed, they can just use another thread to execute the check since it is up to operators.\n\n \u003e it\u0027s unnecessary/bad design to store anything Blazar already is tracking.\n\nTotally agreed with this. But if it doesn\u0027t have a database, I don\u0027t get why such \"POST /v1/on-end\" API is needed. I thought this is needed just to update and synchronize the usage database with Blazar\u0027s. Maybe I\u0027m missing something... I\u0027d like this spec to clear which part of usage service part and blazar part it describes so that I can see what is necessary for community and what is necessary for operators.","commit_id":"728d3c9322e1cbe7541fe3994a1f0a2fb6f0c912"},{"author":{"_account_id":29100,"name":"Jason Anderson","email":"jasonanderson@uchicago.edu","username":"jasonanderson"},"change_message_id":"c600dc96064315e2e3fbf261297b546420b0f154","unresolved":false,"context_lines":[{"line_number":326,"context_line":"The advantage of this approach is that it doesn\u0027t require to operate a separate"},{"line_number":327,"context_line":"web service."},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"The disadvantage is that the tighter coupling of Python code may require more"},{"line_number":330,"context_line":"effort from operators to keep up to date when upgrading to new Blazar releases."},{"line_number":331,"context_line":"It also makes it more complex to use deploy Blazar, particularly when using"},{"line_number":332,"context_line":"containers."},{"line_number":333,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa7e38b_6f82e804","line":330,"range":{"start_line":329,"start_character":25,"end_line":330,"end_character":79},"in_reply_to":"3fa7e38b_cf22320f","updated":"2020-02-21 20:03:50.000000000","message":"Additional effort is needed mostly in regards to packaging and maintaining forks. Each major release would require rebasing or cherry-picking any commits that touch the usage enforcement layer. Over time, the operators may be making many changes to that layer, with each atomic commit adding more maintenance burden. This is itself another kind of a bugbear.\n\nThere are other drawbacks to this approach. For one, I would argue that it makes it too easy for implementors of the enforcement layer to break Blazar\u0027s abstraction layer. Any function/module could be imported and referenced, meaning future changes to unrelated Blazar functionality can break enforcement. For this reason I typically am in favor of abstracting at the level of published HTTP-based interfaces.\n\nAnother consideration is availability. Even if the enforcement layer does not raise exceptions (which we can deal with in Blazar logic), it could pause execution if implemented poorly, such as waiting for a very long time for some sort of response from an external service. If the enforcement layer is itself a separate HTTP service, Blazar has the ability to easily set timeouts and deal with errors (such as allowing the request, as controlled by ``allow_on_error``). It is more difficult to enforce such time-related constraints when the logic is internal to Blazar via custom patches we don\u0027t have control over.\n\nI am personally not concerned about database duplication, because I don\u0027t see any reason why any data would need to be stored by the enforcement layer and would argue it\u0027s unnecessary/bad design to store anything Blazar already is tracking. Blazar will send as much relevant information as possible to the enforcement service so that it is not necessary to store state. If the enforcement layer wants to pull additional state from Blazar, such as the other pending leases owned by the user, it can call Blazar itself using the user\u0027s token.\n\nMaintaining another service is not a design decision I take lightly. There are obvious trade-offs but I think they are the right trade-offs in this use-case. I would be open to an approach where we load a usage extension via stevedore and require operators implement their code as a Python module. This still means that things like service timeouts in the extension layer can cause denial of availability to Blazar, and implementors can still import Blazar functions/modules, but at least they don\u0027t have to maintain custom patches to provide the enforcement capability.","commit_id":"728d3c9322e1cbe7541fe3994a1f0a2fb6f0c912"},{"author":{"_account_id":15197,"name":"Pierre Riteau","email":"pierre@stackhpc.com","username":"priteau","status":"StackHPC"},"change_message_id":"80609e2f3aa598c51dae00ced13721c759bfc502","unresolved":false,"context_lines":[{"line_number":437,"context_line":"References"},{"line_number":438,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":439,"context_line":""},{"line_number":440,"context_line":"1. IRC meeting discussion: http://eavesdrop.openstack.org/meetings/blazar/2019/blazar.2019-05-23-16.00.log.html"},{"line_number":441,"context_line":""},{"line_number":442,"context_line":"History"},{"line_number":443,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1fa4df85_d434e5fd","line":440,"updated":"2020-02-27 14:03:35.000000000","message":"I suggest adding as reference the specs for Nova vendordata2, which uses a similar approach.\n\nhttps://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/vendordata-reboot.html\nhttps://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/vendordata-reboot-ocata.html","commit_id":"728d3c9322e1cbe7541fe3994a1f0a2fb6f0c912"},{"author":{"_account_id":15197,"name":"Pierre Riteau","email":"pierre@stackhpc.com","username":"priteau","status":"StackHPC"},"change_message_id":"d9e5e78c19fe9f41b424e24eb79ec3a1265d456b","unresolved":false,"context_lines":[{"line_number":86,"context_line":"   lease and its reservations and candidate resources will be passed to the"},{"line_number":87,"context_line":"   set of enforcement filters. If all of the filters pass the request, Blazar"},{"line_number":88,"context_line":"   will create the allocations and transition the lease and reservations to the"},{"line_number":89,"context_line":"   PENDING state as usual. If any filter rejects the request, then the lease"},{"line_number":90,"context_line":"   will transition to the ERROR state, with a message from the failed filter"},{"line_number":91,"context_line":"   included in the error raised to the user."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"2. During lease update, after allocation candidates have been selected, both"},{"line_number":94,"context_line":"   the prior lease/reservations/allocations and the new proposed values will"}],"source_content_type":"text/x-rst","patch_set":4,"id":"df33271e_41ae3798","line":91,"range":{"start_line":89,"start_character":27,"end_line":91,"end_character":44},"updated":"2020-03-30 21:01:57.000000000","message":"To be more precise, a lease which is rejected doesn\u0027t get created in the database at all. Can be fixed in a follow-up patch.","commit_id":"773ae05338fc780c5839c498628920c0dab5981e"}]}