)]}'
{"cinder/scheduler/filters/capacity_filter.py":[{"author":{"_account_id":1736,"name":"Ivan Kolodyazhny","email":"e0ne@e0ne.info","username":"e0ne"},"change_message_id":"47b485628444079e16e6d88aa2b9734b26e76d05","unresolved":false,"context_lines":[{"line_number":155,"context_line":"                # capacity is the virtual capacity computed using the"},{"line_number":156,"context_line":"                # over-subscription ratio, minus the space reserved"},{"line_number":157,"context_line":"                # and space already used."},{"line_number":158,"context_line":"                adjusted_free_virtual \u003d ("},{"line_number":159,"context_line":"                    total * backend_state.max_over_subscription_ratio)"},{"line_number":160,"context_line":"                adjusted_free_virtual -\u003d adjusted_free_virtual * reserved"},{"line_number":161,"context_line":"                adjusted_free_virtual -\u003d total - free_space"},{"line_number":162,"context_line":"                res \u003d adjusted_free_virtual \u003e\u003d requested_size"},{"line_number":163,"context_line":"                if not res:"},{"line_number":164,"context_line":"                    msg_args \u003d {\"available\": adjusted_free_virtual,"}],"source_content_type":"text/x-python","patch_set":1,"id":"5fc1f717_c9adb931","line":161,"range":{"start_line":158,"start_character":16,"end_line":161,"end_character":59},"updated":"2019-04-09 18:42:02.000000000","message":"Please, add tests for the new logic","commit_id":"bf9f2ccce2d16466ed138d3512c985b58cc6f28b"},{"author":{"_account_id":10058,"name":"Erlon R. Cruz","email":"erlon.rodrigues.cruz@canonical.com","username":"sombrafam"},"change_message_id":"352686dd58148657ecf5bd650fbeaf5f1aad19ab","unresolved":false,"context_lines":[{"line_number":153,"context_line":"                # accommodate the volume. Adjusted free virtual capacity is"},{"line_number":154,"context_line":"                # the currently available free capacity (taking into account"},{"line_number":155,"context_line":"                # of reserved space) which we can over-subscribe."},{"line_number":156,"context_line":"                adjusted_free_virtual \u003d ("},{"line_number":157,"context_line":"                    free * backend_state.max_over_subscription_ratio)"},{"line_number":158,"context_line":"                res \u003d adjusted_free_virtual \u003e\u003d requested_size"},{"line_number":159,"context_line":"                if not res:"},{"line_number":160,"context_line":"                    msg_args \u003d {\"available\": adjusted_free_virtual,"}],"source_content_type":"text/x-python","patch_set":2,"id":"3fce034c_73bc6069","side":"PARENT","line":157,"range":{"start_line":156,"start_character":16,"end_line":157,"end_character":69},"updated":"2019-04-12 17:18:33.000000000","message":"If \u0027free \u003c 0\u0027, You should not overprovision as you have already exceeded you limit. You should not proceed and return false. If that is the case.\nBut I still wonder how this could be a problem as right bellow this value is being compared with a positive number (requested_size), which will return False. Do you have any details or logs you can share on launchpad?","commit_id":"931816722d43ed866c500a77eaa79b0ed4579bcd"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"b2f6d4ccc1421fee7761ca295bc3b65e7b358783","unresolved":false,"context_lines":[{"line_number":153,"context_line":"                # accommodate the volume. Adjusted free virtual capacity is"},{"line_number":154,"context_line":"                # the currently available free capacity (taking into account"},{"line_number":155,"context_line":"                # of reserved space) which we can over-subscribe."},{"line_number":156,"context_line":"                adjusted_free_virtual \u003d ("},{"line_number":157,"context_line":"                    free * backend_state.max_over_subscription_ratio)"},{"line_number":158,"context_line":"                res \u003d adjusted_free_virtual \u003e\u003d requested_size"},{"line_number":159,"context_line":"                if not res:"},{"line_number":160,"context_line":"                    msg_args \u003d {\"available\": adjusted_free_virtual,"}],"source_content_type":"text/x-python","patch_set":2,"id":"3fce034c_ea4fcb31","side":"PARENT","line":157,"range":{"start_line":156,"start_character":16,"end_line":157,"end_character":69},"in_reply_to":"3fce034c_73bc6069","updated":"2019-04-15 10:15:01.000000000","message":"I don\u0027t think so, \u0027free\u0027 is indicating the free space on the backend based on the effective space available minus the space allocated for the volumes (the virtual space).\n\nSo we probably don\u0027t want to return false is free \u003c 0. What we want is correctly compute the over-subscription which is basically what I\u0027m trying to do with that patch (It may not be the right way to do so).\n\nIt\u0027s easy to reproduce, if you have a backend that have 10GiB with 2.0 over-subscription.\n\nIf we keep the current algorithm, which is:\n\n  adjusted_free_virtual \u003d (\n    free * backend_state.max_over_subscription_ratio)\n  res \u003d adjusted_free_virtual \u003e\u003d requested_size\n  \nNow you allocate 3 volumes of 6 GiB.\n\n- (1): adjusted_free_virtual \u003d 10 * 2.0 \u003d 20  OK since 20 \u003e\u003d 6\n- (2): adjusted_free_virtual \u003d 4 * 2.0 \u003d 8    OK since  8 \u003e\u003d 6 \n- (3): adjusted_free_virtual \u003d -2 * 2.0 \u003d -4  KO since -4 \u003e\u003d 6\n\nThe pass 3 fails where it should work since 3*6\u003d18 and we have a backend of 10Gib with 2.0 over-subscription ratio which means 20GiB.","commit_id":"931816722d43ed866c500a77eaa79b0ed4579bcd"},{"author":{"_account_id":10058,"name":"Erlon R. Cruz","email":"erlon.rodrigues.cruz@canonical.com","username":"sombrafam"},"change_message_id":"fc09475968447e96e54545c140461a8417f45c57","unresolved":false,"context_lines":[{"line_number":153,"context_line":"                # accommodate the volume. Adjusted free virtual capacity is"},{"line_number":154,"context_line":"                # the currently available free capacity (taking into account"},{"line_number":155,"context_line":"                # of reserved space) which we can over-subscribe."},{"line_number":156,"context_line":"                adjusted_free_virtual \u003d ("},{"line_number":157,"context_line":"                    free * backend_state.max_over_subscription_ratio)"},{"line_number":158,"context_line":"                res \u003d adjusted_free_virtual \u003e\u003d requested_size"},{"line_number":159,"context_line":"                if not res:"},{"line_number":160,"context_line":"                    msg_args \u003d {\"available\": adjusted_free_virtual,"}],"source_content_type":"text/x-python","patch_set":2,"id":"3fce034c_f9dfa3d3","side":"PARENT","line":157,"range":{"start_line":156,"start_character":16,"end_line":157,"end_character":69},"in_reply_to":"3fce034c_d3dac615","updated":"2019-04-15 14:45:15.000000000","message":"Free space must never be smaller than 0, by definition. We oversubscribe the free space, which is the calculation being done in the current code. You can not oversubscribe if you don\u0027t have free space.\n\nIn a practical way, the volumes you have just created does not consume space on the storage. The problem here is that this space is subtracted from Cinder as the volume is created and this is the discrepancy that should be solved.","commit_id":"931816722d43ed866c500a77eaa79b0ed4579bcd"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"3eefce387555863734b4c836fc4792a3c6d51160","unresolved":false,"context_lines":[{"line_number":153,"context_line":"                # accommodate the volume. Adjusted free virtual capacity is"},{"line_number":154,"context_line":"                # the currently available free capacity (taking into account"},{"line_number":155,"context_line":"                # of reserved space) which we can over-subscribe."},{"line_number":156,"context_line":"                adjusted_free_virtual \u003d ("},{"line_number":157,"context_line":"                    free * backend_state.max_over_subscription_ratio)"},{"line_number":158,"context_line":"                res \u003d adjusted_free_virtual \u003e\u003d requested_size"},{"line_number":159,"context_line":"                if not res:"},{"line_number":160,"context_line":"                    msg_args \u003d {\"available\": adjusted_free_virtual,"}],"source_content_type":"text/x-python","patch_set":2,"id":"3fce034c_d3dac615","side":"PARENT","line":157,"range":{"start_line":156,"start_character":16,"end_line":157,"end_character":69},"in_reply_to":"3fce034c_ea4fcb31","updated":"2019-04-15 13:24:00.000000000","message":"\u003e That is not how we define \u0027free\u0027 on Cinder. Per our discussions in the past, free_capacity, \"...is the current physical capacity available in the storage array’s pool being used by Cinder. The number and volume sizes of the thin and thick volumes that have been provisioned by Cinder or directly in the storage array are irrelevant here.\"[1], please check the full documents for more details on the scheduler calculations.\n\nErlon, It seems that is exactly what I meant, no? The backend capacity minus the size of the volumes. Since there is a concept of oversubscription we could be in a situation where this value is negative. That is the issue because we apply that negative value with the over-subscription ratio to figure out whether we can schedule the new requested volume.","commit_id":"931816722d43ed866c500a77eaa79b0ed4579bcd"},{"author":{"_account_id":10058,"name":"Erlon R. Cruz","email":"erlon.rodrigues.cruz@canonical.com","username":"sombrafam"},"change_message_id":"9b2ce34271ad886ec99555fdc6038886800b628e","unresolved":false,"context_lines":[{"line_number":153,"context_line":"                # accommodate the volume. Adjusted free virtual capacity is"},{"line_number":154,"context_line":"                # the currently available free capacity (taking into account"},{"line_number":155,"context_line":"                # of reserved space) which we can over-subscribe."},{"line_number":156,"context_line":"                adjusted_free_virtual \u003d ("},{"line_number":157,"context_line":"                    free * backend_state.max_over_subscription_ratio)"},{"line_number":158,"context_line":"                res \u003d adjusted_free_virtual \u003e\u003d requested_size"},{"line_number":159,"context_line":"                if not res:"},{"line_number":160,"context_line":"                    msg_args \u003d {\"available\": adjusted_free_virtual,"}],"source_content_type":"text/x-python","patch_set":2,"id":"3fce034c_b39e1ab6","side":"PARENT","line":157,"range":{"start_line":156,"start_character":16,"end_line":157,"end_character":69},"in_reply_to":"3fce034c_ea4fcb31","updated":"2019-04-15 12:53:39.000000000","message":"That is not how we define \u0027free\u0027 on Cinder. Per our discussions in the past, free_capacity, \"...is the current physical capacity available in the storage array’s pool being used by Cinder. The number and volume sizes of the thin and thick volumes that have been provisioned by Cinder or directly in the storage array are irrelevant here.\"[1], please check the full documents for more details on the scheduler calculations.\n\nSo, if you don\u0027t have free space on your storage you should not allow the creation of more volumes.\n\nWhat you are seeing happens because Cinder keeps the backend.free_space on memory[2] until it gets another update from the driver, which might take up to \u0027periodic_interval\u003d60s\u0027. In this lapse, if you create enough volumes you will get out of \u0027free\u0027 space, even thought you have not really consumed any space on the backend.\n\nWe have discussed  a similar problem in past releases without getting to a solution as the solution wasn\u0027t straightforward. May be what we can is not decrease free space on volume creation, and only use that for calculation of virtual_free.\n\nAnother option you have is not to use the CapacityFilter at all, use the DriverFilter[3] and define a function that fits to you needs.\n \n\n[1] https://specs.openstack.org/openstack/cinder-specs/specs/queens/provisioning-improvements.html\n[2] https://github.com/openstack/cinder/blob/master/cinder/scheduler/host_manager.py#L313\n[3] https://docs.openstack.org/cinder/latest/admin/blockstorage-driver-filter-weighing.html","commit_id":"931816722d43ed866c500a77eaa79b0ed4579bcd"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"40d36144b168e9071eb039a30d2ffde95a9cff19","unresolved":false,"context_lines":[{"line_number":153,"context_line":"                # accommodate the volume. Adjusted free virtual capacity is"},{"line_number":154,"context_line":"                # the currently available free capacity (taking into account"},{"line_number":155,"context_line":"                # of reserved space) which we can over-subscribe."},{"line_number":156,"context_line":"                adjusted_free_virtual \u003d ("},{"line_number":157,"context_line":"                    free * backend_state.max_over_subscription_ratio)"},{"line_number":158,"context_line":"                res \u003d adjusted_free_virtual \u003e\u003d requested_size"},{"line_number":159,"context_line":"                if not res:"},{"line_number":160,"context_line":"                    msg_args \u003d {\"available\": adjusted_free_virtual,"}],"source_content_type":"text/x-python","patch_set":2,"id":"3fce034c_0b4496b6","side":"PARENT","line":157,"range":{"start_line":156,"start_character":16,"end_line":157,"end_character":69},"in_reply_to":"3fce034c_f9dfa3d3","updated":"2019-04-15 15:23:26.000000000","message":"\u003e Free space must never be smaller than 0, by definition. We oversubscribe the free space, which is the calculation being done in the current code. You can not oversubscribe if you don\u0027t have free space.\n\nMy thinking is we can, I tried to show that to you in my example and I responded to Eric, perhaps you could have a second look.\n\n\u003e In a practical way, the volumes you have just created does not consume space on the storage. The problem here is that this space is subtracted from Cinder as the volume is created and this is the discrepancy that should be solved.\n\nYes, but I don\u0027t think that is an issue, we should just be coherent in how we compute new request comming.","commit_id":"931816722d43ed866c500a77eaa79b0ed4579bcd"},{"author":{"_account_id":10058,"name":"Erlon R. Cruz","email":"erlon.rodrigues.cruz@canonical.com","username":"sombrafam"},"change_message_id":"352686dd58148657ecf5bd650fbeaf5f1aad19ab","unresolved":false,"context_lines":[{"line_number":158,"context_line":"                adjusted_free_virtual \u003d ("},{"line_number":159,"context_line":"                    total * backend_state.max_over_subscription_ratio)"},{"line_number":160,"context_line":"                adjusted_free_virtual -\u003d adjusted_free_virtual * reserved"},{"line_number":161,"context_line":"                adjusted_free_virtual -\u003d total - free_space"},{"line_number":162,"context_line":"                res \u003d adjusted_free_virtual \u003e\u003d requested_size"},{"line_number":163,"context_line":"                if not res:"},{"line_number":164,"context_line":"                    msg_args \u003d {\"available\": adjusted_free_virtual,"}],"source_content_type":"text/x-python","patch_set":2,"id":"3fce034c_4dcbb252","line":161,"range":{"start_line":161,"start_character":16,"end_line":161,"end_character":59},"updated":"2019-04-12 17:18:33.000000000","message":"-1: This is not correct. You can not mix total and free_space with the adjusted_free_virtual, which was computed using max_over_subscription_ratio.","commit_id":"40932835a3304c72d0ffe7964fb29d5af799454a"}],"cinder/tests/unit/scheduler/test_host_filters.py":[{"author":{"_account_id":4523,"name":"Eric Harney","email":"eharney@redhat.com","username":"eharney"},"change_message_id":"8cba32453cad5149008392984644b570e9a49b51","unresolved":false,"context_lines":[{"line_number":338,"context_line":"        service \u003d {\u0027disabled\u0027: False}"},{"line_number":339,"context_line":"        host \u003d fakes.FakeBackendState(\u0027host1\u0027,"},{"line_number":340,"context_line":"                                      {\u0027total_capacity_gb\u0027: 500,"},{"line_number":341,"context_line":"                                       \u0027free_capacity_gb\u0027: -350,"},{"line_number":342,"context_line":"                                       \u0027provisioned_capacity_gb\u0027: 400,"},{"line_number":343,"context_line":"                                       \u0027max_over_subscription_ratio\u0027: 2.0,"},{"line_number":344,"context_line":"                                       \u0027reserved_percentage\u0027: 0,"}],"source_content_type":"text/x-python","patch_set":2,"id":"3fce034c_b9091b96","line":341,"range":{"start_line":341,"start_character":59,"end_line":341,"end_character":63},"updated":"2019-04-15 14:38:56.000000000","message":"I don\u0027t believe that any backends are currently expected to return negative values for free_capacity_gb.","commit_id":"40932835a3304c72d0ffe7964fb29d5af799454a"},{"author":{"_account_id":7730,"name":"Sahid Orentino Ferdjaoui","email":"sahid.ferdjaoui@industrialdiscipline.com","username":"sahid"},"change_message_id":"40d36144b168e9071eb039a30d2ffde95a9cff19","unresolved":false,"context_lines":[{"line_number":338,"context_line":"        service \u003d {\u0027disabled\u0027: False}"},{"line_number":339,"context_line":"        host \u003d fakes.FakeBackendState(\u0027host1\u0027,"},{"line_number":340,"context_line":"                                      {\u0027total_capacity_gb\u0027: 500,"},{"line_number":341,"context_line":"                                       \u0027free_capacity_gb\u0027: -350,"},{"line_number":342,"context_line":"                                       \u0027provisioned_capacity_gb\u0027: 400,"},{"line_number":343,"context_line":"                                       \u0027max_over_subscription_ratio\u0027: 2.0,"},{"line_number":344,"context_line":"                                       \u0027reserved_percentage\u0027: 0,"}],"source_content_type":"text/x-python","patch_set":2,"id":"3fce034c_eb1b4a18","line":341,"range":{"start_line":341,"start_character":59,"end_line":341,"end_character":63},"in_reply_to":"3fce034c_b9091b96","updated":"2019-04-15 15:23:26.000000000","message":"I think we can and our problem is we apply the over-subscription ratio on it. The free capacity is the backend capacity minus the size of volumes scheduled on that backend [0].\n\nI provided an example, let me re-use a modified version here:\n\nIf you have a backend that has 10GiB with 2.0 over-subscription. Now you allocate 3 volumes of 6 GiB.\n\n 1) request \u003d 6, free_capacity \u003d 10, adjusted_free \u003d 20 OK\n 2) request \u003d 6, free_capacity \u003d 4,  adjusted_free \u003d  8 OK\n 3) request \u003d 6, free_capacity \u003d -2, adjusted_free \u003d -4 KO\n\nMy patch is fixing that so:\n\n 1) request \u003d 6, free_capacity \u003d 10, adjusted_free \u003d 20 OK\n 2) request \u003d 6, free_capacity \u003d 4,  adjusted_free \u003d 14 OK\n 3) request \u003d 6, free_capacity \u003d -2, adjusted_free \u003d  8 OK\n\nIt\u0027s I guess the behavior that we want when we use over-subscription, what do you think?\n\n[0] https://github.com/openstack/cinder/blob/master/cinder/scheduler/host_manager.py#L313","commit_id":"40932835a3304c72d0ffe7964fb29d5af799454a"}]}