Improve the UI interface of the resources management part for codes Envs.

0 Kudos

The following suggestions are specifically for features in Administrations > Code Envs > Resources. Where you can import pre-trained models locally. What is common if you cannot access the internet.

 

attached the location in the interface of this function position_upload_clear resource.

attached an example of upload without visual interaction. import_local_model_ressources

 

Need more intelligent management of the resource ‘Clear’ function:

At present, the resource directory clear functionality is an all-or-nothing operation that lacks subtlety, especially when working with subdirectories.

It would therefore be very useful if the user interface offered options for :

1 - Selective cleaning of specific items or sub-directories rather than the entire resource directory.

2 - Confirmation or preview of items to be deleted, thus reducing the risk of accidental deletion. (Especially as the resource management of their code machine learning environments are increasingly delegated and under their responsibility).

Improved UI for the Upload function with name collision management:

When importing zip files, the name collision check is currently performed at the end of the process. It would be better to :

1 - Integrate a check mechanism at the start of the import to immediately identify any file name conflicts.

2 - Provide an intelligent overwrite option that ‘merges’ the contents of the zip with existing files rather than deleting them entirely in the event of a conflict.

Add a progress indicator during file import or a process status UI message:

The absence of a progress bar or visual feedback during archive uploads is frustrating, particularly for large files. It would be cool to see the integration of a visible upload bar and real-time information on the status of the upload, including the following:

1 - In the event of success, an explicit message informing the user that the import was successful.

2 - In the event of errors or unexpected events during import, a detailed report or notifications to help diagnose and resolve problems with incomplete archives or a lack of sub-directories.

 

This sometimes leads to a second problem. When the upload finishes (presumably because the upload window disappears) and we find that subdirectories of the unzip archive are missing. Supposedly this could be a duplicate directory or something else, but we can't identify the root cause of the incomplete import because the UI isn't designed to keep us informed of loading and the success or failure of the import.

For clarification, here's an image where you can see that we've added a unet.zip file and then launched upload but the window doesn't seem to show that it's been executed and remains open without loading. However, on the wifi network we can see that the file is being sent to dataiku. Once the upload window disappears, we assume that the import has been completed and we now need to manually check all the sub-directories.

2 Comments

We don't use this functionality for some of the reasons you raised here but above all this functionality is done on a per-environment basis. If you want the same model shared across multiple code environments you have to upload it again to all the other code environments which means you are duplicating things and wasting space (some of the models can be very large). It also means keeping track of model versions is much harder as user can potentially upload newer versions to their code envs. For those reasons we prefer to upload models to a specific local storage location outside of Dataiku and point the relevant packages to load the models from there. While each model/package is different in that regard pretty much all allow for loading of pre-saved/cached models so in our view this is a mode efficient way of achieving this goal.

We don't use this functionality for some of the reasons you raised here but above all this functionality is done on a per-environment basis. If you want the same model shared across multiple code environments you have to upload it again to all the other code environments which means you are duplicating things and wasting space (some of the models can be very large). It also means keeping track of model versions is much harder as user can potentially upload newer versions to their code envs. For those reasons we prefer to upload models to a specific local storage location outside of Dataiku and point the relevant packages to load the models from there. While each model/package is different in that regard pretty much all allow for loading of pre-saved/cached models so in our view this is a mode efficient way of achieving this goal.

Grixis
Level 4

Hello,

see that. this is also one of the alternative ways of bypassing this, we also have approaches that we have a search engine page used to manage uploads without interruption to do this but it's not very resilient and costs us time for nothing when it should logically be by design.

I invite you to thumb up this idea and I'm waiting to hear back from Dataiku if they have already invested in this problem.

 

Hello,

see that. this is also one of the alternative ways of bypassing this, we also have approaches that we have a search engine page used to manage uploads without interruption to do this but it's not very resilient and costs us time for nothing when it should logically be by design.

I invite you to thumb up this idea and I'm waiting to hear back from Dataiku if they have already invested in this problem.