)]}'
{"specs/queens/approved/instance-max-count-limit.rst":[{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"72ac7c48aeec1e6c43f35b7dd17ba8445ec504d5","unresolved":false,"context_lines":[{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Assuming a case where several hundred or thousand instances are specified"},{"line_number":43,"context_line":"in a single request, quota restrictions aside, this request is sent to the"},{"line_number":44,"context_line":"scheduler for processing via an RPC call from the conductor service."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"That RPC call is subject to the ``rpc_response_timeout`` configuration option"},{"line_number":47,"context_line":"which defaults to 60 seconds. Also, that call from conductor to scheduler"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f515b1d_0a62063f","line":44,"updated":"2017-10-06 23:24:01.000000000","message":"How many requests are sent to the scheduler (might be worth mentioning if its all still 1 request, or has it split into many at this point, since I honestly forget).","commit_id":"8bc101c66874240dc0524acecf060d93393d04e0"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0016bc8a0122c200f4e46cc0b2c114a6edb7f48e","unresolved":false,"context_lines":[{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Assuming a case where several hundred or thousand instances are specified"},{"line_number":43,"context_line":"in a single request, quota restrictions aside, this request is sent to the"},{"line_number":44,"context_line":"scheduler for processing via an RPC call from the conductor service."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"That RPC call is subject to the ``rpc_response_timeout`` configuration option"},{"line_number":47,"context_line":"which defaults to 60 seconds. Also, that call from conductor to scheduler"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f515b1d_208de1d2","line":44,"in_reply_to":"7f515b1d_0a62063f","updated":"2017-10-07 01:47:22.000000000","message":"It\u0027s 1. The RequestSpec sent from conductor to scheduler and that contains the info one what each instance should be, and we also pass a list of instance uuids, which were created in the API before casting to conductor. Those instance uuids are the consumers to resources in placement that the scheduler uses (since pike) to claim resources during scheduling. But yeah all one request.\n\nIf you did:\n\nfor x in range(5):\n    nova boot --flavor 1 --image 2 \"vm%i\" % x\n\nThen you\u0027d have 5 separate requests going to the scheduler.","commit_id":"8bc101c66874240dc0524acecf060d93393d04e0"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"aa2f3ef4772055558a1d2ac2d76aba8096ebead3","unresolved":false,"context_lines":[{"line_number":57,"context_line":"request to be sent again to the scheduler, which is already timing out trying"},{"line_number":58,"context_line":"to process the original request. This was recreated in a simple devstack"},{"line_number":59,"context_line":"patch [3]_ using the FakeDriver virt driver, disabling instance quotas, and"},{"line_number":60,"context_line":"creating instances without networking (to bypass the port quota check)."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"What ends up happening is now that the FilterScheduler is creating allocations"},{"line_number":63,"context_line":"for each instance in the Placement service, eventually those retried duplicate"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bf659307_0360db00","line":60,"updated":"2018-03-27 20:25:47.000000000","message":"I don\u0027t think I understand this. If a single scheduler worker times out processing a large request, shouldn\u0027t it clean up/delete all of the related allocations it created in placement before raising and triggering the retry? That way a retry can\u0027t be requesting duplicate allocations to placement?","commit_id":"8bc101c66874240dc0524acecf060d93393d04e0"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"66df1099e1816f7f1795d3eafb0631960de7f1d9","unresolved":false,"context_lines":[{"line_number":57,"context_line":"request to be sent again to the scheduler, which is already timing out trying"},{"line_number":58,"context_line":"to process the original request. This was recreated in a simple devstack"},{"line_number":59,"context_line":"patch [3]_ using the FakeDriver virt driver, disabling instance quotas, and"},{"line_number":60,"context_line":"creating instances without networking (to bypass the port quota check)."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"What ends up happening is now that the FilterScheduler is creating allocations"},{"line_number":63,"context_line":"for each instance in the Placement service, eventually those retried duplicate"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_e15d0d16","line":60,"in_reply_to":"bf659307_0360db00","updated":"2018-10-03 22:45:26.000000000","message":"The client (conductor) is timing out waiting for the reply to the RPC call and gets a MessagingTimeout. The scheduler worker is still off doing it\u0027s thing trying to process the request. So the server (scheduler worker) is not timed out, the client RPC call response timed out and is retried, which doubles down on the load on the scheduler (and placement).","commit_id":"8bc101c66874240dc0524acecf060d93393d04e0"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"821c040210e442da27f880d52743b1898c69a4d3","unresolved":false,"context_lines":[{"line_number":62,"context_line":"What ends up happening is now that the FilterScheduler is creating allocations"},{"line_number":63,"context_line":"for each instance in the Placement service, eventually those retried duplicate"},{"line_number":64,"context_line":"requests result in ``409 Conflict`` responses from Placement because there"},{"line_number":65,"context_line":"can be multiple greenthreads making the same request on the same instance to"},{"line_number":66,"context_line":"the same resource provider. In the devstack patch there is only a single"},{"line_number":67,"context_line":"compute node resource provider, but in a large production deployment there"},{"line_number":68,"context_line":"would be thousands of compute nodes, and each duplicate request being processed"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f515b1d_3332c411","line":65,"range":{"start_line":65,"start_character":0,"end_line":65,"end_character":29},"updated":"2017-10-09 08:36:29.000000000","message":"We only run one single worker per scheduler service and we serialize the requests by using a semaphore lock. So, even if we use some generators that yielding the destinations, AFAIK we don\u0027t have multiple RPC greenthreads running concurrently for a single service.\n\nHave you seen the above, or is it because we could call the Placement API without having a synchronited method ? If so, looks to me just like a bug.","commit_id":"8bc101c66874240dc0524acecf060d93393d04e0"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"72ac7c48aeec1e6c43f35b7dd17ba8445ec504d5","unresolved":false,"context_lines":[{"line_number":63,"context_line":"for each instance in the Placement service, eventually those retried duplicate"},{"line_number":64,"context_line":"requests result in ``409 Conflict`` responses from Placement because there"},{"line_number":65,"context_line":"can be multiple greenthreads making the same request on the same instance to"},{"line_number":66,"context_line":"the same resource provider. In the devstack patch there is only a single"},{"line_number":67,"context_line":"compute node resource provider, but in a large production deployment there"},{"line_number":68,"context_line":"would be thousands of compute nodes, and each duplicate request being processed"},{"line_number":69,"context_line":"could actually result in instance allocations being made against several"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f515b1d_2adf02d7","line":66,"updated":"2017-10-06 23:24:01.000000000","message":"Seems like a classical case for cross-system-distributed (or even local locks) locking (write lock things before you start writing to them, and do it in the same order).","commit_id":"8bc101c66874240dc0524acecf060d93393d04e0"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0016bc8a0122c200f4e46cc0b2c114a6edb7f48e","unresolved":false,"context_lines":[{"line_number":63,"context_line":"for each instance in the Placement service, eventually those retried duplicate"},{"line_number":64,"context_line":"requests result in ``409 Conflict`` responses from Placement because there"},{"line_number":65,"context_line":"can be multiple greenthreads making the same request on the same instance to"},{"line_number":66,"context_line":"the same resource provider. In the devstack patch there is only a single"},{"line_number":67,"context_line":"compute node resource provider, but in a large production deployment there"},{"line_number":68,"context_line":"would be thousands of compute nodes, and each duplicate request being processed"},{"line_number":69,"context_line":"could actually result in instance allocations being made against several"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f515b1d_c0b72d86","line":66,"in_reply_to":"7f515b1d_2adf02d7","updated":"2017-10-07 01:47:22.000000000","message":"I\u0027m not really sure how much that would help here, it might even hurt depending on where you\u0027re locking and that could make the rpc timeout issue worse. Would have to talk to Jay Pipes. In thinking about this, we might not even be doing the correct thing when the client (the scheduler) gets the 409 from placement - it just retries, but the scheduler client should actually fetch the latest information from placement and see if it\u0027s already the thing it\u0027s trying to PUT, and if so, job done - move on.","commit_id":"8bc101c66874240dc0524acecf060d93393d04e0"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"72ac7c48aeec1e6c43f35b7dd17ba8445ec504d5","unresolved":false,"context_lines":[{"line_number":68,"context_line":"would be thousands of compute nodes, and each duplicate request being processed"},{"line_number":69,"context_line":"could actually result in instance allocations being made against several"},{"line_number":70,"context_line":"different compute nodes, thus affecting the accounting of what is actually"},{"line_number":71,"context_line":"consuming resources from those nodes."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"If by chance one of the concurrent requests fails due to a NoValidHost error,"},{"line_number":74,"context_line":"all of the instance allocations created in that request will be rolled back"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f515b1d_cae98e80","line":71,"updated":"2017-10-06 23:24:01.000000000","message":"Yup, sounds bad.","commit_id":"8bc101c66874240dc0524acecf060d93393d04e0"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"72ac7c48aeec1e6c43f35b7dd17ba8445ec504d5","unresolved":false,"context_lines":[{"line_number":86,"context_line":"my per-request limit is when doing so."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"As an operator, I want to be able to limit the number of instances created"},{"line_number":89,"context_line":"per-request which affect scheduler performance."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Proposed change"},{"line_number":92,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f515b1d_8a8836c6","line":89,"updated":"2017-10-06 23:24:01.000000000","message":"I\u0027m not sure operators actually want this (I certainly wouldn\u0027t), they want it to work correctly for any value and correctly handle all the scenarios automatically (even at extremes).","commit_id":"8bc101c66874240dc0524acecf060d93393d04e0"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"821c040210e442da27f880d52743b1898c69a4d3","unresolved":false,"context_lines":[{"line_number":86,"context_line":"my per-request limit is when doing so."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"As an operator, I want to be able to limit the number of instances created"},{"line_number":89,"context_line":"per-request which affect scheduler performance."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Proposed change"},{"line_number":92,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f515b1d_1e058f11","line":89,"in_reply_to":"7f515b1d_0063051c","updated":"2017-10-09 08:36:29.000000000","message":"I remember some very old discussion we had with operators, and AFAIR operators were saying that what they\u0027d like is maybe some thing like a quota per request.","commit_id":"8bc101c66874240dc0524acecf060d93393d04e0"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0016bc8a0122c200f4e46cc0b2c114a6edb7f48e","unresolved":false,"context_lines":[{"line_number":86,"context_line":"my per-request limit is when doing so."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"As an operator, I want to be able to limit the number of instances created"},{"line_number":89,"context_line":"per-request which affect scheduler performance."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Proposed change"},{"line_number":92,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f515b1d_0063051c","line":89,"in_reply_to":"7f515b1d_8a8836c6","updated":"2017-10-07 01:47:22.000000000","message":"Good point. Wording here is definitely awkward. What I was thinking of was more related to the fact the rpc_response_timeout is static config, but the request is dynamic, so the default rpc_response_timeout for most requests would be fine, but if you have a monster request where someone is trying to create 1000 instances in a single request and it triggers the rpc timeout retry loop of death, then that\u0027s something I\u0027d want to guard against. But as noted below in alternatives, we could possibly chunk the requests to handle this scenario.","commit_id":"8bc101c66874240dc0524acecf060d93393d04e0"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"821c040210e442da27f880d52743b1898c69a4d3","unresolved":false,"context_lines":[{"line_number":91,"context_line":"Proposed change"},{"line_number":92,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Define a configurable per-request ``instance-multi-create`` quota limit,"},{"line_number":95,"context_line":"similar to ``[quota]/metadata_items`` or ``[quota]/injected_files`` which are"},{"line_number":96,"context_line":"only checked per instance create (and rebuild) request."},{"line_number":97,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f515b1d_be3c3bc8","line":94,"range":{"start_line":94,"start_character":36,"end_line":94,"end_character":57},"updated":"2017-10-09 08:36:29.000000000","message":"Like I said above, AFAIR the naming was more something like \"multi-create-instance-per-request\u0027","commit_id":"8bc101c66874240dc0524acecf060d93393d04e0"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"821c040210e442da27f880d52743b1898c69a4d3","unresolved":false,"context_lines":[{"line_number":102,"context_line":"We would also expose the new limit in the ``limits``, ``os-quota-sets`` and"},{"line_number":103,"context_line":"``os-quota-class-sets`` APIs so that a user can discover the value when"},{"line_number":104,"context_line":"making the server create request."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"**Microversion**"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"TODO: This is where things break down. Add new fields to the limits and quota"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f515b1d_5e442747","line":105,"updated":"2017-10-09 08:36:29.000000000","message":"What would be the default for that quota limit ? Since you can only have 10 active instances by default, maybe 10 ? Or just 1, since max_count defaults to min_count which defaults to 1 ?","commit_id":"8bc101c66874240dc0524acecf060d93393d04e0"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"821c040210e442da27f880d52743b1898c69a4d3","unresolved":false,"context_lines":[{"line_number":113,"context_line":"and still potentially stumble into the RPC timeout issue. Or would we honor"},{"line_number":114,"context_line":"the configurable limit as a safety precaution for operators regardless of"},{"line_number":115,"context_line":"microversion requested, but let it be known that users would have to get the"},{"line_number":116,"context_line":"limit value before making requests if they care about the results?"},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"Alternatives"},{"line_number":119,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f515b1d_be6afbaf","line":116,"updated":"2017-10-09 08:36:29.000000000","message":"I\u0027d assume then that we should honor an unlimited quota by default no ?","commit_id":"8bc101c66874240dc0524acecf060d93393d04e0"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"72ac7c48aeec1e6c43f35b7dd17ba8445ec504d5","unresolved":false,"context_lines":[{"line_number":135,"context_line":"  and that those deployments will need to consider setting"},{"line_number":136,"context_line":"  ``rpc_response_timeout`` to a high value. Note that doing that exposes one"},{"line_number":137,"context_line":"  to other issues, like waiting a long time on a response to a dead service."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"- We could add a configuration option for operators to limit the maximum"},{"line_number":140,"context_line":"  number of instances that can be created in a single request. Without"},{"line_number":141,"context_line":"  somehow exposing this value out of the API, however, would not be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f515b1d_2aa6e254","line":138,"updated":"2017-10-06 23:24:01.000000000","message":"Other idea, don\u0027t have the conductor -\u003e scheduler system as RPC in the first place (it doesn\u0027t seem like the concept is right here), treat it as a async request the the conductor \u0027polls\u0027 (even long-polls) the scheduler to determine what/how much has finished.","commit_id":"8bc101c66874240dc0524acecf060d93393d04e0"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0016bc8a0122c200f4e46cc0b2c114a6edb7f48e","unresolved":false,"context_lines":[{"line_number":135,"context_line":"  and that those deployments will need to consider setting"},{"line_number":136,"context_line":"  ``rpc_response_timeout`` to a high value. Note that doing that exposes one"},{"line_number":137,"context_line":"  to other issues, like waiting a long time on a response to a dead service."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"- We could add a configuration option for operators to limit the maximum"},{"line_number":140,"context_line":"  number of instances that can be created in a single request. Without"},{"line_number":141,"context_line":"  somehow exposing this value out of the API, however, would not be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f515b1d_8076d5d7","line":138,"in_reply_to":"7f515b1d_2aa6e254","updated":"2017-10-07 01:47:22.000000000","message":"I assume you mean RPC *calls* - it\u0027s the blocking RPC call that\u0027s the issue which hits the timeout. If we did an RPC cast and then poll for results, sure that\u0027s something else.\n\nThe shitty thing about polling here is if you don\u0027t poll fast enough, you\u0027re spending time saying something is building when it\u0027s just waiting - and people do love counting the milliseconds it takes to create servers in nova.\n\nAn RPC cast with some kind of callback mechanism using event-driven notifications could be cool but would require some thought. And even that would need to timeout at some point.\n\nI realize I\u0027m replying to Mr TaskFlow here too. :)","commit_id":"8bc101c66874240dc0524acecf060d93393d04e0"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"72ac7c48aeec1e6c43f35b7dd17ba8445ec504d5","unresolved":false,"context_lines":[{"line_number":146,"context_line":"  of instances that can be created per request, but would chunk the maximum"},{"line_number":147,"context_line":"  number of instances per request *to the scheduler*. This would essentially"},{"line_number":148,"context_line":"  make the conductor service orchestrate its calls to the scheduler in batches"},{"line_number":149,"context_line":"  based on some configurable amount."},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"Data model impact"},{"line_number":152,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f515b1d_ca6cee09","line":149,"updated":"2017-10-06 23:24:01.000000000","message":"Yes, this seems like a decent start that doesn\u0027t expose the internal problems/bugs/design issues of nova to the users.","commit_id":"8bc101c66874240dc0524acecf060d93393d04e0"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0016bc8a0122c200f4e46cc0b2c114a6edb7f48e","unresolved":false,"context_lines":[{"line_number":146,"context_line":"  of instances that can be created per request, but would chunk the maximum"},{"line_number":147,"context_line":"  number of instances per request *to the scheduler*. This would essentially"},{"line_number":148,"context_line":"  make the conductor service orchestrate its calls to the scheduler in batches"},{"line_number":149,"context_line":"  based on some configurable amount."},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"Data model impact"},{"line_number":152,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f515b1d_e04ea994","line":149,"in_reply_to":"7f515b1d_ca6cee09","updated":"2017-10-07 01:47:22.000000000","message":"Yeah I like this as a starting point too. By default we don\u0027t batch. If you allow super high instance quotas, and don\u0027t want to configure for super high rpc timeouts, then you could use this as a way to say, chunk multi-create instances in batches of quota_instances / some_number_you_are_comfortable_with.\n\ne.g. if your instance quota limit is 100, maybe you set this up to chunk in batches of 10 at a time.\n\nNote again, however, the downside to this is you could be unnecessarily waiting to send those other batches to the scheduler which means they are sitting there that much longer in BUILDING state.","commit_id":"8bc101c66874240dc0524acecf060d93393d04e0"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"72ac7c48aeec1e6c43f35b7dd17ba8445ec504d5","unresolved":false,"context_lines":[{"line_number":175,"context_line":"---------------------"},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"The new limit type and microversion would be exposed in python-novaclient"},{"line_number":178,"context_line":"limit and quotas CLIs and python API bindings."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Performance Impact"},{"line_number":181,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f515b1d_ca450e72","line":178,"updated":"2017-10-06 23:24:01.000000000","message":"I don\u0027t see why this has to be exposed to users at all.","commit_id":"8bc101c66874240dc0524acecf060d93393d04e0"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0016bc8a0122c200f4e46cc0b2c114a6edb7f48e","unresolved":false,"context_lines":[{"line_number":175,"context_line":"---------------------"},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"The new limit type and microversion would be exposed in python-novaclient"},{"line_number":178,"context_line":"limit and quotas CLIs and python API bindings."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Performance Impact"},{"line_number":181,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f515b1d_2054c120","line":178,"in_reply_to":"7f515b1d_ca450e72","updated":"2017-10-07 01:47:22.000000000","message":"If we go with alternatives it wouldn\u0027t have to be - the point of exposing a configurable limit for max_count would be so that a user can query the API to find out what limit they have on specifying a max count of instances in a single request, or if the client needs to do the batching.\n\ne.g. if my quota is 1000 instances but nova is configured to only allow multi-create requests with a max of 100, I\u0027d want to know that so I\u0027m not sending 1000 and getting a 403 response. It\u0027s a discoverability issue.","commit_id":"8bc101c66874240dc0524acecf060d93393d04e0"}]}