Mark committed_capacity field for removal

[AlanCoding]

SUMMARY

Explaining why this field exists:

This app used to use celery and RabbitMQ as the messaging system.

In that old design, the instance groups corresponded to literal queues in RabbitMQ. When the task manager dispatched a task, it submitted it to its instance group queue. This meant that we had no control over which node (inside of the group) received the job, because all nodes in the group would be pulling from that queue.

This was redesigned entirely, we don't use RabbitMQ, replacing it with the postgres message bus. Instead of having queues for instance groups, every instance had a queue. Instead of the task manager selecting an instance group alone, it now selects the instance_group, controller_node, and execution_node, and sends the message to the controller_node queue.

The construct of "committed" capacity is for jobs with "waiting" status which have already been submitted to the instance group queue (the type of queue that no longer exists).

In the modern system, all capacity use is committed to a particular instance. The consumed capacity for an instance group is just the consumed capacity of the instances in that group, added up.

This field is archaic at this point.

OPTIONS with this change

            "committed_capacity": {
                "type": "field",
                "label": "Committed capacity",
                "help_text": "This resource has been deprecated and will be removed in a future release",
                "filterable": false
            },

ISSUE TYPE

• Feature Pull Request

COMPONENT NAME

• API

[kdelee]

🎉

[kdelee]

fwiw consumed_capacity also uses capacity_values in the ha.py that we've talked about axing. We should think about if we can deprecate that too (unless we want to do some other re-implementation w/o the capacity_values function)

[AlanCoding]

I don't think we should want to remove the IG consumed_capacity. Ultimately, if we cache task_impact for unified jobs, then we can do the summation in the database by using an efficient Django annotate.