Page MenuHomePhabricator

Execution error after moving to debian package
Closed, ResolvedPublic


@Marostegui reported fails after using the debian package for deployment:

1root@cumin1001:/home/marostegui# --no-compress --no-encrypt --no-checksum db1117.eqiad.wmnet:/srv/sqldata.m2 db1080.eqiad.wmnet:/srv
2ERROR: The specified target path /srv doesn't exist on db1080.eqiad.wmnet
6root@db1080:/srv# ls
7sqldata sqldata.m2 tmp
9root@db1080:/srv# rm -fr sqldata.m2/ sqldata
12root@cumin1001:/home/marostegui# --no-compress --no-encrypt --no-checksum db1117.eqiad.wmnet:/srv/sqldata.m2 db1080.eqiad.wmnet:/srv
13ERROR: The specified target path /srv doesn't exist on db1080.eqiad.wmnet
15 can be called and can show help normally, but it always says directory not exists (even if it does).

Funnily, HEAD works ok when locally cloned and used. My guess it is some path issue when building/installing the package + bad error reporting. E.g. cumin fails to be called but reports as "directory not found"? Or could be an infrastructure issue.

Testing environment would be key to debug the issue.

Event Timeline

In our testing environment, I am currently using the Debian package only. Let me see what could be this issue!

Can we get a --verbose output, that would tell us if it is the problem with Cumin?

--verbose was the first thing I tried, but it didn't work either, it just showed the same error. Maybe the package I created was faulty? I will try to build it again with HEAD.

Change 608475 had a related patch set uploaded (by Jcrespo; owner: Jcrespo):
[operations/puppet@production] Revert "Revert "mariadb-backups: Move transferpy deployment to debian package"" /608475

I rebuilt, and it works again. Maybe I had uploaded an earlier version of the package?

Actually, I never got that error. I will have a look for the possibility of that error.

Change 608475 merged by Jcrespo:
[operations/puppet@production] Revert "Revert "mariadb-backups: Move transferpy deployment to debian package"" /608475

jcrespo claimed this task.

So I think this was a deployment issue only, something about building the package or configured paths leftover from the previous installations. This looks resolved now.