[JIRA] [core] (JENKINS-24752) NodeProvisioner algorithm is suboptimal for fast one-off cloud
Title: Message Title Nicolas De Loof commented on JENKINS-24752 Re: NodeProvisioner algorithm is suboptimal for fast one-off cloud For docker-slaves we decided to just bypass the Cloud API. A container-based environment doesn't rely on re-used executors, so using a RetentionStrategy doesn't make sense, as to wait for any delay before provisioning a container for the build. We actually listen to the Queue for the onEntered event, which is a clear signal a build do require an executor, and add a unique label to ensure this container-executor will only be used by this specific job. This has various side effects (especially when container fails to run) that we haven't addressed yet. As the container image is defined by the job I'd like the build to still run (on a fake executor?) but get result set as NOT_BUILT with the container startup log attached. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-24752) NodeProvisioner algorithm is suboptimal for fast one-off cloud
Title: Message Title Kanstantsin Shautsou commented on JENKINS-24752 Re: NodeProvisioner algorithm is suboptimal for fast one-off cloud Sorry, who is we? Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-24752) NodeProvisioner algorithm is suboptimal for fast one-off cloud
Title: Message Title SCM/JIRA link daemon commented on JENKINS-24752 Re: NodeProvisioner algorithm is suboptimal for fast one-off cloud Code changed in jenkins User: Jesse Glick Path: demo/run.sh http://jenkins-ci.org/commit/workflow-plugin/81283c06e02f128e6c5abe774e08ed0e74e5740d Log: JENKINS-24752 Speeding up cloud slave provisioning for this relatively quick-running demo. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-24752) NodeProvisioner algorithm is suboptimal for fast one-off cloud
Title: Message Title SCM/JIRA link daemon commented on JENKINS-24752 Re: NodeProvisioner algorithm is suboptimal for fast one-off cloud Code changed in jenkins User: Jesse Glick Path: demo/run.sh http://jenkins-ci.org/commit/parallel-test-executor-plugin/f11a8e4f47bfe0b1fd935d4cff913e1d70c2e55f Log: JENKINS-24752 Noting. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-24752) NodeProvisioner algorithm is suboptimal for fast one-off cloud
Marat Mavlyutov commented on JENKINS-24752 NodeProvisioner algorithm is suboptimal for fast one-off cloud https://github.com/jenkinsci/jenkins/blame/master/core/src/main/java/hudson/slaves/NodeProvisioner.java#L280 it is pluggable now This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-24752) NodeProvisioner algorithm is suboptimal for fast one-off cloud
Kanstantsin Shautsou commented on JENKINS-24752 NodeProvisioner algorithm is suboptimal for fast one-off cloud Is it resolved now? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-24752) NodeProvisioner algorithm is suboptimal for fast one-off cloud
stephenconnolly commented on JENKINS-24752 NodeProvisioner algorithm is suboptimal for fast one-off cloud https://github.com/jenkinsci/jenkins/pull/1433 is a refactoring of NodeProvisioner that makes the strategy plugable This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-24752) NodeProvisioner algorithm is suboptimal for fast one-off cloud
stephenconnolly commented on JENKINS-24752 NodeProvisioner algorithm is suboptimal for fast one-off cloud I have some more thoughts on this, but perhaps the best solution is: to make NodeProvisioner into a plugable extension point (perhaps plugable based on label matching rules; or where all the NodeProvisioner extensions get to run until one returns an "I have made a definitive action" marker) to have the NodeProvisioner review every time a job is scheduled. That would at least allow for introducing additional strategies This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-24752) NodeProvisioner algorithm is suboptimal for fast one-off cloud
Kohsuke Kawaguchi created JENKINS-24752 NodeProvisioner algorithm is suboptimal for fast one-off cloud Issue Type: Bug Assignee: Unassigned Components: core Created: 17/Sep/14 11:33 PM Description: NodeProvisioner minimally takes the time in the order of nodeProvisioningTime + nodeProvisionerRunInterval to react to a newly submitted item in the queue. For clouds that are fast, such as docker plugin or JOCbC, nodeProvisioningTime could be 1sec or even less. And nodeProvisionerRunInterval is currently 10secs. So that ends up as a lot of waiting. The problem do get masked if the rentention strategy of the provisioned slaves keeps the slaves around, as in such a case the steady state will not involve node provisioning or deprovisioning. So the NodeProvisioner becomes irrevelant. But if the retention strategy is one-off, like docker or JOCbC, then the effect of NodeProvisioner remains visible in the steady state. Jesse suggested that perhaps NodeProvisioner should be invoked out of cycle when jobs are submitted to the queue, which removes the nodeProvisionerRunInterval term from the above equation. (03:48:56 PM) jglick: Nope, similar behavior. kohsuke: even in current trunk NodeProvisioner fails to provision as many one-shot cloud nodes as would be needed to handle the queue, even if you let things run for a long time with constant load. Is this really “as designed”? (03:49:31 PM) kohsuke: Not sure if I entirely follow, but ... (03:49:52 PM) kohsuke: in a steady state the length of the queue will approach zero (03:50:05 PM) jglick: Well you would expect that if there is a Cloud which always agrees to provision new nodes, then the queue would be close to empty. (03:50:05 PM) qma17: When running the slave from slave command line. java -jar slave.jar -jnlpUrl http://host:8080/computer/rocks/slave-agent.jnlp, I got the 403 forbidden. Because that I am loggin with user on this slave. in the JENKINS UI, it has a secret key, `-secret 4bfe7cdc6a05f29cd4421305a30f788ffaf85070aed4ba1b1fc10246c72c4ce8`, How can I pull this key automatically without manually setup on each slave? (03:50:10 PM) jglick: But in fact it stays full. (03:50:39 PM) jglick: Is there some minimum job duration below which this invariant does not hold? (03:50:50 PM) kohsuke: I thought the algorithm was basically try to keep "queueLength - nodesBeingProvisioned - idleExecutors" zero (03:51:04 PM) kohsuke: where each term is conservatively estimated between a point-in-time snapshot and moving average (03:51:30 PM) kohsuke: So in your steady state I'm curious which of the 3 terms is incorrectly computed (03:51:39 PM) jglick: For me this _expression_ is hovering around 8, where I have 11 distinct queue items. (03:52:13 PM) jglick: Nothing is idle, sometimes one or two slaves are being provisioned. (03:52:33 PM) jglick: Queue length typically 8 or 9. (03:52:42 PM) kohsuke: Are you running this with debugger? (03:53:08 PM) jglick: Yes. (03:54:03 PM) jglick: My jobs are mostly short—from 10 to 60 seconds. Maybe that is the explanation? (03:54:05 PM) kohsuke: So we want to see 3 local variables the 'idle', 'qlen', and 'plannedCapacity' (03:54:20 PM) kohsuke: ... in the NodeProvisioner.update() (03:54:43 PM) jglick: Alright, will look into it. (03:55:16 PM) kohsuke: that corresponds to 3 terms above, and you see that "conservative estimate" is implemented as max/min op (03:55:22 PM) kohsuke: between moving average and snapshot value (04:00:03 PM) shmiti: Hey, I got a question about building a plugin, if I want to add several steps options, I simply create multiple descriptors? (04:00:04 PM) jglick: Ah, do not need debugger at all, just logging on NodeProvisioner, which I already have… (04:00:24 PM) jglick: Excess workload 4.0 detected. (planned capacity=1.0547044E-9,Qlen=4.0,idle=0.0831823350,total=16m,=0.161) (04:00:45 PM) kohsuke: So it should be provisioning 4 more node (04:01:08 PM) jglick: And it does, at that time. (04:01:19 PM) kohsuke: OK, so we are waiting for it to hit the steady state? (04:02:31 PM) jglick: Well, this *is* the steady state. (04:03:17 PM) kohsuke:
