Removal of hard-limit on number of Project Creation API Calls

Banco do Brasil is fully automating the process of building a MLOps pipeline that uses CP4DaaS as one of their work environments. Such a pipeline relies on administrative functionalities and execution triggers that are directly linked to their on-premises environments (such as internal identification/authorization policies, archive storage, production inference servers for trained models, etc). Such on-premises components thus do rely on the provided CP4DaaS APIs to automate tasks critical to the overall pipeline operation. One such automation has to do with the creation of the working environment a team should have when tackling a machine learning problem. Such a working environment is comprised by (but not limited to) a CP4DaaS Project as well as Deployment Space, both sharing the same set of users/roles.

To achieve process scalability, the creation of such working environment for a given Banco do Brasil team is done through the CP4DaaS API calls, triggered by an administrative component running on-premises, according to the employee roles/permissions (in other words, only specific employees, say team managers can execute such a task). The described automation is of great importance to Banco do Brasil since it allows them to offer strong guarantees regarding regulatory needs as well as flexibility to adhere to their internal architectural requirements and extensibility demands.

They are, however, facing an important and limiting issue regarding a key API usage for automatically creating projects, that prevents them to adopt CP4DaaS as their de-facto working environment, namely: the Project Creation API has a user-based hard limit on total number of projects that can be created via API. Currently, a given user X is limited to create at most 100 projects on CP4DaaS via API. If such a limit is reached there's no other option other then deleting projects, which, due to regulatory aspects, is not that trivial. The issue Banco do Brasil is facing with such a per-user hard-limit approach is that, usually, an impersonated "API-User" is used to create projects via the transactional project creation API endpoint, and such impersonated user has a single role: to create projects. But 100 projects strongly limits the usability of having a impersonated "API-User" whose unique goal is to create projects. Such a user is of key importance, however, since it not only allows automation of the MLOps pipeline (in regards to environment creation) as well as it guarantees auditing tasks in a centralized manner, as required by regulatory processes.

More specifically, their impersonated API user receives an API error that says "The number of projects created by the authenticated user exceeds the designated limits. Projects created by user (101) > Projects per user limit (100)." Limiting that in a per user basis, however, doesn't seem to make much sense since it prevents the API to be used for automation purposes (which is a reasonable use case for exposing such APIs).