{"action":"created","issue":{"url":"https://api.github.com/repos/jenkinsci/jenkins/issues/1448","labels_url":"https://api.github.com/repos/jenkinsci/jenkins/issues/1448/labels{/name}","comments_url":"https://api.github.com/repos/jenkinsci/jenkins/issues/1448/comments","events_url":"https://api.github.com/repos/jenkinsci/jenkins/issues/1448/events","html_url":"https://github.com/jenkinsci/jenkins/pull/1448","id":47410297,"number":1448,"title":"Allow clouds to launch slaves with job-specified parameters","user":{"login":"magnayn","id":53653,"avatar_url":"https://avatars.githubusercontent.com/u/53653?v=3","gravatar_id":"","url":"https://api.github.com/users/magnayn","html_url":"https://github.com/magnayn","followers_url":"https://api.github.com/users/magnayn/followers","following_url":"https://api.github.com/users/magnayn/following{/other_user}","gists_url":"https://api.github.com/users/magnayn/gists{/gist_id}","starred_url":"https://api.github.com/users/magnayn/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/magnayn/subscriptions","organizations_url":"https://api.github.com/users/magnayn/orgs","repos_url":"https://api.github.com/users/magnayn/repos","events_url":"https://api.github.com/users/magnayn/events{/privacy}","received_events_url":"https://api.github.com/users/magnayn/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2014-10-31T15:58:25Z","updated_at":"2015-06-03T12:10:21Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/jenkinsci/jenkins/pulls/1448","html_url":"https://github.com/jenkinsci/jenkins/pull/1448","diff_url":"https://github.com/jenkinsci/jenkins/pull/1448.diff","patch_url":"https://github.com/jenkinsci/jenkins/pull/1448.patch"},"body":"We would like to be able to add parameters into a build to contain\r\na setting for various slave parameters - for example, a docker volume\r\nthat contains a Jenkins workspace.\r\n\r\nThis would enable that workspace to be 'passed up' through a build pipeline\r\nto subsequent stages.\r\n\r\nHowever - with the current API, there is no way of the slave launcher\r\nknowing what additional slave startup parameters that it needs. By the\r\ntime the slave is constructed, this is too late - such settings can only\r\nbe applied at slave construction time.\r\n\r\nThus there is a need for the slave launcher to be aware of (optional)\r\nparameters that it can use in order to control the slave that it is\r\nlaunching.\r\n\r\nSo -\r\n\r\n- create a new CloudProvisioningRequest object, that contains the existing\r\nsettings (Label, Excess Workload), and a list of 'Actionable' items that\r\nit is passed. Add a provision option into the Cloud class (default impl\r\nfor backwards compatibility to be the old provision impl).\r\n\r\nThese Actionable items are, in effect, the builds in the queue. The cloud\r\nsubclass can examine this queue and pull off builds. From there it would\r\nlook for the ParametersAction, and the Parameters stored within. Cloud\r\nimplementations will provide their own ParameterDefinition/Values that\r\nthey look for.\r\n\r\nOnce a slave is launched, we need to make sure the 'right' job is attached\r\nto the 'right' slave. Fortunately, all a cloud implementation needs to do\r\nis add a NodeProperty to the launched slave, which Jenkins will ask\r\n'canTake' to see if a buildable item is appropriate for this slave. All\r\nthe slave then needs to do is say it's not appropriate for that node if\r\nthe launch parameters don't match the build parameters.\r\n\r\nSigned-off-by: Nigel Magnay <nigel.magnay@gmail.com>"},"comment":{"url":"https://api.github.com/repos/jenkinsci/jenkins/issues/comments/108348650","html_url":"https://github.com/jenkinsci/jenkins/pull/1448#issuecomment-108348650","issue_url":"https://api.github.com/repos/jenkinsci/jenkins/issues/1448","id":108348650,"user":{"login":"stephenc","id":209336,"avatar_url":"https://avatars.githubusercontent.com/u/209336?v=3","gravatar_id":"","url":"https://api.github.com/users/stephenc","html_url":"https://github.com/stephenc","followers_url":"https://api.github.com/users/stephenc/followers","following_url":"https://api.github.com/users/stephenc/following{/other_user}","gists_url":"https://api.github.com/users/stephenc/gists{/gist_id}","starred_url":"https://api.github.com/users/stephenc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/stephenc/subscriptions","organizations_url":"https://api.github.com/users/stephenc/orgs","repos_url":"https://api.github.com/users/stephenc/repos","events_url":"https://api.github.com/users/stephenc/events{/privacy}","received_events_url":"https://api.github.com/users/stephenc/received_events","type":"User","site_admin":false},"created_at":"2015-06-03T12:10:21Z","updated_at":"2015-06-03T12:10:21Z","body":"The issue I see with this is that you need a way to flag that a `PlannedNode` is going to satisfy some of these `Actionable` items that are waiting for the label.\r\n\r\nSo while the idea of moving to a request object is a good pattern to follow, my belief is that this change as currently envisioned will not solve the problem you describe.\r\n\r\nWhat we really need to have is some other kind of `Label`-like marker for tasks that can contain the extra information. Labels are really a specialized form of these markers and as such we should really be provisioning against markers and not against Labels as that would let us ensure that nodes are provisioned correctly.\r\n\r\nThe other thing is that I suspect your use of the current Cloud API is not aligned with its original vision.\r\n\r\nThe original vision of the Cloud API is that the future that gets wrapped in the PlannedNode represents all the work required to provision the node and configure it correctly. A simple launcher should be returned. What I see happening in most implementations of the Cloud API is that the future returns too early and then people use a custom launcher that \"waits\" for the node to be ready. As such the node customization should happen in the future so that the correct Node instance is constructed and returned *only when it is ready to be connected to*.\r\n\r\n> Thus there is a need for the slave launcher to be aware of (optional)\r\nparameters that it can use in order to control the slave that it is\r\nlaunching.\r\n\r\nis not really correct in that respect, because you should not be returning a custom slave launcher rather just one of the standard ones. The `Callable<Node>` that has been submitted to `Computer.threadPoolForRemoting` and is linked to the `PlannedNode.future` is what needs to be aware of (optional) parameters"}}