Merge lp://qastaging/~doanac/lava-lab/lava-scripts into lp://qastaging/lava-lab

This looks awesome!

One general comment: you don't need to run l-d-t as root. I did the following
on the vagrant-bootstrap script inside the l-d-t repo:

if ! test -d /srv/lava/instances/development; then
  cd $basedir
  su vagrant -c './lava-deployment-tool setup -nd'
  su vagrant -c './lava-deployment-tool install -nd development'
fi

so you could do something like that, and you won't need to chown/chmod away, or
even add that check on l-d-t to allow running as root.

--
Antonio Terceiro
Software Engineer - Linaro
http://www.linaro.org

On 02/05, Antonio Terceiro wrote:
> One general comment: you don't need to run l-d-t as root. I did the following
> on the vagrant-bootstrap script inside the l-d-t repo:
>
> if ! test -d /srv/lava/instances/development; then
> cd $basedir
> su vagrant -c './lava-deployment-tool setup -nd'
> su vagrant -c './lava-deployment-tool install -nd development'
> fi

You must be setting up your "vagrant" user to allow password-less sudo?
We don't do that for our instance-manager and it seems a little scare
(to me) to allow that.

> so you could do something like that, and you won't need to chown/chmod away, or
> even add that check on l-d-t to allow running as root.

On Tue, Feb 05, 2013 at 06:46:22PM -0000, Andy Doan wrote:
> On 02/05, Antonio Terceiro wrote:
> > One general comment: you don't need to run l-d-t as root. I did the following
> > on the vagrant-bootstrap script inside the l-d-t repo:
> >
> > if ! test -d /srv/lava/instances/development; then
> > cd $basedir
> > su vagrant -c './lava-deployment-tool setup -nd'
> > su vagrant -c './lava-deployment-tool install -nd development'
> > fi
>
> You must be setting up your "vagrant" user to allow password-less sudo?
> We don't do that for our instance-manager and it seems a little scare
> (to me) to allow that.

in that case we could setup password-less sudo for instance-manager
exclusively for running the lava-deployment-tool command.

--
Antonio Terceiro
Software Engineer - Linaro
http://www.linaro.org

Andy Doan <email address hidden> writes:

> Andy Doan has proposed merging lp:~doanac/lava-lab/lava-scripts into lp:lava-lab.
>
> Requested reviews:
> Linaro Validation Team (linaro-validation)
>
> For more details, see:
> https://code.launchpad.net/~doanac/lava-lab/lava-scripts/+merge/146547
>
> start work on some helper functions that should allow us to manage lava deployments using salt
> --
> https://code.launchpad.net/~doanac/lava-lab/lava-scripts/+merge/146547
> You are subscribed to branch lp:lava-lab.
> === modified file '_grains/lava.py'
> --- _grains/lava.py 2013-01-10 16:37:55 +0000
> +++ _grains/lava.py 2013-02-05 04:19:20 +0000
> @@ -9,4 +9,10 @@
> p = os.path.join(instdir, f)
> if os.path.isdir(p):
> insts.append(p)
> + # This seems to be a bug in salt. Even after you reload/resync grains
> + # the module still uses what it read at the time the minion started up.
> + # this makes this dynamic so we don't have to restart salt just to see
> + # a new instance
> + if 'lava_instances' in __grains__:
> + __grains__['lava_instances'] = insts

Thats because grains are supposed to be invariant. From
http://docs.saltstack.org/en/latest/topics/targeting/grains.html:

    It is important to remember that grains are bits of information
    loaded when the salt minion starts, so this information is
    static. This means that the information in grains is unchanging,
    therefore the nature of the data is static. So grains information
    are things like the running kernel, or the operating system.

I think grains-but-varying-things are "pillars", but not completely
sure. Might be worth asking #saltstack IRC...

On 02/05, Antonio Terceiro wrote:
> in that case we could setup password-less sudo for instance-manager
> exclusively for running the lava-deployment-tool command.

l-d-t runs too many sudo commands to make a sane sudoers entry. Its
really an all or nothing approach. So I'd say we just allow this hack in
l-d-t for now.