Bug 17410 - let --remote optionally handle compilation from afar too
Summary: let --remote optionally handle compilation from afar too
Status: RESOLVED WONTFIX
Alias: None
Product: systemtap
Classification: Unclassified
Component: translator (show other bugs)
Version: unspecified
: P2 enhancement
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-18 17:55 UTC by Josh Stone
Modified: 2017-05-08 20:40 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Josh Stone 2014-09-18 17:55:47 UTC
Right now when using remote, you must either have a local environment for compiling to the target, or enable a compile server for that.  But there may be cases where the remote targets are already capable of compiling stap modules themselves, and we could let them do so directly.

The user would still get to write their script locally however they like, and can also get the fanout of running it on multiple --remote targets at once.

This would have similar questions as the compile server as to what to ship from the user to remote -- at least the script and -I tapsets, and all the options except remote itself.  But this wouldn't have the same security considerations as the compile server, because --remote works as an authenticated user already.

A new --remote-compile option might be the trigger for this new behavior.
Comment 1 Frank Ch. Eigler 2017-05-08 20:40:06 UTC
unlikely to do; for such 'thick hosts', an %ssh host stap ... could do