)]}'
{"specs/stein/approved/ironic-conductor-groups.rst":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d6c05159adaa123488b08481e1aa882866ca7654","unresolved":false,"context_lines":[{"line_number":50,"context_line":"of the current code, which fetches a list of all compute services running the"},{"line_number":51,"context_line":"ironic driver from the database. To ensure that the hash ring splits nodes only"},{"line_number":52,"context_line":"between currently running compute services, we will check this list against the"},{"line_number":53,"context_line":"database and filter out any inactive services listed in ``peer_list``."},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"Both options will be \"mutable\", meaning it only requires a SIGHUP to update the"},{"line_number":56,"context_line":"running service with new config values."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_99698d27","line":53,"range":{"start_line":53,"start_character":28,"end_line":53,"end_character":36},"updated":"2018-10-11 14:02:53.000000000","message":"Does this mean inactive in the \"service hasn\u0027t reported in $interval seconds\" sort of sense?","commit_id":"3dbf47527b5e7888fda667897a1e1c8cbb6e1ea0"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"89ee11724cc4022d405a41388405307f615553f5","unresolved":false,"context_lines":[{"line_number":50,"context_line":"of the current code, which fetches a list of all compute services running the"},{"line_number":51,"context_line":"ironic driver from the database. To ensure that the hash ring splits nodes only"},{"line_number":52,"context_line":"between currently running compute services, we will check this list against the"},{"line_number":53,"context_line":"database and filter out any inactive services listed in ``peer_list``."},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"Both options will be \"mutable\", meaning it only requires a SIGHUP to update the"},{"line_number":56,"context_line":"running service with new config values."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_5f975547","line":53,"range":{"start_line":53,"start_character":28,"end_line":53,"end_character":36},"in_reply_to":"3f79a3b5_99698d27","updated":"2018-10-11 14:54:46.000000000","message":"We currently check it with `self.servicegroup_api.service_is_up(svc), so yes. Will clarify.","commit_id":"3dbf47527b5e7888fda667897a1e1c8cbb6e1ea0"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"f523987aeab9c1d58205f9ced606ac80c5b70b11","unresolved":false,"context_lines":[{"line_number":45,"context_line":"of nodes which a given nova-compute service is managing, we need a mechanism to"},{"line_number":46,"context_line":"tell the service which other compute services are managing the same"},{"line_number":47,"context_line":"``partition_key``. To do this, we will add another configuration option,"},{"line_number":48,"context_line":"``peer_list``, which is a comma-separated list of hostnames of other compute"},{"line_number":49,"context_line":"services managing the same subset of nodes. If set, this will be used instead"},{"line_number":50,"context_line":"of the current code, which fetches a list of all compute services running the"},{"line_number":51,"context_line":"ironic driver from the database. To ensure that the hash ring splits nodes only"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_44442c9f","line":48,"range":{"start_line":48,"start_character":26,"end_line":48,"end_character":59},"updated":"2018-10-15 14:26:32.000000000","message":"Every time we require configuration like this, a sad panda sighs inside me. I guess we don\u0027t have a way to put additional information into a nova compute service record, do we?","commit_id":"812689c0da4cca0bd545057cc8918b9ac864ba62"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"d11bc10e29c8c3225712ffd3c8c4498e4f735b7d","unresolved":false,"context_lines":[{"line_number":45,"context_line":"of nodes which a given nova-compute service is managing, we need a mechanism to"},{"line_number":46,"context_line":"tell the service which other compute services are managing the same"},{"line_number":47,"context_line":"``partition_key``. To do this, we will add another configuration option,"},{"line_number":48,"context_line":"``peer_list``, which is a comma-separated list of hostnames of other compute"},{"line_number":49,"context_line":"services managing the same subset of nodes. If set, this will be used instead"},{"line_number":50,"context_line":"of the current code, which fetches a list of all compute services running the"},{"line_number":51,"context_line":"ironic driver from the database. To ensure that the hash ring splits nodes only"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_cac2d702","line":48,"range":{"start_line":48,"start_character":26,"end_line":48,"end_character":59},"in_reply_to":"3f79a3b5_2ffda4b1","updated":"2018-10-23 16:48:01.000000000","message":"We already have the cpu_info field in the hypervisors API which is hypervisor-specific, but I guess I could see people not wanting to make that any worse since generally anything hypervisor-specific in the API is bad.","commit_id":"812689c0da4cca0bd545057cc8918b9ac864ba62"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"8c593289923eee40aa920e74f4ad4ae11e1b4596","unresolved":false,"context_lines":[{"line_number":45,"context_line":"of nodes which a given nova-compute service is managing, we need a mechanism to"},{"line_number":46,"context_line":"tell the service which other compute services are managing the same"},{"line_number":47,"context_line":"``partition_key``. To do this, we will add another configuration option,"},{"line_number":48,"context_line":"``peer_list``, which is a comma-separated list of hostnames of other compute"},{"line_number":49,"context_line":"services managing the same subset of nodes. If set, this will be used instead"},{"line_number":50,"context_line":"of the current code, which fetches a list of all compute services running the"},{"line_number":51,"context_line":"ironic driver from the database. To ensure that the hash ring splits nodes only"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_6f3a2398","line":48,"range":{"start_line":48,"start_character":26,"end_line":48,"end_character":59},"in_reply_to":"3f79a3b5_44442c9f","updated":"2018-10-17 18:47:05.000000000","message":"Sure we could:\n\nhttps://developer.openstack.org/api-ref/compute/#update-compute-service\n\nIt could also be a compute host aggregate in nova with a special metadata key and then members of that aggregate are peers in the conductor group. The problem is aggregates are defined in the API DB and nova-compute services are in the cell DB, so if the compute service needs to know it\u0027s peer list, that information needs to be sent down from the API (or shared in something like etcd as was mentioned).","commit_id":"812689c0da4cca0bd545057cc8918b9ac864ba62"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"38bc4e97c76fe3d250f32509735e7f43bd16d1aa","unresolved":false,"context_lines":[{"line_number":45,"context_line":"of nodes which a given nova-compute service is managing, we need a mechanism to"},{"line_number":46,"context_line":"tell the service which other compute services are managing the same"},{"line_number":47,"context_line":"``partition_key``. To do this, we will add another configuration option,"},{"line_number":48,"context_line":"``peer_list``, which is a comma-separated list of hostnames of other compute"},{"line_number":49,"context_line":"services managing the same subset of nodes. If set, this will be used instead"},{"line_number":50,"context_line":"of the current code, which fetches a list of all compute services running the"},{"line_number":51,"context_line":"ironic driver from the database. To ensure that the hash ring splits nodes only"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_bf283bed","line":48,"range":{"start_line":48,"start_character":26,"end_line":48,"end_character":59},"in_reply_to":"3f79a3b5_6f3a2398","updated":"2018-10-19 14:42:36.000000000","message":"\u003e It could also be a compute host aggregate in nova with a special\n \u003e metadata key and then members of that aggregate are peers in the\n \u003e conductor group. The problem is aggregates are defined in the API\n \u003e DB and nova-compute services are in the cell DB, so if the compute\n \u003e service needs to know it\u0027s peer list, that information needs to be\n \u003e sent down from the API\n\nThis is not an option, IMHO. It requires special ironic-specific knowledge at the API layer, and a place to store that at the compute level. It\u0027s complex and brings its own set of brittle elements to this that are harder for an op to diagnose and resolve than fixing config.","commit_id":"812689c0da4cca0bd545057cc8918b9ac864ba62"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"20f079544ee0ac98af89f1f4201be01dd0942636","unresolved":false,"context_lines":[{"line_number":45,"context_line":"of nodes which a given nova-compute service is managing, we need a mechanism to"},{"line_number":46,"context_line":"tell the service which other compute services are managing the same"},{"line_number":47,"context_line":"``partition_key``. To do this, we will add another configuration option,"},{"line_number":48,"context_line":"``peer_list``, which is a comma-separated list of hostnames of other compute"},{"line_number":49,"context_line":"services managing the same subset of nodes. If set, this will be used instead"},{"line_number":50,"context_line":"of the current code, which fetches a list of all compute services running the"},{"line_number":51,"context_line":"ironic driver from the database. To ensure that the hash ring splits nodes only"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_dc1505e8","line":48,"range":{"start_line":48,"start_character":26,"end_line":48,"end_character":59},"in_reply_to":"3f79a3b5_6f3a2398","updated":"2018-10-19 14:01:54.000000000","message":"I think the complexity of representing that is why Dan finally suggested a configuration parameter. I guess etcd would make sense each compute service could just register its self as \"I am x,y\", and that service can also be partitioned (or not), and upon hash ring recalculation the compute service could just pull the list from etcd.  Etcd, while it was not discussed during the session, seems to be the cleanest path.","commit_id":"812689c0da4cca0bd545057cc8918b9ac864ba62"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"f3158641e591e42eac779f32bd36cba3abfe36da","unresolved":false,"context_lines":[{"line_number":45,"context_line":"of nodes which a given nova-compute service is managing, we need a mechanism to"},{"line_number":46,"context_line":"tell the service which other compute services are managing the same"},{"line_number":47,"context_line":"``partition_key``. To do this, we will add another configuration option,"},{"line_number":48,"context_line":"``peer_list``, which is a comma-separated list of hostnames of other compute"},{"line_number":49,"context_line":"services managing the same subset of nodes. If set, this will be used instead"},{"line_number":50,"context_line":"of the current code, which fetches a list of all compute services running the"},{"line_number":51,"context_line":"ironic driver from the database. To ensure that the hash ring splits nodes only"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_2ffda4b1","line":48,"range":{"start_line":48,"start_character":26,"end_line":48,"end_character":59},"in_reply_to":"3f79a3b5_bf283bed","updated":"2018-10-23 11:50:25.000000000","message":"Sure, we could add a field to the compute service record. This was discussed in the nova room at the PTG, but adding a field there for a particular driver was a deal-breaker for some (IIRC).","commit_id":"812689c0da4cca0bd545057cc8918b9ac864ba62"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"8c593289923eee40aa920e74f4ad4ae11e1b4596","unresolved":false,"context_lines":[{"line_number":51,"context_line":"ironic driver from the database. To ensure that the hash ring splits nodes only"},{"line_number":52,"context_line":"between currently running compute services, we will check this list against the"},{"line_number":53,"context_line":"database and filter out any inactive services (i.e. has not checked in"},{"line_number":54,"context_line":"recently) listed in ``peer_list``."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"Both options will be \"mutable\", meaning it only requires a SIGHUP to update the"},{"line_number":57,"context_line":"running service with new config values."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_2ff2ebe5","line":54,"updated":"2018-10-17 18:47:05.000000000","message":"Is it possible to update a node\u0027s conductor_group via the ironic API? If I move a node from conductor_group A to B, that means I then also need to update the configs on all of my nova-compute services which had the compute with the matching partition_key out of their peer_list, right? That makes me want to die.\n\nAlso, if compute host A is managing nodes 1,2,3 in conductor_group A, and then we update node 3 to go to conductor_group B which is managed by compute host B, does that imply that the server instance for node B gets migrated (in nova) from host A to host B? I expect not, but isn\u0027t that kind of what you\u0027re asking for here?","commit_id":"812689c0da4cca0bd545057cc8918b9ac864ba62"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"20f079544ee0ac98af89f1f4201be01dd0942636","unresolved":false,"context_lines":[{"line_number":51,"context_line":"ironic driver from the database. To ensure that the hash ring splits nodes only"},{"line_number":52,"context_line":"between currently running compute services, we will check this list against the"},{"line_number":53,"context_line":"database and filter out any inactive services (i.e. has not checked in"},{"line_number":54,"context_line":"recently) listed in ``peer_list``."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"Both options will be \"mutable\", meaning it only requires a SIGHUP to update the"},{"line_number":57,"context_line":"running service with new config values."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_1c9dbd57","line":54,"in_reply_to":"3f79a3b5_2ff2ebe5","updated":"2018-10-19 14:01:54.000000000","message":"\u003e Is it possible to update a node\u0027s conductor_group via the ironic\n \u003e API?\n\nYes, it can be updated via the API, and would take effect ironic side during the next hash ring recalculation.\n\n \u003e If I move a node from conductor_group A to B, that means I\n \u003e then also need to update the configs on all of my nova-compute\n \u003e services which had the compute with the matching partition_key out\n \u003e of their peer_list, right? That makes me want to die.\n\nOnly if we want to track 1:1, which is not what we are desiring. The instance in the hypervisor record _could_ disappear from nova\u0027s POV, but if there is already a nova-compute running for B, it should just appear there upon hash ring re-balance on the B group. No operator intervention should be needed, afaik, as long as there are also nova-compute services running with the B partition_key.\n\n \u003e Also, if compute host A is managing nodes 1,2,3 in conductor_group\n \u003e A, and then we update node 3 to go to conductor_group B which is\n \u003e managed by compute host B, does that imply that the server instance\n \u003e for node B gets migrated (in nova) from host A to host B? I expect\n \u003e not, but isn\u0027t that kind of what you\u0027re asking for here?\n\nWe\u0027re not asking for that, but we\u0027re simply asking for the management to allow an operator to reduce the scope of specific nova-compute processes. If someone were to move the node, then I think they have essentially shot themselves in the foot. We could, at least on the ironic side, put very big warnings in place to provide guidance for an operator making those sorts of changes.","commit_id":"812689c0da4cca0bd545057cc8918b9ac864ba62"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"14b2458e0e4f07ba7f9276f085510d036b21c4fd","unresolved":false,"context_lines":[{"line_number":51,"context_line":"ironic driver from the database. To ensure that the hash ring splits nodes only"},{"line_number":52,"context_line":"between currently running compute services, we will check this list against the"},{"line_number":53,"context_line":"database and filter out any inactive services (i.e. has not checked in"},{"line_number":54,"context_line":"recently) listed in ``peer_list``."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"Both options will be \"mutable\", meaning it only requires a SIGHUP to update the"},{"line_number":57,"context_line":"running service with new config values."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_cfc990ab","line":54,"in_reply_to":"3f79a3b5_2ff2ebe5","updated":"2018-10-23 11:42:30.000000000","message":"\u003e Is it possible to update a node\u0027s conductor_group via the ironic\n \u003e API? If I move a node from conductor_group A to B, that means I\n \u003e then also need to update the configs on all of my nova-compute\n \u003e services which had the compute with the matching partition_key out\n \u003e of their peer_list, right? That makes me want to die.\n\nNo need to update configs. The config option is only a list of nova-compute services which manage the same conductor group; not a list of nodes that should be managed.\n\n \u003e Also, if compute host A is managing nodes 1,2,3 in conductor_group\n \u003e A, and then we update node 3 to go to conductor_group B which is\n \u003e managed by compute host B, does that imply that the server instance\n \u003e for node B gets migrated (in nova) from host A to host B? I expect\n \u003e not, but isn\u0027t that kind of what you\u0027re asking for here?\n\nThe hash ring calculation always sticks an ironic node with an instance to the nova-compute service managing that instance. It isn\u0027t ideal from a consistency POV, though. We\u0027ve talked for a while about automatically \"migrating\" instances on a hash ring rebalance (or in this case, a conductor_group update), but haven\u0027t felt a strong need to do it.\n\nNote: migrating an ironic instance to another compute service is just updating database records.","commit_id":"812689c0da4cca0bd545057cc8918b9ac864ba62"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"f523987aeab9c1d58205f9ced606ac80c5b70b11","unresolved":false,"context_lines":[{"line_number":62,"context_line":"Ideally, we wouldn\u0027t need a ``peer_list`` configuration option, as we would be"},{"line_number":63,"context_line":"able to dynamically fetch this list from the database, and it\u0027s prone to"},{"line_number":64,"context_line":"operator mistakes. However, there currently isn\u0027t a good place in the database"},{"line_number":65,"context_line":"to store arbitrary data about a service like this, and there doesn\u0027t seem to be"},{"line_number":66,"context_line":"support for adding one."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"Data model impact"},{"line_number":69,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_04c8741e","line":66,"range":{"start_line":65,"start_character":55,"end_line":66,"end_character":23},"updated":"2018-10-15 14:26:32.000000000","message":"The panda sighs again.","commit_id":"812689c0da4cca0bd545057cc8918b9ac864ba62"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"0ea02d27c454a30077c291d1fbc3b591239caa27","unresolved":false,"context_lines":[{"line_number":62,"context_line":"Ideally, we wouldn\u0027t need a ``peer_list`` configuration option, as we would be"},{"line_number":63,"context_line":"able to dynamically fetch this list from the database, and it\u0027s prone to"},{"line_number":64,"context_line":"operator mistakes. However, there currently isn\u0027t a good place in the database"},{"line_number":65,"context_line":"to store arbitrary data about a service like this, and there doesn\u0027t seem to be"},{"line_number":66,"context_line":"support for adding one."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"Data model impact"},{"line_number":69,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_eb140eec","line":66,"range":{"start_line":65,"start_character":55,"end_line":66,"end_character":23},"in_reply_to":"3f79a3b5_04c8741e","updated":"2018-10-16 13:03:54.000000000","message":"yeah, using config for this is a bit sad making. Was there any discussion of using tooz, etcd, what-have-you? Some kind of \"coordination API\"?","commit_id":"812689c0da4cca0bd545057cc8918b9ac864ba62"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"20f079544ee0ac98af89f1f4201be01dd0942636","unresolved":false,"context_lines":[{"line_number":62,"context_line":"Ideally, we wouldn\u0027t need a ``peer_list`` configuration option, as we would be"},{"line_number":63,"context_line":"able to dynamically fetch this list from the database, and it\u0027s prone to"},{"line_number":64,"context_line":"operator mistakes. However, there currently isn\u0027t a good place in the database"},{"line_number":65,"context_line":"to store arbitrary data about a service like this, and there doesn\u0027t seem to be"},{"line_number":66,"context_line":"support for adding one."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"Data model impact"},{"line_number":69,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_7cf071fd","line":66,"range":{"start_line":65,"start_character":55,"end_line":66,"end_character":23},"in_reply_to":"3f79a3b5_0ff92fc4","updated":"2018-10-19 14:01:54.000000000","message":"Matt, for the record, that was the outcome of the discussion during the nova/ironic session, specifically when it didn\u0027t come to placement, but came to trying to understand which other nova-compute processes were online and what configuration each represented.","commit_id":"812689c0da4cca0bd545057cc8918b9ac864ba62"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"14b2458e0e4f07ba7f9276f085510d036b21c4fd","unresolved":false,"context_lines":[{"line_number":62,"context_line":"Ideally, we wouldn\u0027t need a ``peer_list`` configuration option, as we would be"},{"line_number":63,"context_line":"able to dynamically fetch this list from the database, and it\u0027s prone to"},{"line_number":64,"context_line":"operator mistakes. However, there currently isn\u0027t a good place in the database"},{"line_number":65,"context_line":"to store arbitrary data about a service like this, and there doesn\u0027t seem to be"},{"line_number":66,"context_line":"support for adding one."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"Data model impact"},{"line_number":69,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_ef31ecbc","line":66,"range":{"start_line":65,"start_character":55,"end_line":66,"end_character":23},"in_reply_to":"3f79a3b5_7cf071fd","updated":"2018-10-23 11:42:30.000000000","message":"Right, what Julia said. Other options were definitely brought up, but this is what we agreed on. I\u0027ll flesh this out.","commit_id":"812689c0da4cca0bd545057cc8918b9ac864ba62"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"8c593289923eee40aa920e74f4ad4ae11e1b4596","unresolved":false,"context_lines":[{"line_number":62,"context_line":"Ideally, we wouldn\u0027t need a ``peer_list`` configuration option, as we would be"},{"line_number":63,"context_line":"able to dynamically fetch this list from the database, and it\u0027s prone to"},{"line_number":64,"context_line":"operator mistakes. However, there currently isn\u0027t a good place in the database"},{"line_number":65,"context_line":"to store arbitrary data about a service like this, and there doesn\u0027t seem to be"},{"line_number":66,"context_line":"support for adding one."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"Data model impact"},{"line_number":69,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_0ff92fc4","line":66,"range":{"start_line":65,"start_character":55,"end_line":66,"end_character":23},"in_reply_to":"3f79a3b5_eb140eec","updated":"2018-10-17 18:47:05.000000000","message":"\"there doesn\u0027t seem to be support for adding one.\"\n\nIs that based on hallway chatter at the PTG or something? Like, what is being proposed here is pretty fugly, so we should probably document why other alternatives are worse.\n\nI do see stuff in the PTG etherpad about leveraging placement aggregates for this somehow but since placement doesn\u0027t have consumer types it might not work right now.","commit_id":"812689c0da4cca0bd545057cc8918b9ac864ba62"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"d11bc10e29c8c3225712ffd3c8c4498e4f735b7d","unresolved":false,"context_lines":[{"line_number":62,"context_line":"Ideally, we wouldn\u0027t need a ``peer_list`` configuration option, as we would be"},{"line_number":63,"context_line":"able to dynamically fetch this list from the database, and it\u0027s prone to"},{"line_number":64,"context_line":"operator mistakes. However, there currently isn\u0027t a good place in the database"},{"line_number":65,"context_line":"to store arbitrary data about a service like this, and there doesn\u0027t seem to be"},{"line_number":66,"context_line":"support for adding one."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"Data model impact"},{"line_number":69,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_4ad6c7c6","line":66,"range":{"start_line":65,"start_character":55,"end_line":66,"end_character":23},"in_reply_to":"3f79a3b5_ef31ecbc","updated":"2018-10-23 16:48:01.000000000","message":"OK, I wasn\u0027t paying attention to this discussion at the PTG so for those that don\u0027t remember any of that discussion, the points should be documented in the spec.","commit_id":"812689c0da4cca0bd545057cc8918b9ac864ba62"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"61d6d7a8cdc90c1c9d613cf1046dc900a1430f27","unresolved":false,"context_lines":[{"line_number":160,"context_line":"Documentation Impact"},{"line_number":161,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"Deployer and operator documentation will need updates."},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"References"},{"line_number":166,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_ea4c739e","line":163,"updated":"2018-10-23 16:52:49.000000000","message":"Either here, or operator or user impacts, I think something should be said about what happens if the node\u0027s conductor group is updated in ironic and what we expect to happen on the nova side. Does everything automatically rebalance and fix itself or can the operator shoot themselves in the foot by doing that? Am I overly worried about this and nobody thinks it will ever happen?","commit_id":"19bbd94d87c5ff1f7f93b79d0e801d95faa4a66d"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"9afc0c160765b8a428865a241d6cf82538b5cfa0","unresolved":false,"context_lines":[{"line_number":160,"context_line":"Documentation Impact"},{"line_number":161,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"Deployer and operator documentation will need updates."},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"References"},{"line_number":166,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_6383da07","line":163,"in_reply_to":"3f79a3b5_d0191276","updated":"2018-11-02 17:36:43.000000000","message":"Talked some options out with Dan, we\u0027re going to add a use_partition_keys boolean option. If True, the other options take effect (and the default partition_key is the default group). If False, all nodes are queried.","commit_id":"19bbd94d87c5ff1f7f93b79d0e801d95faa4a66d"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"150ec9575875cddb4eb0a0acf745c028c7d7a4ad","unresolved":false,"context_lines":[{"line_number":160,"context_line":"Documentation Impact"},{"line_number":161,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"Deployer and operator documentation will need updates."},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"References"},{"line_number":166,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_d0191276","line":163,"in_reply_to":"3f79a3b5_ea4c739e","updated":"2018-10-24 11:26:48.000000000","message":"It just works, I can add some words. Well, assuming there\u0027s a compute service that can manage the new group. I also don\u0027t expect that to be a thing that changes often, or at all.\n\nThat said, thanks for bringing it up. Thinking through this, I realized that we need to distinguish between \"not configured\" and \"manages default group (empty string)\".\n\nIn the former case, a compute service will look at the full list of ironic nodes (which may contain some nodes in a group, and the group may have compute services bound to the group).\n\nIn the latter case, a compute service will only manage nodes in the default group. But if every compute service is bound to a group, and there\u0027s nodes in a group without a compute service to manage it, the node is orphaned.\n\nSo I need to think through:\n* how to make this clear in documentation, and if there\u0027s any recommendations we can give (like always have a compute service that can manage all)\n* If this situation can be detected somehow. Since the config is local to the compute nodes, we can\u0027t use something that checks the nova database against the list of ironic nodes or whatever. Putting this in the services table would make detecting a loaded footgun much easier.","commit_id":"19bbd94d87c5ff1f7f93b79d0e801d95faa4a66d"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"0bdb2415bd7c30d082ef0f0183aa7f7f39aaf1d9","unresolved":false,"context_lines":[{"line_number":35,"context_line":"Proposed change"},{"line_number":36,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"A configuration option ``partition_key`` will be added, to tell the"},{"line_number":39,"context_line":"nova-compute service which ``conductor_group`` (an ironic-ism) it is"},{"line_number":40,"context_line":"responsible for managing. This will be used as a filter when querying the list"},{"line_number":41,"context_line":"of nodes from ironic, so that only the subset of nodes which have a"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_f31dd1be","line":38,"range":{"start_line":38,"start_character":25,"end_line":38,"end_character":38},"updated":"2018-11-12 17:48:35.000000000","message":"In the [ironic] CONF section I presume?","commit_id":"bed1832eaa32fcc8a8287d67121faafd46d158eb"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"8d02329089bb3e011d48fb39488409e1f3539c7a","unresolved":false,"context_lines":[{"line_number":35,"context_line":"Proposed change"},{"line_number":36,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"A configuration option ``partition_key`` will be added, to tell the"},{"line_number":39,"context_line":"nova-compute service which ``conductor_group`` (an ironic-ism) it is"},{"line_number":40,"context_line":"responsible for managing. This will be used as a filter when querying the list"},{"line_number":41,"context_line":"of nodes from ironic, so that only the subset of nodes which have a"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_a3104f5a","line":38,"range":{"start_line":38,"start_character":25,"end_line":38,"end_character":38},"in_reply_to":"3f79a3b5_45062dcf","updated":"2018-11-14 10:05:04.000000000","message":"Done","commit_id":"bed1832eaa32fcc8a8287d67121faafd46d158eb"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"a44a8044f5c64049499c27dee9243d34de7637e9","unresolved":false,"context_lines":[{"line_number":35,"context_line":"Proposed change"},{"line_number":36,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"A configuration option ``partition_key`` will be added, to tell the"},{"line_number":39,"context_line":"nova-compute service which ``conductor_group`` (an ironic-ism) it is"},{"line_number":40,"context_line":"responsible for managing. This will be used as a filter when querying the list"},{"line_number":41,"context_line":"of nodes from ironic, so that only the subset of nodes which have a"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_45062dcf","line":38,"range":{"start_line":38,"start_character":25,"end_line":38,"end_character":38},"in_reply_to":"3f79a3b5_f31dd1be","updated":"2018-11-13 15:56:43.000000000","message":"Yes, can push an update to make this clear.","commit_id":"bed1832eaa32fcc8a8287d67121faafd46d158eb"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"bee2cc227791f60aa58b068a98ca1c4ebc658ac2","unresolved":false,"context_lines":[{"line_number":53,"context_line":"database and filter out any inactive services (i.e. has not checked in"},{"line_number":54,"context_line":"recently) listed in ``peer_list``."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"A third ``use_partition_keys`` configuration turns the functionality on and"},{"line_number":57,"context_line":"off. If this is False, the behavior is as before, where all nodes may be"},{"line_number":58,"context_line":"managed. If True, the ``partition_key`` will take effect, with the default"},{"line_number":59,"context_line":"being the default (empty) group."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_cd3fea20","line":56,"updated":"2018-11-10 13:22:47.000000000","message":"I guess we couldn\u0027t default partition_key to some kind of sentinel, since in the ironic API it\u0027s pretty open-ended on what\u0027s acceptable for the conductor group? Meaning, if we had a sentinel, that could be used as the enable/disable thing where if the value is not the sentinel, it means it\u0027s a real conductor group.","commit_id":"bed1832eaa32fcc8a8287d67121faafd46d158eb"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"8d02329089bb3e011d48fb39488409e1f3539c7a","unresolved":false,"context_lines":[{"line_number":53,"context_line":"database and filter out any inactive services (i.e. has not checked in"},{"line_number":54,"context_line":"recently) listed in ``peer_list``."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"A third ``use_partition_keys`` configuration turns the functionality on and"},{"line_number":57,"context_line":"off. If this is False, the behavior is as before, where all nodes may be"},{"line_number":58,"context_line":"managed. If True, the ``partition_key`` will take effect, with the default"},{"line_number":59,"context_line":"being the default (empty) group."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_0614b141","line":56,"in_reply_to":"3f79a3b5_80f6732c","updated":"2018-11-14 10:05:04.000000000","message":"Done","commit_id":"bed1832eaa32fcc8a8287d67121faafd46d158eb"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"807f5ec47d05fdaa09547c3f2c2af08d98286280","unresolved":false,"context_lines":[{"line_number":53,"context_line":"database and filter out any inactive services (i.e. has not checked in"},{"line_number":54,"context_line":"recently) listed in ``peer_list``."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"A third ``use_partition_keys`` configuration turns the functionality on and"},{"line_number":57,"context_line":"off. If this is False, the behavior is as before, where all nodes may be"},{"line_number":58,"context_line":"managed. If True, the ``partition_key`` will take effect, with the default"},{"line_number":59,"context_line":"being the default (empty) group."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_80f6732c","line":56,"in_reply_to":"3f79a3b5_8586850e","updated":"2018-11-13 16:12:17.000000000","message":"I guess None is a valid default, let\u0027s just use that as the sentinel. Sorry for the churn :/","commit_id":"bed1832eaa32fcc8a8287d67121faafd46d158eb"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"a44a8044f5c64049499c27dee9243d34de7637e9","unresolved":false,"context_lines":[{"line_number":53,"context_line":"database and filter out any inactive services (i.e. has not checked in"},{"line_number":54,"context_line":"recently) listed in ``peer_list``."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"A third ``use_partition_keys`` configuration turns the functionality on and"},{"line_number":57,"context_line":"off. If this is False, the behavior is as before, where all nodes may be"},{"line_number":58,"context_line":"managed. If True, the ``partition_key`` will take effect, with the default"},{"line_number":59,"context_line":"being the default (empty) group."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_8586850e","line":56,"in_reply_to":"3f79a3b5_b368b91e","updated":"2018-11-13 15:56:43.000000000","message":"We need to somehow delineate \"manage all nodes\" and \"manage the nodes in the default (empty string) group\". \n\nThat said, if StrOpts can have a null default, maybe we can just do that for partition_key... I need to check this out. I feel like that wasn\u0027t an option when I looked, but I could be wrong.\n\nmriedem makes a good point that we could use a sentinel. The conductor group is pretty open, but there\u0027s lots of special characters we could use (though it would be confusing, I think).","commit_id":"bed1832eaa32fcc8a8287d67121faafd46d158eb"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"0bdb2415bd7c30d082ef0f0183aa7f7f39aaf1d9","unresolved":false,"context_lines":[{"line_number":53,"context_line":"database and filter out any inactive services (i.e. has not checked in"},{"line_number":54,"context_line":"recently) listed in ``peer_list``."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"A third ``use_partition_keys`` configuration turns the functionality on and"},{"line_number":57,"context_line":"off. If this is False, the behavior is as before, where all nodes may be"},{"line_number":58,"context_line":"managed. If True, the ``partition_key`` will take effect, with the default"},{"line_number":59,"context_line":"being the default (empty) group."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_b368b91e","line":56,"in_reply_to":"3f79a3b5_cd3fea20","updated":"2018-11-12 17:48:35.000000000","message":"I\u0027m actually also wondering why the need for a third CONF option. What is the default partition_key and peer_list going to be? Couldn\u0027t the new partition_key functionality be triggered when peer_list isn\u0027t None (or an empty list) and partition_key is non-None?","commit_id":"bed1832eaa32fcc8a8287d67121faafd46d158eb"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"0bdb2415bd7c30d082ef0f0183aa7f7f39aaf1d9","unresolved":false,"context_lines":[{"line_number":72,"context_line":"the partition key. Compute services running the ironic driver could then use"},{"line_number":73,"context_line":"this field to determine their peer list. During the Stein PTG discussion"},{"line_number":74,"context_line":"about this feature, we agreed not to do this, as adding fields or blobjects"},{"line_number":75,"context_line":"in the service record for a single driver is a layer violation."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"Another option is for the ironic driver to manage its own list of live services"},{"line_number":78,"context_line":"in something like etcd, and the peer list could be determined from here. This"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_535da579","line":75,"range":{"start_line":75,"start_character":43,"end_line":75,"end_character":63},"updated":"2018-11-12 17:48:35.000000000","message":"correct. ++","commit_id":"bed1832eaa32fcc8a8287d67121faafd46d158eb"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"0bdb2415bd7c30d082ef0f0183aa7f7f39aaf1d9","unresolved":false,"context_lines":[{"line_number":107,"context_line":"Performance Impact"},{"line_number":108,"context_line":"------------------"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Using this feature slightly improves the performance of the resource tracker"},{"line_number":111,"context_line":"update, as the hash ring is refreshed at this time, and there will be less"},{"line_number":112,"context_line":"nodes to iterate over before returning the node list."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"Other deployer impact"},{"line_number":115,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_f34b91ae","line":112,"range":{"start_line":110,"start_character":0,"end_line":112,"end_character":53},"updated":"2018-11-12 17:48:35.000000000","message":"I\u0027m not understanding how this proposed functionality will improve performance versus the hash-ring splitting that already exists in nova+ironic. It just seems like this is adding a further partitioning scheme over top of the existing hash-ring partitioning scheme. Is that correct?","commit_id":"bed1832eaa32fcc8a8287d67121faafd46d158eb"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"8d02329089bb3e011d48fb39488409e1f3539c7a","unresolved":false,"context_lines":[{"line_number":107,"context_line":"Performance Impact"},{"line_number":108,"context_line":"------------------"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Using this feature slightly improves the performance of the resource tracker"},{"line_number":111,"context_line":"update, as the hash ring is refreshed at this time, and there will be less"},{"line_number":112,"context_line":"nodes to iterate over before returning the node list."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"Other deployer impact"},{"line_number":115,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_463869cb","line":112,"range":{"start_line":110,"start_character":0,"end_line":112,"end_character":53},"in_reply_to":"3f79a3b5_70975b39","updated":"2018-11-14 10:05:04.000000000","message":"Re-reading Jay\u0027s question, it\u0027s specifically about performance, while Dan\u0027s response covers why we\u0027re doing this (which I believe is already answered).\n\nWRT performance - Jay, it\u0027s a very small difference in the API calls made to ironic. Without this functionality, the compute service gets a list of *all* ironic nodes, and iterates over them, determining which nodes should be managed by this compute host. With this functionality, the compute service gets a *subset* of ironic nodes, and iterates over them.\n\nI\u0027ve added some words to make this more clear.","commit_id":"bed1832eaa32fcc8a8287d67121faafd46d158eb"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"8c5301449f78fcff9f223b233440aad6b348a298","unresolved":false,"context_lines":[{"line_number":107,"context_line":"Performance Impact"},{"line_number":108,"context_line":"------------------"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Using this feature slightly improves the performance of the resource tracker"},{"line_number":111,"context_line":"update, as the hash ring is refreshed at this time, and there will be less"},{"line_number":112,"context_line":"nodes to iterate over before returning the node list."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"Other deployer impact"},{"line_number":115,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_70975b39","line":112,"range":{"start_line":110,"start_character":0,"end_line":112,"end_character":53},"in_reply_to":"3f79a3b5_c5a31d9c","updated":"2018-11-14 08:38:56.000000000","message":"If Dan\u0027s reply clarifies this, at least the difference with the hash ring, or how the hash ring doesn\u0027t solve the problem, maybe we throw that into the spec somewhere, like a \"Why doesn\u0027t hash ring solve this? I\u0027m glad you asked. blah blah blah\". Then it\u0027s at least recorded in the spec beyond just review comment back and forth. I for one wasn\u0027t paying attention at the PTG so that\u0027s why I\u0027m asking lots of questions.","commit_id":"bed1832eaa32fcc8a8287d67121faafd46d158eb"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"a44a8044f5c64049499c27dee9243d34de7637e9","unresolved":false,"context_lines":[{"line_number":107,"context_line":"Performance Impact"},{"line_number":108,"context_line":"------------------"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Using this feature slightly improves the performance of the resource tracker"},{"line_number":111,"context_line":"update, as the hash ring is refreshed at this time, and there will be less"},{"line_number":112,"context_line":"nodes to iterate over before returning the node list."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"Other deployer impact"},{"line_number":115,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_c5a31d9c","line":112,"range":{"start_line":110,"start_character":0,"end_line":112,"end_character":53},"in_reply_to":"3f79a3b5_de43f296","updated":"2018-11-13 15:56:43.000000000","message":"What Dan said :)","commit_id":"bed1832eaa32fcc8a8287d67121faafd46d158eb"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5d11c3fb2b4c64cb00e42521eb192d4ed20a31cb","unresolved":false,"context_lines":[{"line_number":107,"context_line":"Performance Impact"},{"line_number":108,"context_line":"------------------"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Using this feature slightly improves the performance of the resource tracker"},{"line_number":111,"context_line":"update, as the hash ring is refreshed at this time, and there will be less"},{"line_number":112,"context_line":"nodes to iterate over before returning the node list."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"Other deployer impact"},{"line_number":115,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_de43f296","line":112,"range":{"start_line":110,"start_character":0,"end_line":112,"end_character":53},"in_reply_to":"3f79a3b5_f34b91ae","updated":"2018-11-13 12:47:29.000000000","message":"Yes, Ironic has a partitioning scheme now, but there is no way for us to dedicate a set of computes to a set of ironic nodes. This is necessary for availability-related partitioning, as well as affinity.\n\nIf we need ironic nodes in a remote datacenter, we need a way to make sure that the nova-computes that are in that datacenter manage those ironic nodes. Right now and without this, all the nova-computes running the ironic driver in the entire deployment will hash-ring all the available ironic nodes.","commit_id":"bed1832eaa32fcc8a8287d67121faafd46d158eb"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3b55e6d81ea0eff46b88ff8186ddfbb551a8c2a6","unresolved":false,"context_lines":[{"line_number":15,"context_line":"services to a particular location (building, aisle, rack, etc), and provides a"},{"line_number":16,"context_line":"way for operators to manage the failure domain of a given nova-compute service."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"Problem description"},{"line_number":19,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"As OpenStack deployments become larger, and edge compute becomes a reality,"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_fce7c40f","line":18,"updated":"2018-11-14 12:30:40.000000000","message":"nit: the problem description doesn\u0027t really say what happens today which is the problem, meaning nodes at one far edge site could be managed by a compute service at a totally opposite remote edge site, which is a problem. I think that is explained elsewhere and in review discussion (and Dan explaining this to me in person). But I don\u0027t think I would have gotten it from just the problem description here. Anyway, it\u0027s a nit. I think what made the light bulb go off for me is when I compare this to the server/volume affinity issue that nova has had with cinder for a long time where people want their root volume running as close to the server as possible, but we can only do that today with matching nova/cinder AZs.","commit_id":"3d285f2ea44d3cdd75ed9bc7603c64f4826a8ad2"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"df2c78088a1200f9f31e643977954af2166f6911","unresolved":false,"context_lines":[{"line_number":15,"context_line":"services to a particular location (building, aisle, rack, etc), and provides a"},{"line_number":16,"context_line":"way for operators to manage the failure domain of a given nova-compute service."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"Problem description"},{"line_number":19,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"As OpenStack deployments become larger, and edge compute becomes a reality,"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9fdfeff1_2bdf7069","line":18,"in_reply_to":"3f79a3b5_fce7c40f","updated":"2019-02-01 18:31:49.000000000","message":"this was not obvios to me.\nthanks for adding the context","commit_id":"3d285f2ea44d3cdd75ed9bc7603c64f4826a8ad2"}]}