Skip to end of metadata
Go to start of metadata

as this is duplicate page and the meeting notes is moved to the - Meetings

  • No labels

3 Comments

  1. From an architectural perspective the Design Studio is not the right component to place a "request to create a microservice or its docker image", either directly by the user or indirectly during the validation phase when an ML Model's docker image is found to be missing.. This should happen from MP - Portal (after on boarding) and there is one such icon on the MP - Portal already where the user can do so. Why do we want to duplicate this functionality in Design Studio?

    For the scenario we discussed today - which is if an ML Model is used in a composite solution does not yet have its docker image created, then the DS will flag a validation error. The user should go to the MP - Portal and place a request for the creation of its docker image and then after successful image creation return to the DS and submit the solution for validation.

    The proposal to place the request for docker image creation during validation by the backend Composition Engine (CE) of DS has the following issues:

    1. First DS is not a component from which such a request be placed.
    2. If such a request is placed during validation phase by the DS backend CE, and if errors are encountered during Microservices generation and docker image creation, the DS user  is not the right "role" to understand the intricacies of docker creation and related errors.
    3. The DS user would say - "why am I being presented with docker image creation errors when I requested the validation of solution?" In this case we ultimately have to bring in the "right role" to fix the docker image creation errors via the MP - Portal. So what have we gained via DS?
    4. This brings in an additional and un necessary complication into DS backend CE to deal with microservice/docker creation and related error handling  - something that is completely out of the scope of DS. Place the functionality where it correctly belongs!
  2. Hi, Sorry to not be present yesterday at the architecture committee but in my opinion this point was already discussed and validated I summarized it in ACUMOS-1070.

    In my point of View ; 

    The micro service must be created automatically in background each time we on-board a model. So, first we on-board a model then once the model has been on-borded successfully, the micro-service generation is launched automaticaly in background whithout any manual triggerring . (Even if we don't need micro-service right from the start, this micro service could be used later by other Acumos user). Then we have to think about notifications to warn the user that the model is on-board but not ready for DS, for deployment etc ... and also if a problem occured during micro service génération.

    So on-boarding stay in on-boarding project and microservice-generation move to common-services project. That's what I understood since I arrived in Acumos and that the reason of being of EPIC 1070. 

    We need to be focused on User Experience. Acumos user will be Data Scientist or Data analyst, they don't know and don't care about Docker & Micro-service so we need to hide these objects from them. 




  3. As per my point of view after uploading the model user may want to download and test it (viz., whether model is uploaded successfully, able to download & run the image, model is giving expected output, check the accuracy , etc.), even before using it in composite solution. So we cannot delay microservice generation task to be triggered by validation process in DS Composition Engine.

    W.r.t to Philippe comment above, till the time micorservice generation task is in progress in background, if possible can we assign some state to model, indicating that "onboarded model is under process". And latter on depending on the completion or failure of microservice generation update the state accordingly and make the model available to all other functionality (e.g., download and design studio)