#266 User specific IDB entries

UNICORE 7.3
closed
5
2015-02-23
2012-03-12
Sonja Holl
No

The user can specify IDB entries for applications and store those in a specific folder (e.g. /home). UNICORE loads the specific IDB entries and publish them only to the user at the client side. The user is then able to use his specific applications. This should also work with the service orchestrator.

Discussion

  • Hi!

    Recently we were thinking about a very similar FR, here in ICM. More concretely about admin controlled IDB, but per user. This is because we have resources which actually should have different values for different users. For instance, such user-specific entries could be generated by a script with some arguments, invoked by the server when the IDB is refreshed. In the end this is very similar to this FR: user will have much different IDB-related information in TSS RPs, then what is found in TSF RPs.

    However after some consideration we haven't decided to submit such a FR. The reason is the last sentence of current description: the service orchestrator. I'm afraid that SO would have a very difficult job to build a local view of a whole grid. Even in a very small setup of PL-Grid (5 sites, nearly 250 users) this gives well over 1000 copies of IDB and the same number of queries, which are to be executed on quite short intervals. I'm not sure how this is implemented in the SO but I believe it can be a problem. Especially in ever bigger setups.

    Additional problem will be with security. By default the SO doesn't have perms to access user's TSS without trust delegation.

    So to sum up: we are certainly interested with this feature too, but we are also eager to hear how it is going to be realized, especially from the SO point of view (maybe via unicore-devel?).

    Cheers
    KB

     
  • Hi,
    I want just add that this feature would be awesome to have!
    Additionally, it would be nice to have possibility to define some user-specific Resource's AllowedValue options (for instance merged with the global ones defined in IDB). Use case which we have would be, that we could specify users' Project values validated during job submission.

    The main problem is SO. Just to put some ideas (even the wrong ones) maybe it would be good to have some API function in SO that could get user's IDB if it is needed by some brokering strategy. Of course, default behavior would not read it at all. It would be get on demand of programmed strategy, caching those additional (user-specific) properties would have to be done also by a programmer in a plugin.
    In case of security, if a trust delegation would be a problem, maybe some role 'broker' with ability to read users TSFs would be an idea?

    Of course, I'm probably missing lots of things, but that ideas came to my after reading my colleague's comment ;)

    Kind regards,
    Rafal Kluszczynski

     
  • Bernd Schuller
    Bernd Schuller
    2012-06-14

    • labels: 686323 --> Server
    • milestone: --> UNICORE 7
    • priority: 6 --> 5
     
  • Bernd Schuller
    Bernd Schuller
    2012-06-14

    1) As I see it, the "should work the the service orchestrator" is rather difficult to realise. The SO brokers on the TSF level, not TSS, mostly because of scalability reasons, as Krzysztof explained. One could make a compromise, and keep the SO as is. If the user wants to use "custom" applications, she will have to manually select the TSS. But we need to think about the brokering anyway, since the current way also does not work well with virtualized/cloudy target systems.

    2) Having user-specific resource settings is tricky. This would have to be admin controlled, and the IDB file should not be in $HOME. So this conflicts with the applications use case. So its rather a hierarchy of IDBs :-)

    Summary: since the TSSs are user specific anyway, the basic idea of having user-specific settings is not too difficult to realize. But the integration with the workflow system is much more tricky ;)

     
  • Bernd Schuller
    Bernd Schuller
    2014-12-01

    • Group: UNICORE 7.0 --> UNICORE 7.3
    • Priority: 5 --> 7
     
  • Bernd Schuller
    Bernd Schuller
    2014-12-01

    Postponed yet another time, but this time we will do it :-)
    - need to rethink a bit the application support
    - user-defined apps
    - how to deal with non-batch stuff like hadoop
    - any changes required when using docker
    - per-user brokering required at least as a configurable strategy?

     
  • Bernd Schuller
    Bernd Schuller
    2015-02-19

    • labels: Server --> Server, XNJS, UNICORE/X, Workflow System
    • Priority: 7 --> 5
     
  • Bernd Schuller
    Bernd Schuller
    2015-02-19

    UNICORE/X part is done. Brokering in URC and Servorch not yet (should have separate tracker items for those)

     
  • Bernd Schuller
    Bernd Schuller
    2015-02-23

    • status: open --> closed