)]}'
{"specs/rocky/approved/alloc-candidates-member-of.rst":[{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"a7a0e8c95d338a547fb804d3a6521723087cf2c8","unresolved":false,"context_lines":[{"line_number":95,"context_line":"---------------------"},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"We should be able to deprecate the aggregate multi-tenancy isolation scheduler"},{"line_number":98,"context_line":"filter after the \"S\" release."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"Developer impact"},{"line_number":101,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_fca03e94","line":98,"updated":"2018-02-14 21:19:20.000000000","message":"...assuming host aggregates get mirrored into placement.","commit_id":"ea3f940b80555c6bc5d641e886a7b10255d192b7"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"a7a0e8c95d338a547fb804d3a6521723087cf2c8","unresolved":false,"context_lines":[{"line_number":137,"context_line":"Testing"},{"line_number":138,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"Normal functional and unit testing."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"Documentation Impact"},{"line_number":143,"context_line":"\u003d\u003d\u003d\u003d\u003d\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":"3fa0c359_dcc0e22d","line":140,"updated":"2018-02-14 21:19:20.000000000","message":"including gabbits","commit_id":"ea3f940b80555c6bc5d641e886a7b10255d192b7"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"17740c8a232d7efaf80792b281f95803f1752c01","unresolved":false,"context_lines":[{"line_number":43,"context_line":"``member_of`` query `parameter_`. This parameter is \"a string representing an"},{"line_number":44,"context_line":"aggregate uuid; or the prefix in: followed by a comma-separated list of strings"},{"line_number":45,"context_line":"representing aggregate uuids. The returned resource providers must be"},{"line_number":46,"context_line":"associated with at least one of the aggregates identified by uuid.\""},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"We propose to support this exact same parameter for the ``GET"},{"line_number":49,"context_line":"/allocation_candidates`` placement REST API call."}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_1e77e43c","line":46,"updated":"2018-03-20 20:07:16.000000000","message":"So, if I have a request that includes two non-overlapping aggregates, should I only get resource providers that are within both, or that are within either?","commit_id":"6ab0f717d037c15c0c334f0cb15d93f96da7cd10"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"9ac1662083c2a5bad618982c6b251b8fd2a56a3f","unresolved":false,"context_lines":[{"line_number":43,"context_line":"``member_of`` query `parameter_`. This parameter is \"a string representing an"},{"line_number":44,"context_line":"aggregate uuid; or the prefix in: followed by a comma-separated list of strings"},{"line_number":45,"context_line":"representing aggregate uuids. The returned resource providers must be"},{"line_number":46,"context_line":"associated with at least one of the aggregates identified by uuid.\""},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"We propose to support this exact same parameter for the ``GET"},{"line_number":49,"context_line":"/allocation_candidates`` placement REST API call."}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_abf45388","line":46,"in_reply_to":"df7087c5_0b8a1f1a","updated":"2018-03-21 22:40:20.000000000","message":"Well, the thing I care the most about is doable with just what we have now, so I\u0027m not overly flustered. However, I think it would be another nice performance bump to be able to get placement to handle the AZ limit for us, instead of pulling ALL hosts and throwing away a bunch that aren\u0027t in the right AZ.\n\nRight now, I could do that too, but not if both the az and the filter_tenant filters are enabled. So either I have to make them mutually exclusive, or just hold off on the AZ one until we get something else.\n\nAs I say, the filter_tenant one is what I care about the most, and that\u0027s set at the moment, so whatever ya\u0027ll want to do.","commit_id":"6ab0f717d037c15c0c334f0cb15d93f96da7cd10"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"682a68af298c47a6ff2ef7d3e2d31bd9ddb69a38","unresolved":false,"context_lines":[{"line_number":43,"context_line":"``member_of`` query `parameter_`. This parameter is \"a string representing an"},{"line_number":44,"context_line":"aggregate uuid; or the prefix in: followed by a comma-separated list of strings"},{"line_number":45,"context_line":"representing aggregate uuids. The returned resource providers must be"},{"line_number":46,"context_line":"associated with at least one of the aggregates identified by uuid.\""},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"We propose to support this exact same parameter for the ``GET"},{"line_number":49,"context_line":"/allocation_candidates`` placement REST API call."}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_d721384f","line":46,"in_reply_to":"df7087c5_1e77e43c","updated":"2018-03-21 15:54:41.000000000","message":"The way this is implemented is an OR, not an AND. In other words, the SQL query uses an IN(...) expression and therefore produces the union of all providers that are in any of the aggregates specified in member_of\u003din:\u003cagg1, agg2\u003e\n\nWe could theoretically add support for:\n\n member_of\u003dall:\u003cagg1, agg2\u003e\n\nin the future if such functionality is required.","commit_id":"6ab0f717d037c15c0c334f0cb15d93f96da7cd10"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"ddf9774ff1e6b7fd1652f023ab8ba325845ac4b8","unresolved":false,"context_lines":[{"line_number":43,"context_line":"``member_of`` query `parameter_`. This parameter is \"a string representing an"},{"line_number":44,"context_line":"aggregate uuid; or the prefix in: followed by a comma-separated list of strings"},{"line_number":45,"context_line":"representing aggregate uuids. The returned resource providers must be"},{"line_number":46,"context_line":"associated with at least one of the aggregates identified by uuid.\""},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"We propose to support this exact same parameter for the ``GET"},{"line_number":49,"context_line":"/allocation_candidates`` placement REST API call."}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_0b8a1f1a","line":46,"in_reply_to":"df7087c5_57c76813","updated":"2018-03-21 22:33:08.000000000","message":"This can certainly be SQLed.\n\nWorth pointing out that the placement API doesn\u0027t (yet) support any querystrings where you can duplicate keys.  The alternative to preserve this \"policy\" would be imposing a new punctuation mark, like:\n\n member_of\u003dall:foo;in:bar,baz\n\n@Dan, at this point it\u0027s pretty clear that you\u0027re going to need *something* to make your stuff work, yah?  So reasonable or not, let\u0027s get a delta to this spec proposed, and we can bikeshed the syntactic details there.","commit_id":"6ab0f717d037c15c0c334f0cb15d93f96da7cd10"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d68315b9cb0c5b1775183ac2eecc7048120af532","unresolved":false,"context_lines":[{"line_number":43,"context_line":"``member_of`` query `parameter_`. This parameter is \"a string representing an"},{"line_number":44,"context_line":"aggregate uuid; or the prefix in: followed by a comma-separated list of strings"},{"line_number":45,"context_line":"representing aggregate uuids. The returned resource providers must be"},{"line_number":46,"context_line":"associated with at least one of the aggregates identified by uuid.\""},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"We propose to support this exact same parameter for the ``GET"},{"line_number":49,"context_line":"/allocation_candidates`` placement REST API call."}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_57c76813","line":46,"in_reply_to":"df7087c5_d721384f","updated":"2018-03-21 16:05:19.000000000","message":"Right, it\u0027s an OR. So, the problem here is that sometimes I need to be able to require some aggregates specifically, but also request further filtering to one-of-a-set. Take the following example:\n\n 1. User requests AZ foo\n 2. User\u0027s tenant is confined to aggregates bar,baz\n\nI need to be able to say \"it must be in foo\u0026bar or foo\u0026baz\" in order to satisfy that requirement.\n\nI think that if I was able to do two member_of queries, one with in and one with all, then I could do what I need. The above would become:\n\n member_of\u003dall:foo\u0026member_of\u003din:bar,baz\n\nDoes that seem reasonable and like something that could be added to the SQL query?","commit_id":"6ab0f717d037c15c0c334f0cb15d93f96da7cd10"}]}