raymond-ndibe@cloudcontrol1006:~$ sudo wmcs-openstack quota show --usage wikiwho

+-----------------------+--------+--------+----------+
| Resource              |  Limit | In Use | Reserved |
+-----------------------+--------+--------+----------+
| cores                 |     48 |     24 |        0 |
...
| ram                   | 249856 | 124928 |        0 |
...
+-----------------------+--------+--------+----------+

raymond-ndibe@cloudcontrol1006:~$ sudo wmcs-openstack quota set --cores 25 --ram 126976 wikiwho
raymond-ndibe@cloudcontrol1006:~$ sudo wmcs-openstack quota show --usage wikiwho

+-----------------------+--------+--------+----------+
| Resource              |  Limit | In Use | Reserved |
+-----------------------+--------+--------+----------+
| cores                 |     25 |     24 |        0 |
...
| ram                   | 126976 | 124928 |        0 |
...
+-----------------------+--------+--------+----------+

In T423408#12177977, @dcaro wrote:

Forgot to add the changelog

@bking you can request for toolforge access here https://toolsadmin.wikimedia.org/register/
to begin experimenting with toolforge

while getting the webservice-cli to use the jobs-api directly,
what we should actually do is to get the webservice-cli to use the jobs-cli (should this be the case?), just like the jobs-cli uses the jobs-api).

So we investigated this, and as far as we know, this issue seems to be coming from the tool-sample-complex-app tool in toolsbeta, because of the cronjobs that run every minute or so (cronjob, generate-emails).

In T431421#12097427, @bd808 wrote:

webservice shell stays as it is, unless we add support for shelling into containers in jobs-api too.

T431276: jobs-api, jobs-cli: investigate shell / exec into jobs-api containers

correction: this a duplicate of https://phabricator.wikimedia.org/T423408 and https://phabricator.wikimedia.org/T423410, not https://phabricator.wikimedia.org/T348755

Decision:

• this is a bit concerning, but we can ignore it until it becomes a bottleneck

In T431273#12090854, @dcaro wrote:

Another option:

• Use the web command for buildservice webservices, as that's what is set as the default entrypoint for them anyhow (so should be backwards compatible).

Decision:

• we can ignore. doesn't seem like anyone depends on it

Decision:

• PORT env should be added.
• HOME env for buildservice images was added because HOME was being set to / in buildservice images without it. we could leave everything like it is right now (so HOME for webservice-cli, NO_HOME for jobs-api, shouldn't be a problem)