[JIRA] (JENKINS-38556) Jenkins spawns infinite windows spot instances on aws.

2016-09-28 Thread sbr...@imagus.com.au (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Steve Brain updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-38556  
 
 
  Jenkins spawns infinite windows spot instances on aws.   
 

  
 
 
 
 

 
Change By: 
 Steve Brain  
 
 
Component/s: 
 aws-java-sdk-plugin  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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] (JENKINS-38556) Jenkins spawns infinite windows spot instances on aws.

2016-09-28 Thread sbr...@imagus.com.au (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
 Steve Brain commented on  JENKINS-38556  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Jenkins spawns infinite windows spot instances on aws.   
 

  
 
 
 
 

 
 Same problem, I updated to the latest aws-java-sdk 1.11.37 from 1.10.50 library and restarted my Jenkins instance, and noticed no nodes were being created. I looked at my ec2 page and had the maximum number of allowed machines running or starting up. I terminated these and it filled up again. I immediately undid the upgrade and it started working correctly. The jenkins log was filled with these Sep 29, 2016 12:01:08 AM hudson.plugins.ec2.EC2Cloud provision INFO: Attempting to provision slave from template hudson.plugins.ec2.SlaveTemplate@1a01b2a0 needed by excess workload of 1 units of label 'cxx' Considering launching ami-63112100 for template Linux AMI Sep 29, 2016 12:01:10 AM hudson.plugins.ec2.SlaveTemplate logProvisionInfo INFO: Considering launching ami-63112100 for template Linux AMI Setting Instance Initiated Shutdown Behavior : ShutdownBehavior.Stop Sep 29, 2016 12:01:10 AM hudson.plugins.ec2.SlaveTemplate logProvisionInfo INFO: Setting Instance Initiated Shutdown Behavior : ShutdownBehavior.Stop Looking for existing instances with describe-instance: {InstanceIds: [],Filters: [ {Name: image-id,Values: [ami-63112100]} ,  {Name: instance.group-name,Values: [JenkinsSecurity]} ,  {Name: key-name,Values: [Jenkins_keys]} ,  {Name: instance-type,Values: [c3.large]} ,  {Name: tag:Name,Values: [Centos Jenkins Slave CXX]} ,  {Name: tag:Jenkins,Values: [Slave]} ],} Sep 29, 2016 12:01:11 AM hudson.triggers.SafeTimerTask run SEVERE: Timer task hudson.slaves.NodeProvisioner$NodeProvisionerInvoker@459472fa failed java.lang.NoSuchMethodError: com.amazonaws.services.ec2.AmazonEC2.createTags(Lcom/amazonaws/services/ec2/model/CreateTagsRequest;)V at hudson.plugins.ec2.SlaveTemplate.updateRemoteTags(SlaveTemplate.java:882) at hudson.plugins.ec2.SlaveTemplate.provisionOndemand(SlaveTemplate.java:585) at hudson.plugins.ec2.SlaveTemplate.provision(SlaveTemplate.java:377) at hudson.plugins.ec2.EC2Cloud.getNewOrExistingAvailableSlave(EC2Cloud.java:515) at hudson.plugins.ec2.EC2Cloud.provision(EC2Cloud.java:532) at hudson.slaves.NodeProvisioner$StandardStrategyImpl.apply(NodeProvisioner.java:701) at hudson.slaves.NodeProvisioner.update(NodeProvisioner.java:307) at hudson.slaves.NodeProvisioner.access$000(NodeProvisioner.java:60) at hudson.slaves.NodeProvisioner$NodeProvisionerInvoker.doRun(NodeProvisioner.java:798) at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:50) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Sep 29, 2016 12:01:18 AM hudson.plugins.ec2.EC2Cloud provision INFO: Attempting to provision slave from template hudson.plugins.ec2.SlaveTemplate@1a01b2a0 needed by excess workload of 1 units of label 'cxx' Considering launching ami-63112100 for template Linux AMI Sep 29, 2016 12:01:19 AM hudson.plugins.ec2.SlaveTemplate logProvisionInfo INFO: Considering launching ami-63112100 for template Linux AMI Setting Instance Initiated Shutdown Behavior : ShutdownBehavior.Stop Sep 29, 2016 12:01:19 AM hudson.plugins.ec2.SlaveTemplate logProvisionInfo INFO: Setting Instance Initiated

[JIRA] [git-client-plugin] (JENKINS-20941) Stored git credentials not used when submodule is updated

2016-05-20 Thread sbr...@imagus.com.au (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Steve Brain edited a comment on  JENKINS-20941 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Stored git credentials not used when submodule is updated  
 
 
 
 
 
 
 
 
 
 Hi,I noticed that if the .gimodules submodule name is not the same as the path spec the submodule update fails by trying to use the name.submodule defined like this fails  [submodule "rpm"]   path = linux/rpm   url = ../rpm.git with error > git config --get submodule.rpm.url # timeout=60 > git submodule update --init --recursive rpm # timeout=100FATAL: Command "git submodule update --init --recursive rpm" returned status code 1:stdout: stderr: error: pathspec 'rpm' did not match any file(s) known to git.Did you forget to 'git add'?the workaround is to name the submodule the same as the path [submodule "linux/rpm"]   path = linux/rpm   url = ../rpm.git using git 2.5.0-beta5git-client 1.20.0-beta3 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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] [git-client-plugin] (JENKINS-20941) Stored git credentials not used when submodule is updated

2016-05-19 Thread sbr...@imagus.com.au (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Steve Brain commented on  JENKINS-20941 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Stored git credentials not used when submodule is updated  
 
 
 
 
 
 
 
 
 
 
Hi, 
I noticed that if the .gimodules submodule name is not the same as the path spec the submodule update fails by trying to use the name. 
submodule defined like this fails [submodule "rpm"] path = linux/rpm url = ""> 
 with error > git config --get submodule.rpm.url # timeout=60 > git submodule update --init --recursive rpm # timeout=100 FATAL: Command "git submodule update --init --recursive rpm" returned status code 1: stdout:  stderr: error: pathspec 'rpm' did not match any file(s) known to git. Did you forget to 'git add'? 
the workaround is to name the submodule the same as the path [submodule "linux/rpm"] path = linux/rpm url = ""> 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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.