WIP | Consolidating fabric operations related methods#56
Open
hkumarmk wants to merge 5 commits intoJuniper:masterfrom
Open
WIP | Consolidating fabric operations related methods#56hkumarmk wants to merge 5 commits intoJuniper:masterfrom
hkumarmk wants to merge 5 commits intoJuniper:masterfrom
Conversation
Current method - copy ssh private key to remote node1 and then try to ssh using that key file - is not required, as ssh-agent forwarding will enable such facility without ssh private keys present in subsequent machines. You just need private key on test node and no need to copy private key to anywhere else, just run ssh-agent on test node and run the command on remote nodes (even between remote nodes with agent forwarding enabled. Added tools/common.sh with common bash functions. Added a new function "prepare" and also added a new parameter to run only "prepare". This will be helpful in case of manually running tests which actually need running tools/configure.py as well as starting ssh-agent on test node.
This is to refactor certain common code to central place and to reuse them. Current effort is to consolidate methods which use fabric operations to single place and avoid importing fabric module to various other files but to use the methods from fabutils.
This method to be used to run command on any remote nodes - whether it
is a remote server or VM or between VMs. This method has capability to
handle:
1. run remote command on remote server from test node
2. Run remote command on node-a through node-b from the test node
* in this case node-a is the target node, node-b is gateway, and the
nodes will be connect from testnode
* This is to avoid situation to login to remote node (node-b in this
case) and run script (fab script or pexpect or any such code) on
that remote node (node-b) against running command on target node
(node-a)
3. Run remote command on VM thorugh compute node - Same usecase as of Juniper#2
4. Run remote commands between VMs - say copy a file from vm1 to vm2
through compute node of vm1.
* This will use ssh-agent forward to avoid copying ssh private keys to
subsequent servers - Previously we used to copy ssh private keys to
compute node and then copy the same file to vm1 in order to be able
to connect from vm1 to vm2.
* The commands will be running sitting on the test node then run an
* "ssh/scp" command on vm1 through compute node of vm1 with
agent_forward on
* in this case flow is like this: test_node ->
compute_of_vm1(gateway - passthrough) -> vm1 (run ssh/scp there) ->
vm2 (final command is run)
NOTE that in all above situations ssh is initiated from the test node
and NO NEED TO SSH TO ANY OTHER NODE AND RUN SSH/FAB COMMANDS FROM
THERE.
Removed run_fab_cmd_on_node from the codebase and replaced all occurances of it with run_cmd.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.