)]}'
{"specs/queens/approved/nova-disk-quota-tracking.rst":[{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"006ba7233af15730c4e2c91050c138c77597c998","unresolved":false,"context_lines":[{"line_number":23,"context_line":"Use Cases"},{"line_number":24,"context_line":"---------"},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"In case we care only about allocated storage in general and not on allocation"},{"line_number":27,"context_line":"means, whether it is Cinder or root disc for VM, we would need a storage quotas"},{"line_number":28,"context_line":"in nova. So, cloud admins will have more flexibility for storage tracking."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"Proposed change"},{"line_number":31,"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_c6057716","line":28,"range":{"start_line":26,"start_character":0,"end_line":28,"end_character":8},"updated":"2017-10-03 22:36:30.000000000","message":"When you say Cinder, I assume you mean Cinder ephemeral storage that is backing VMs. Because quota for number of Cinder volumes and size of Cinder volumes will always be managed in Cinder, not in Nova.","commit_id":"f139abdb1954eaa569ef053e4c79e33a767f214f"},{"author":{"_account_id":8768,"name":"Chris Friesen","email":"chris.friesen@windriver.com","username":"cbf123"},"change_message_id":"34b0a99c45c4232d1e091b4e639db3deb84ff685","unresolved":false,"context_lines":[{"line_number":30,"context_line":"Proposed change"},{"line_number":31,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"It is proposed to create additional quota resource called, for example,"},{"line_number":34,"context_line":"\u0027local_gb\u0027 that will consist of root disc and ephemeral storage, that nova"},{"line_number":35,"context_line":"has been tracking for long time. It will require small update of API, where"},{"line_number":36,"context_line":"we show new quota resource in addition to existing ones and allow to update"},{"line_number":37,"context_line":"it with quota and quota class sets. Also, we will need to create new"},{"line_number":38,"context_line":"configuration option with default value, in the same way it is done for all"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f515b1d_2381dd4b","line":35,"range":{"start_line":33,"start_character":1,"end_line":35,"end_character":75},"updated":"2017-10-03 20:41:24.000000000","message":"It\u0027s not quite that simple.\n\nHow will you handle the accounting for resizes, where you could consume both the old and the new disk space while the resize is in progress?  Would you prevent a resize if it would mean temporarily exceeding the quota?\n\nWhat about accounting for the fact that the worst-case disk consumption is actually 2X the configured consumption...where the backing file is full and the delta file is the same size as the backing file.  Would you use the nominal disk consumption or would it make more sense to use the higher of the nominal/actual consumption?  (And for actual consumption how would you handle backing files shared by multiple instances?)","commit_id":"f139abdb1954eaa569ef053e4c79e33a767f214f"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"006ba7233af15730c4e2c91050c138c77597c998","unresolved":false,"context_lines":[{"line_number":36,"context_line":"we show new quota resource in addition to existing ones and allow to update"},{"line_number":37,"context_line":"it with quota and quota class sets. Also, we will need to create new"},{"line_number":38,"context_line":"configuration option with default value, in the same way it is done for all"},{"line_number":39,"context_line":"other existing quotas."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Alternatives"},{"line_number":42,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f515b1d_5c583af9","line":39,"updated":"2017-10-03 22:36:30.000000000","message":"I think the use case for this makes sense, but I\u0027m concerned about how this fits in at this time with the in-progress work going on in placement.\n\nWe have a long-standing problem in Nova with boot-from-volume instances consuming \"local_gb\" resources [1]. Presently, instances that are booted from volume consume disk resources based on their flavor when they should really be consuming zero disk. This leads to problems where a compute host is considered \"full\" even when none of its local disk has been consumed. If we add disk quota right now, it would be subject to the same problem -- quota would be consumed by boot-from-volume instances when they should be consume zero disk (as Cinder manages volumes).\n\nThere is work in-progress in placement to correctly account for shared storage and treat boot-from-volume properly. There is also a workaround patch proposed [2] which would solve the problem temporarily. I think solving the boot-from-volume problem is a prerequisite for this work, otherwise it opens the possibility for boot-from-volume instances to consume disk quota and cause additional headaches for users.\n\n[1] https://bugs.launchpad.net/nova/+bug/1469179\n[2] https://review.openstack.org/#/c/428481","commit_id":"f139abdb1954eaa569ef053e4c79e33a767f214f"}]}