)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"bb842de8ec214709a09acfed6fca18948cd0db16","unresolved":true,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"If quotas are ignored from a provider, its expected that node"},{"line_number":10,"context_line":"allocations will fail due to quota errors, so it shouldn\u0027t be counted as"},{"line_number":11,"context_line":"a failed attempt to launch the node"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Change-Id: I7e68509c4d4d0278ac2bf672db386951b8ad69c5"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"d0b6fb61_f7e1469f","line":11,"updated":"2023-08-09 14:36:00.000000000","message":"I\u0027m not sure the assertion here is supported by the docs (which says that we check against max-servers).  Can you elaborate on the basis for this?\n\nI think some people set very high attempts values to deal with expected-unexpected quota errors.\n\nIf we wanted to change that (and I\u0027m not sure we do), then this change would need a test to codify and verify the behavior.","commit_id":"2ebe95ac59b295f2ed1831571e565b5185571876"},{"author":{"_account_id":33934,"name":"Joshua Watt","email":"JPEWhacker@gmail.com","username":"jpew"},"change_message_id":"04bdd698173b729b338abf6e3400930281d5bbf6","unresolved":true,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"If quotas are ignored from a provider, its expected that node"},{"line_number":10,"context_line":"allocations will fail due to quota errors, so it shouldn\u0027t be counted as"},{"line_number":11,"context_line":"a failed attempt to launch the node"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Change-Id: I7e68509c4d4d0278ac2bf672db386951b8ad69c5"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"713ab465_38f6e9eb","line":11,"in_reply_to":"5c2ac202_f6e283fc","updated":"2023-08-11 21:20:45.000000000","message":"Yep, you are correct. There is no reason for us to be setting ignore-provider-quota. I removed that and everything works fine. Sorry for the noise.","commit_id":"2ebe95ac59b295f2ed1831571e565b5185571876"},{"author":{"_account_id":33934,"name":"Joshua Watt","email":"JPEWhacker@gmail.com","username":"jpew"},"change_message_id":"b2211c972599ad28e57d29bce425aa2aa4c32ae6","unresolved":true,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"If quotas are ignored from a provider, its expected that node"},{"line_number":10,"context_line":"allocations will fail due to quota errors, so it shouldn\u0027t be counted as"},{"line_number":11,"context_line":"a failed attempt to launch the node"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Change-Id: I7e68509c4d4d0278ac2bf672db386951b8ad69c5"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"8e270c71_696c4632","line":11,"in_reply_to":"d0b6fb61_f7e1469f","updated":"2023-08-09 14:55:25.000000000","message":"In our system, quota is dynamically adjusted based on demand; as such we have to set ignore-provider-quota so that Zuul generates the requests that create the \"pressure\" needed to get more quota when necessary. In the case where there is sufficient capacity to satisfy the quota demands, this reacts quickly enough that there are no problems. However, when OpenStack is at capacity, the quota isn\u0027t going to increase, which means the jobs eventually just fails with NODE_FAILURE, which is not good. In addition, we need to keep up the \"pressure\" to prevent the quota we want from going elsewhere.\n\nSetting a very high attempts value is an option I guess, but it really doesn\u0027t seem like a great solution; If I\u0027m setting the flag that says that I want to ignore the quota, that implies (to me anyway) that quota errors are something you expect to happen at some point; unlike the case where nodepool is attempting to obey the quota and quota error is more exceptional.\n\n\nI don\u0027t think it\u0027s against the docs, according to my reading. IMHO, the docs are clarifying that even when you set ignore-provider-quota, max-server is still respected (as it always is). IOW, ingore-provider-quota doesn\u0027t mean \"ignore max-servers\". My patch doesn\u0027t change this.\n\nYa, I can write tests, just wanted to make sure the idea wasn\u0027t going to get rejected before going through that effort.","commit_id":"2ebe95ac59b295f2ed1831571e565b5185571876"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"e718cc6f6f0eb5ee709216d8859229b7d9779ec1","unresolved":true,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"If quotas are ignored from a provider, its expected that node"},{"line_number":10,"context_line":"allocations will fail due to quota errors, so it shouldn\u0027t be counted as"},{"line_number":11,"context_line":"a failed attempt to launch the node"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Change-Id: I7e68509c4d4d0278ac2bf672db386951b8ad69c5"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"5c2ac202_f6e283fc","line":11,"in_reply_to":"d0b6fb61_f7e1469f","updated":"2023-08-09 22:20:24.000000000","message":"The docs mention that the setting was designed to be used when the provider can not correctly calculate quota.  The actual history is that it was intended to be used when the cloud\u0027s quota system is more complex than Nodepool\u0027s.  For example, the cloud has multiple quota types and Nodepool does not.  Nodepool actually does support multiple quota types now, so these days we would have implemented the fix for the original issue differently without adding the ignore option at all.\n\nBut I digress.\n\nThe upshot is that there are other use cases where users may need to disable quota checks but still don\u0027t expect quota errors, and in those cases, they might prefer the launch to fail so that another launcher can handle the request.  And the original use case for the feature is indeed one of those use cases.\n\nSo if we are to support the use case you describe, it should probably be a new option.\n\nBut I have so many questions about the system you describe.  Chief among them is: why isn\u0027t it sufficient to let nodepool go up to the current quota, have the quota adjusting system notice that and increase the quota, and then have nodepool notice the new quota and start to use new nodes?","commit_id":"2ebe95ac59b295f2ed1831571e565b5185571876"}]}