On Mon, 2011-01-24 at 12:28 -0500, Kamil Paral wrote:
----- Original Message -----
>
> > host.run('rm -rf %s; mkdir -p %s' % (dir_, dir_))
> > host.send_file(dir_, dir_)
>
> The delete_dest=True argument for autotest host.send_file() attempts
> to
> handle this for us. In fact, they use the same/similar commands that
> you list above.
>
> delete_dest: if this is true, the command will also clear
> out any old files at dest that are not in the
> source
>
> I didn't do exhaustive testing to ensure that delete_dest was honored,
> but can queue that up shortly. I'd like to have the built-in autotest
> delete_dest= support working, but we can certainly use the above if
> the
> autotest support is broken or not patchable in the short-term.
It's simple. Try to do:
host.send_file('/etc/autoqa', '/etc/autoqa', delete_dest=True)
This won't work with rsync, it will create /etc/autoqa/autoqa even
if the destination doesn't exist. On the other hand, it will work
with scp if the destination doesn't exist, but it won't work if
the destination does exist (it will create /etc/autoqa/autoqa).
So let's try:
host.send_file('/etc/autoqa/', '/etc/autoqa/', delete_dest=True)
This will work with rsync in both cases (destination exists and
doesn't exist). But scp will fail if the destination doesn't exist.
Broooken! :-)
Okay, I'll try this soon ... I'd like to fix autotest if possible.
The easiest workaround is to remove and re-create the destination
manually and always use slashes.
That'll work if needed.
> How about just using packaging instead of recreating all the
> "packaging"
> tasks manually. Seems like it would be beneficial to only maintain one
> "packaging" scenario. My assumption with the original patch was that
> all code would be packaged and published in a repo somewhere, even for
> a
> staging instance. For staging code, some cronjob would git checkout,
> attempt a build and update the 'testing' repo [1] with the build
> results. This mimics the behavior for official Fedora updates and lets
> existing mechanisms deal with packaging.
>
> The goal with the original patchset was from an idea you gave me.
> Basically, making it *really* effortless to add a new system and start
> scheduling tests to it. I was able to hide all the package install and
> configuration into the site_autotest.py. While it seemed to work, I'm
> not convinced we want to put all AutoQA setup into this method. I
> liked
> it, but as coded, anyone with the autoqa and autotest-server packages
> installed will get autoqa installed+configured on *all* of their test
> clients. I may need to make this support optional by way of a
> global_config.ini setting.
I can imagine this could work just fine for production and
staging environment. But there is one use case missing, and that
is the development environment. Basically, when I'm developing
AutoQA on my server+client(s), I don't want to replicate every
change I make onto all those machines. That's really tedious.
Also I'm often quite confused where to make this change (on the
server/on the client/on all machines). It depends on which part
of AutoQA I'm currently working on (hooks/harness/library/tests).
Ah, good use case. Can we think of any reason that the autoqa code on
the server shouldn't match the code on the clients? Eventually, we will
have mixed client environment (i386/x86_64/$other using f15, f14, f13
epel5 etc...).
This implies that our code must work for all supported releases.
Meaning, we can't have autoqa-0.4.4-1.el5 but autoqa-0.4.4-2 for f14. I
don't have a problem with this, I typically build new packages for all
supported releases. But just want to confirm
My dream is to do any change on the server only, and it gets
propagated to all clients. I can do that using rsync, but yes,
it's not as clean as using rpm packages (which you can't use
for development anyway).
I'll have to think more about it, tomorrow.
This is a cool idea. Let's do it!
>
> So my recommendation would be ...
> 1. Adjust autotest-server %requires to add rsync and
> openssh-{clients,server}
Actually only the autotest client requires openssh-server. (But it is
kind of obvious because you need to register it with the server and
for that you need openssh-server installed.)
Both the server and the client require openssh-clients (and preferably
also rsync).
Okay
Thanks,
James