{"action":"created","issue":{"url":"https://api.github.com/repos/hashicorp/nomad/issues/150","repository_url":"https://api.github.com/repos/hashicorp/nomad","labels_url":"https://api.github.com/repos/hashicorp/nomad/issues/150/labels{/name}","comments_url":"https://api.github.com/repos/hashicorp/nomad/issues/150/comments","events_url":"https://api.github.com/repos/hashicorp/nomad/issues/150/events","html_url":"https://github.com/hashicorp/nomad/issues/150","id":108844002,"number":150,"title":"Persistent data on nodes","user":{"login":"F21","id":2263040,"avatar_url":"https://avatars.githubusercontent.com/u/2263040?v=3","gravatar_id":"","url":"https://api.github.com/users/F21","html_url":"https://github.com/F21","followers_url":"https://api.github.com/users/F21/followers","following_url":"https://api.github.com/users/F21/following{/other_user}","gists_url":"https://api.github.com/users/F21/gists{/gist_id}","starred_url":"https://api.github.com/users/F21/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/F21/subscriptions","organizations_url":"https://api.github.com/users/F21/orgs","repos_url":"https://api.github.com/users/F21/repos","events_url":"https://api.github.com/users/F21/events{/privacy}","received_events_url":"https://api.github.com/users/F21/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/hashicorp/nomad/labels/enhancement","name":"enhancement","color":"84b6eb"},{"url":"https://api.github.com/repos/hashicorp/nomad/labels/scheduling","name":"scheduling","color":"B722E4"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":67,"created_at":"2015-09-29T10:45:52Z","updated_at":"2016-07-10T10:14:24Z","closed_at":null,"body":"Nomad should have some way for tasks to acquire persistent storage on nodes. In a lot of cases, we might want to run our own hdfs or ceph cluster on nomad.\r\n\r\nThat means, things like hdfs' datanodes needs to be able to reserve persistent storage on the node it is launched on. If the whole cluster goes down, once its brought back up, the appropriate tasks should be launched on its original nodes (where possible), so that it can gain access to data it has previously written."},"comment":{"url":"https://api.github.com/repos/hashicorp/nomad/issues/comments/231581241","html_url":"https://github.com/hashicorp/nomad/issues/150#issuecomment-231581241","issue_url":"https://api.github.com/repos/hashicorp/nomad/issues/150","id":231581241,"user":{"login":"Ghostium","id":15706162,"avatar_url":"https://avatars.githubusercontent.com/u/15706162?v=3","gravatar_id":"","url":"https://api.github.com/users/Ghostium","html_url":"https://github.com/Ghostium","followers_url":"https://api.github.com/users/Ghostium/followers","following_url":"https://api.github.com/users/Ghostium/following{/other_user}","gists_url":"https://api.github.com/users/Ghostium/gists{/gist_id}","starred_url":"https://api.github.com/users/Ghostium/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Ghostium/subscriptions","organizations_url":"https://api.github.com/users/Ghostium/orgs","repos_url":"https://api.github.com/users/Ghostium/repos","events_url":"https://api.github.com/users/Ghostium/events{/privacy}","received_events_url":"https://api.github.com/users/Ghostium/received_events","type":"User","site_admin":false},"created_at":"2016-07-10T10:14:24Z","updated_at":"2016-07-10T10:14:24Z","body":"@faddat I think you missing the point. Volumes aren't complex because the stateless hype. The problem, that isn't really a problem but makes things more complex, is that HashiCorp want the scheduler aware of the volumes technology it is scheduling - and support many of them.\r\n\r\nA proposal how to do this in the job desc. is easy, just put some name or identifier plus the volume type like Ceph or Aws EBS in the resources section.\r\n\r\nThe there are three real problems to solve in my opinion.\r\n\r\nFirst, they need to implement some type of interface and a plugin system so Nomad can be made aware of external resources and its availability. \r\n\r\nThis isn't so easy as you think because maybe not every external resource can be mounted on every machine. It comes down how the system works. I think every system has different conditions. So Nomad need a deep understanding but at the same time a high level of abstraction. Support every use case? Not so easy!\r\n\r\nSecond, how does the actual operating system could support it. Every Nomad client would need preinstalled software to work the volumes. (Fuse etc.) \r\nMaybe tags/constraints or something to mark the task that it only can be scheduled to a client which has the specific volume software installed.\r\nHere is the question should Nomad just check for the software, should the needed software come build-in to reduce complexity or should Nomad install the needed software if it isn't installed already.\r\n\r\nThird, how does the resources get allocated/acquired. I mean does the master or client access an external api over the plugin. If it is on the client side to reduce burden for the master, how do you manage the secrets for access correctly (Env vars?). \r\n\r\nAt my hoster for example, you get one key, that gives complete access to storage. That must be managed at the master to ensure confidentially.\r\nTo ensure compatibility with everything, which I thought was Nomad goal, it would need support both the allocation on master as the client side.\r\n\r\nThat is a lot of important decision making that should not be done fast, just to support volumes. That could lead to problems later. Although I would like a quick decision ;D.\r\n\r\nIf I did get something wrong correct me @dadgar "}}
{"actor":{"display_login":"Ghostium"}}