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
Add remote file operations #1538
Conversation
and:
|
@susebot run deploy |
Commit ba1732a is OK. |
@susebot run deploy |
Commit afb5e5a is OK. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks perfect otherwise!
args = 'set -ex' + '\n' + args | ||
self.run(args=args, stdin=data) | ||
|
||
def sudo_write_file(self, path, data, **kwargs): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO, sudo_write_file()
is not super-convenient compared to write_file(path, data, sudo=True)
. So I won't mind not having sudo_write_file()
.
But, yes, not having it would break many tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can delete it, I don't it can break anything because it is new function, I added because someone might think it handy to use sudo_write_file
because of shorter syntax.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But, yes, not having it would break many tests.
this is why we do not delete teuthology.misc.sudo_write_file
but make it use remote.write_file(sudo=True)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'd like to see PRs on ceph side which use the newly added functions. otherwise these new methods are just unused and untested.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tchaikov it is already used there, through misc.sudo_write_file, check there logs:
https://pulpito.ceph.com/kyr-2020-07-16_20:09:04-rados:cephadm-master-distro-basic-smithi/
You can find there a 'dd' command.
Even if you don't see it used in upstream ceph, it does not mean we (mostly me) do not plan to use it downstream.
I agree we can add more test cases, however it is "tested" through misc api.
I don't want to refactor and go through the PRs on ceph side now and go through the all cycles of merging and backporting.
I'm more comfortable to do this later, this is why a deprication message.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tchaikov what do you have on mind, to backport it to 'octopus', 'nautilus', or also py2 depended branches 'luminous' and correspondingly backport this PR to teuthology py2?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tchaikov is that kind of PR do you expect? ceph/ceph#36211
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[OT] also, please let me know if you are going to work on ceph/ceph#35674 (comment) ? if not, i will cherry-pick the fixes.
Do you suggest to finish it before merging this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[OT] also, please let me know if you are going to work on ceph/ceph#35674 (comment) ? if not, i will cherry-pick the fixes.
Do you suggest to finish it before merging this PR?
no, it's not related to this changeset. i marked "[OT]" (short for off-topic) here. as per your reply, i just realized that you are not likely to work on backports. hence the question.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, it's not related to this changeset. i marked "[OT]" (short for off-topic) here. as per your reply, i just realized that you are not likely to work on backports. hence the question.
thanks for the remark, sorry sometimes I'm bad to decode things like "ot". Regarding backport, sooner or later I might work on it. But not right now. So go ahead and cherry-pick it.
chown = 'sudo chown' if sudo else 'chown' | ||
args += '\n' + chown + ' ' + owner + ' ' + path | ||
args = 'set -ex' + '\n' + args | ||
self.run(args=args, stdin=data) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I must also mention that I would prefer returning the return value of self.run()
since access to the object representing the process can allow better testing and troubleshooting. Applies to this method as well as to other methods here and in misc.py
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I said, we don't need trouble shoot write_file (it is a utility function which always should work), we need to stop as fast as possible and analize logs, even more, it is bad to continue execution because it make more troubles to figure out the first source of the failure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, if we want more control on error handling I would prefer to specific exception produced by the file operation, so the user don't need to check output of the script of write_file. We need to declare all specific to the function exception in the doc for the function and we must not let user to do this instead of us, because the code of script can be changed and will be very difficult to support. Basically user should not use anything about internals of functions like write_file and treat it as blackbox.
setup.py
Outdated
@@ -49,6 +49,7 @@ | |||
'Topic :: System :: Filesystems', | |||
], | |||
install_requires=['apache-libcloud', | |||
'Deprecated >= 1.2.10', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
instead of introducing yet another dependency, i'd suggest just update all the callers of the deprecated functions, and then drop them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the problem with introducing new dependency which is useful?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'd suggest just update all the callers of the deprecated functions, and then drop them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tchaikov I've dropped the dependency.
1060c6a
to
b58a76c
Compare
57c7654
to
a10871e
Compare
retest this please |
a10871e
to
1f74b1c
Compare
Add advanced write_file and sudo_write_file to remote context for more intuitive and handy coding Signed-off-by: Kyr Shatskyy <kyrylo.shatskyy@suse.com>
1f74b1c
to
8d001b1
Compare
Deprecate misc.write_file() and misc.sudo_write_file() in favor of the orchestra.remote package methods. The code of the misc's methods is now calling the remote's ones. Signed-off-by: Kyr Shatskyy <kyrylo.shatskyy@suse.com>
The misc.append_lines_to_file method has been using get remote file to temporary file and then write back to remote host. The orchestra.remote.write_file method has 'append' parameter when using which there is no data downloaded from remote host. Signed-off-by: Kyr Shatskyy <kyrylo.shatskyy@suse.com>
8d001b1
to
2790fa9
Compare
@susebot run deploy |
Commit 2790fa9 is OK. |
@susebot run deploy |
Signed-off-by: Kyr Shatskyy <kyrylo.shatskyy@suse.com>
e13a356
to
ab6fa1d
Compare
Commit e13a356 is OK. |
chown = 'sudo chown' if sudo else 'chown' | ||
args += '\n' + chown + ' ' + owner + ' ' + dst | ||
args = 'set -ex' + '\n' + args | ||
self.run(args=args) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'd suggest rewrite this using a helper function for adding optional sudo
and f-string, but my suggestion was dropped by accident when posting it. i will add a follow-up PR later on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the heads up, I also would like to backport this patch to py2, however I'm not sure that I will do that, hopefully we will not need py2 based branches of teuthology downstream in couple of months.
No description provided.