Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JENKINS-39370,JENKINS-39369] - Support of work directories in Remoting #129

Merged
merged 24 commits into from
May 7, 2017

Conversation

oleg-nenashev
Copy link
Member

@oleg-nenashev oleg-nenashev commented Oct 31, 2016

This pull requests adds a basic support of workspaces to Remoting. It offers options, which allow enabling workspaces for JNLP and SSH agents in Jenkins.

  • In the original implementation we had no way to determine working directory on startup. Remoting itself didn't know about workspaces even if it was a Jenkins agent/slave
  • With previous parameters the remoting behavior does not change
  • The change will require additional configuration on the Jenkins side to enable workspaces by default

Scope of changes:

  • Introduce concept of working directory in the remoting (should be compatible with Jenkins agents) - JENKINS-39370
  • Automatically create STDERR and STDOUT outputs if the workspace is enabled - JENKINS-39369
  • Use alternate JAR cache location if workspace is specified JENKINS-18578
  • Add option to fail the agent startup if the workdir does not exist JENKINS-39130
  • Functional tests
  • Automatic Logrotate for logs within workdir. Should be manageable by JUL settings
  • Documentation
  • Adjust logging to make it compliant with docs, add support of JUL property files

Potential improvements:

  • Postponed: specifying workdir after the agent startup (let Jenkins enable it?)
  • TBD: other magic to automagically determine Workdir in a compatible way


if (slaveLog != null) { // Legacy behavior
System.out.println("Using " + slaveLog + " as an agent Error log destination. 'Out' log won't be generated");
System.out.flush(); // Just in case the channel
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing words/sentence end in the comment?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep

if (!workDir.isDirectory()) {
throw new IOException("The specified agent working directory path points to a non-directory file");
}
if (!workDir.canWrite() || !workDir.canRead() || !workDir.canExecute()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should/couldn't it just (try to) create it? Like for .jenkins will just be created if absent?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It creates it on-demand. This code is being executed only for existing files

System.setErr(new PrintStream(new TeeOutputStream(System.err,
new FileOutputStream(new File(internalDirPath.toFile(), "remoting.err.log")))));
System.setOut(new PrintStream(new TeeOutputStream(System.out,
new FileOutputStream(new File(internalDirPath.toFile(), "remoting.out.log")))));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if this wouldn't be easier, for diagnostics purposes, to just output in a single file, and use JUL (I don't like it very much, but as it's already present in the JDK and Jenkins code already uses it in general...) or another logging API to distinguish between messages severities. E.g. here we don't have the dates of the logs, so it would make btw it hard or impossible to correlate .err logs to .out ones, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was considering it, but unfortunately SOME of executions on agents in plugin implementations write to STDOUT/STDERR instead of using JUL or whatever other logging. Hence we have to maintain such low-level API. Otherwise I would just implement JUL appender

@oleg-nenashev oleg-nenashev changed the title [JENKINS-39370,JENKINS-39369] - Improve logging of agents [JENKINS-39370,JENKINS-39369] - Support of working directories in Remoting Nov 16, 2016
*/
public synchronized void startEngine() throws IOException {
// Prepare the working directory if required
final Path path = WorkDirManager.getInstance().initializeWorkDir(workDir.toFile(), internalDir, failIfWorkDirIsMissing);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally should be moved to /remoting/logs and logrotated

@oleg-nenashev
Copy link
Member Author

Tests pass for me locally. I have no idea how these changes cause such failure in the Channel property. And #132 works like a charm

@oleg-nenashev
Copy link
Member Author

@reviewbybees would be useful

Copy link
Member

@stephenc stephenc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks mostly ok, I think you can use the aliases for slaveLog and rename it now. I also wonder if you have missed passing slaveLog through

* If specified, this option overrides the default destination within {@link #workDir}.
* If both this options and {@link #workDir} is not set, the log will not be generated.
*/
@Option(name="-slaveLog", usage="Local agent error log destination (overrides workDir)")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Option(name="-agentLog", aliases={"-slaveLog"}, ... and be done with the rename

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was considering renaming.
My main concern about agent is that we will have Jenkins agent and remoting agentterms. And they won't be equal in general.

jnlpArgs.add(internalDir);
jnlpArgs.add("-failIfWorkDirIsMissing");
jnlpArgs.add(Boolean.toString(failIfWorkDirIsMissing));
}
if (candidateCertificates != null && !candidateCertificates.isEmpty()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pass through slaveLog/AgentLog?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is https://issues.jenkins-ci.org/browse/JENKINS-39817 for it. I'm not a big fan of adding this option since we are going to have the workDir now. But maybe it's good for the code consistency

* @throws IOException Verification failure
*/
private static void verifyDirectory(@Nonnull File dir, @Nonnull DirType type, boolean failIfMissing) throws IOException {
if (dir.exists()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I would expect the process to try to create the directory path if it is missing and complain if it can't create the directory.


/**
* Sets up logging subsystem in the working directory.
* It the logging system is already initialized, do nothing
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If

@oleg-nenashev
Copy link
Member Author

@reviewbybees No additional reviews required right now. Will push the logrotate support soon as we have discussed with @stephenc

@jglick
Copy link
Member

jglick commented Feb 17, 2017

JENKINS-18578 seems like the most critical change.

@stephenc suggested doing it in the PR, so I decided to address it as a part of JENKINS-39370.
But the code still has initialization in hudson.remoting.Launcher for other logging modes.
@oleg-nenashev oleg-nenashev changed the title [JENKINS-39370,JENKINS-39369] - Support of working directories in Remoting [JENKINS-39370,JENKINS-39369] - Support of work directories in Remoting May 2, 2017
@oleg-nenashev
Copy link
Member Author

oleg-nenashev commented May 3, 2017

@reviewbybees I am working on extra functional tests, but the core logic & documentation is ready to review

@ghost
Copy link

ghost commented May 3, 2017

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

@oleg-nenashev
Copy link
Member Author

@reviewbybees Tests are also ready, so it can be reviewed. I will post the design doc by tomorrow.

@recampbell recampbell requested a review from jglick May 5, 2017 15:48
Copy link
Member

@stephenc stephenc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes since my last revew LGTM

@oleg-nenashev
Copy link
Member Author

@reviewbybees done. I will do more testing in downstream PRs

@oleg-nenashev oleg-nenashev merged commit 76c9b8c into jenkinsci:master May 7, 2017
@oleg-nenashev oleg-nenashev deleted the feature/JENKINS-39370 branch May 7, 2017 07:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants