Rundeck Rundeck Development

Comments and changes to this ticket

• 

  Alex-SF February 23rd, 2011 @ 09:28 AM

  • Assigned user set to “Alex-SF”

  Do you imagine that this kind of step is done prior to the execution of the workflow or during it's course of execution?

• You flagged this item as spam.
  

  John Wyles March 15th, 2011 @ 03:26 PM

  The upload would happen prior to the execution of the workflow, stored in a configurable path on the RunDeck server, and then:
  A) Subsequently uploaded to host(s) tagged by the job which in turn perform some set of operations on this resource (e.g. if a shell script it could be executed, if it was a tar ball it could be untarred and ./configure && make && make install, if it is an RPM it could be installed locally, it is is a JPEG it could be resized and put into a certain path, etc.) by the defined job it was attached to

  B) Simply be manipulated or operated upon by the RunDeck server itself (e.g. take a log file and grep it for some contents, take a JPEG file, make it a PNG file, and give me the file size, etc.) - perhaps some poor examples but it might be useful from the RunDeck server to merely operate on the files and not have to, in turn, upload them to other host(s)

  To explain B a bit better the job can be entirely selfcontained within the RunDeck server itself for operating on these uploaded resources just as well as it can take and pass on that uploaded resource to the hosts defined for some jobs.

• 

  Alex-SF March 15th, 2011 @ 04:31 PM

  A few questions: Would this file be something that lives beyond the job execution? Does it live in a workspace akin to Jenkins/Hudson build workspace (that might be cleared between executions). Is it accessible by URL during and after the execution. Should they be listable via a Rundeck interface?

• You flagged this item as spam.
  

  John Wyles March 15th, 2011 @ 07:13 PM

  A few questions: Would this file be something that lives beyond the job execution? Does it live in a workspace akin to Jenkins/Hudson build workspace (that might be cleared between executions).

  A very thoughtful consideration, I would imagine it could live in the job execution history as an attached resource and therefore, when jobs are rerun (perhaps tuning parameters, etc.) it would not need to be included again. perhaps some configurable logic (not unlike Jenkins/Hudson) around number of job execution resources to keep around (after, say 100 resources attached to jobs, job 101 in history would have bold red text saying "resource too old and no longer attached please attach a resource")

  Is it accessible by URL during and after the execution. Should they be listable via a Rundeck interface?

  I am not so sure this is necessary, at least initially, unless it is thought that this "loose API" definition for the resource could be used for fetching it from the dispatched nodes - it could be that rather than an SCP/SFTP/FTP of the file to the host it is curl'ed from these hosts instead from the RunDeck API defined for fetching the resource. And while we're at it why not list them in the RunDeck interface :o)

• You flagged this item as spam.
  

  John Wyles April 26th, 2011 @ 09:54 AM

  Any updates on this issue?

• You flagged this item as spam.
  

  Michael Gibson April 12th, 2012 @ 04:38 PM

  +1

• You flagged this item as spam.
  

  ardthurxen (at gmail) June 18th, 2016 @ 05:54 PM

  • Title changed from “Feature Request: Resource upload dialog” to “YYdscvafZTgajkdfv”
  • Assigned user changed from “Alex-SF” to “Greg Schueler”

  [b]Gtczxvdg[/b] http://fxfskrddfbxdf.com here: [b]Gtczxvdg[/b] http://fxfskrddfbxdf.com
  [b]best Gtczxvdg[/b] http://fxfskrddfbxdf.com [url=http://fxfskrddfbxdf.com][b]Maefegvtjy[/b][/url] dfsdgbcdsHLBHFDasufksdfjln [b][url=http://fxfskrddfbxdf.com]Maefegvtjy[/url][/b]
  Ozxcjkl [url=http://fxfskrddfbxdf.com]Maefegvtjy[/url] dfdfdfdsdgd
  FGxczDHXfgvdhjhjhjhsdadddfxgbnbm