This portal is to open public enhancement requests against products and services offered by the IBM Data & AI organization. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updateson them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,
Post an idea
Upvote ideas that matter most to you
Get feedback from the IBM team to refine your idea
Specific links you will want to bookmark for future use
Deployment space creation via API that allows pending user owner
Banco do Brasil (BdB) is fully automating the process of building an MLOps pipeline that uses CP4DaaS as one of theirwork 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 a Deployment Space, both sharing the same set of users/roles. To achieve process scalability, the creation of such a 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 such work environments, that prevents them from adopting CP4DaaS as their de-facto working environment, namely the creation of deployment spaces via API. Users in the PENDING state (a.k.a. users that have access and were invited to the platform but still haven't access it yet) cannot be administrators of a deployment space, although those users can indeed be administrators/members of a cp4d project. So, for project creation the API allows proper automation, but for deployment space creation the API does not allow full process automation since it requires a human intervention (to change the user from pending to active state) without a concrete business purpose: the user has all the roles/privileges to be a member/admin of such a deployment space but there's no real need for such a user to access the platform prior to space creation.
To clarify even more: BdB automates the project/deployment space creation in order to keep all management tasks in a centralized platform that runs on premises. In this on-premises platform, a user with correct roles creates a "BdB Project" which consists of (1) a cp4d project, (2) two cp4d deployment spaces, and (3) a set of users added to the project and both spaces as members.
The user that creates this "BdB Project" is the cp4d project/space admin.
Point 1) The user that creates "BdB Projects" is usually a manager, without technical expertise. So he usually does not access cp4d. All management tasks that he needs to do (such as creating projects, assigning users to projects and deleting projects) is done in the BdB platform (on-prem), no need to reach our dataplatform.cloud.ibm.com .
Point 2) This process works as expected when creating the project since a user with cp4d access role can create projects via API even without having its first access to the platform done.
Point 3) This does not hold for deployment spaces, since there is an additional pre-condition that says that the user creating the deployment space must access the platform beforehand to be considered active to the platform. This additional requirement, which is not consistent on the way project creation works, is the main concern.
Why? Consider the following situation: A manager "A" has a team with 5 employees. They want to work on a brand new machine learning solution using cp4d. Manager "A" creates a "BdB Project" inside their platform (on-premises side). This starts a procedure that creates a cp4d project and adds the 5 employees as project members. The manager is the project admin. That works as expected. However, this procedure also creates two deployment spaces (which are - at BdB side - associated to the created project). The 5 employees should also be members of both deployment spaces. Now the problem is, the 5 employees can not access the complete working environment because the deployment spaces can not be created UNTIL manager "A" accesses the platform for the first time (and thus be considered active instead of pending user). And such a user can perfectly never access it anymore - since its perfectly fine to expect such a user to NOT be a data scientist or the like - it's a people manager. Clearly, this blocks the overall automation because now the environment creation process requires a "man-on-the-middle" manual intervention, which is not automatic not automatable.
Do not place IBM confidential, company confidential, or personal information into any field.