{"action":"opened","issue":{"url":"https://api.github.com/repos/flux-framework/flux-sched/issues/266","repository_url":"https://api.github.com/repos/flux-framework/flux-sched","labels_url":"https://api.github.com/repos/flux-framework/flux-sched/issues/266/labels{/name}","comments_url":"https://api.github.com/repos/flux-framework/flux-sched/issues/266/comments","events_url":"https://api.github.com/repos/flux-framework/flux-sched/issues/266/events","html_url":"https://github.com/flux-framework/flux-sched/issues/266","id":257142270,"number":266,"title":"User-data scratch space in the jobspec implementation","user":{"login":"dongahn","id":862123,"avatar_url":"https://avatars3.githubusercontent.com/u/862123?v=4","gravatar_id":"","url":"https://api.github.com/users/dongahn","html_url":"https://github.com/dongahn","followers_url":"https://api.github.com/users/dongahn/followers","following_url":"https://api.github.com/users/dongahn/following{/other_user}","gists_url":"https://api.github.com/users/dongahn/gists{/gist_id}","starred_url":"https://api.github.com/users/dongahn/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dongahn/subscriptions","organizations_url":"https://api.github.com/users/dongahn/orgs","repos_url":"https://api.github.com/users/dongahn/repos","events_url":"https://api.github.com/users/dongahn/events{/privacy}","received_events_url":"https://api.github.com/users/dongahn/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2017-09-12T18:42:20Z","updated_at":"2017-09-12T18:42:20Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"Hi @morrone: \r\n\r\nYou and I talked about where in your jobspec implementation I can put the request aggregate information or find an alternative.\r\n\r\nJust to remind you, say I have this jobspec, `cluster[1]->rack[2]->node[2]->socket[2]->core[8]` I want to put aggregate information on a subtree like: `cluster[1](core:64)->rack[2](core32)->node[2](core:16)->socket[2](core:8)->core[8]` Then, such subtree aggregate info will be used to prune the search as part of the preorder walk. What will be aggregated should be programmable by the scheduler itself, of course.\r\n\r\nIt turns out `map<string, int64_t>` for each resource vertex will just do fine for my purpose. Now, I would like to reach a design decision with you so that I can firm up my implementation.\r\n\r\nI have three options and depending on what you prefer, I can go with any of these.\r\n\r\n1. Introduce `void *usr_data` in `class Resource`\r\nThis will be most generic and thus definitely support my need. The downside is type safety and memory management. \r\n\r\n2. Introduce `map<string, int64_t> usr_data` in `class Resource`\r\nThis will definitely support my need and will also be type safe. In addition, you can do your memory management within the destructor of jobspec. But this will not be as generic as 1) and a bit memory inefficient.  \r\n\r\n3. Not adding usr_data at all\r\n If you don't see other use cases for such user data scratch space, NOOP also works for me. I can create my own data structure to keep track of aggregates. This is less than ideal for me, but okay to work with.\r\n\r\nCan we quickly reach an agreement between these options or a alternative. Once I will finish an end-to-end demonstration of  my`resource-query`, I will start doing lots of code cleanup/refactoring and having decisions like this will help me avoid redo the work later.  \r\n\r\n\r\n"}}
{"actor":{"display_login":"dongahn"}}