{"action":"created","issue":{"url":"https://api.github.com/repos/coreos/bugs/issues/805","labels_url":"https://api.github.com/repos/coreos/bugs/issues/805/labels{/name}","comments_url":"https://api.github.com/repos/coreos/bugs/issues/805/comments","events_url":"https://api.github.com/repos/coreos/bugs/issues/805/events","html_url":"https://github.com/coreos/bugs/issues/805","id":108040924,"number":805,"title":"Add -from-s3 option to read data from S3 URL","user":{"login":"crawford","id":368848,"avatar_url":"https://avatars.githubusercontent.com/u/368848?v=3","gravatar_id":"","url":"https://api.github.com/users/crawford","html_url":"https://github.com/crawford","followers_url":"https://api.github.com/users/crawford/followers","following_url":"https://api.github.com/users/crawford/following{/other_user}","gists_url":"https://api.github.com/users/crawford/gists{/gist_id}","starred_url":"https://api.github.com/users/crawford/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/crawford/subscriptions","organizations_url":"https://api.github.com/users/crawford/orgs","repos_url":"https://api.github.com/users/crawford/repos","events_url":"https://api.github.com/users/crawford/events{/privacy}","received_events_url":"https://api.github.com/users/crawford/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-09-24T01:50:55Z","updated_at":"2015-09-24T01:50:57Z","closed_at":"2015-09-24T01:50:55Z","body":"<a href=\"https://github.com/vaijab\"><img src=\"https://avatars.githubusercontent.com/u/1308018?v=3\" align=\"left\" width=\"96\" height=\"96\" hspace=\"10\"></img></a> **Issue by [vaijab](https://github.com/vaijab)**\n_Tuesday Mar 31, 2015 at 10:53 GMT_\n_Originally opened as https://github.com/coreos/coreos-cloudinit/issues/331_\n\n----\n\nAWS launch configuration being immutable when using auto scaling groups does not help at all. S3 https URLs do not have flexible ACLs either. `coreos-cloudinit` supports reading configuration from URL already, but it has to be public, which is not ideal.\r\n\r\nSo by adding cloudinit s3:// support solves the issue described above. Do people agree? If so, I could potentially write support for that.\n"},"comment":{"url":"https://api.github.com/repos/coreos/bugs/issues/comments/142780815","html_url":"https://github.com/coreos/bugs/issues/805#issuecomment-142780815","issue_url":"https://api.github.com/repos/coreos/bugs/issues/805","id":142780815,"user":{"login":"crawford","id":368848,"avatar_url":"https://avatars.githubusercontent.com/u/368848?v=3","gravatar_id":"","url":"https://api.github.com/users/crawford","html_url":"https://github.com/crawford","followers_url":"https://api.github.com/users/crawford/followers","following_url":"https://api.github.com/users/crawford/following{/other_user}","gists_url":"https://api.github.com/users/crawford/gists{/gist_id}","starred_url":"https://api.github.com/users/crawford/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/crawford/subscriptions","organizations_url":"https://api.github.com/users/crawford/orgs","repos_url":"https://api.github.com/users/crawford/repos","events_url":"https://api.github.com/users/crawford/events{/privacy}","received_events_url":"https://api.github.com/users/crawford/received_events","type":"User","site_admin":false},"created_at":"2015-09-24T01:50:57Z","updated_at":"2015-09-24T01:50:57Z","body":"<a href=\"https://github.com/crawford\"><img src=\"https://avatars.githubusercontent.com/u/368848?v=3\" align=\"left\" width=\"48\" height=\"48\" hspace=\"10\"></img></a> **Comment by [crawford](https://github.com/crawford)**\n_Friday Apr 17, 2015 at 15:35 GMT_\n\n----\n\nTo be completely upfront, I do not like the idea of using coreos-cloudinit for configuration management. It was never designed to do this and it's really bad at it. It sounds like you want to work around the immutable nature of the auto scaling group. May I ask why? Is it for ease of development or do need this flexibility in production?\r\n\r\nThe other consideration to be made is that in order to run with this flag, your user data will need to be a script. Given that, why not implement all of the logic to fetch the \"second stage\" user data in the script? Is that a straightforward call to curl or does that require a utility?\n"}}