On 05/24/2015 01:09 AM, anonym wrote:
> On 05/23/2015 10:15 AM, Adam Burns wrote:
>> Hi anonym,
>>
>> On 05/23/2015 09:09 AM, anonym wrote:
>>> On 05/22/2015 01:31 PM, Adam Burns wrote:
>>>> I've taken a very quick look at this.
>>>>
>>>> As the ticket #8086 suggests, it is an issue in the way Rake is used
>>>> with a "Monkey-patched" Vagrant to build TAILS.
>>>
>>> The monkey patch is against *Vagrant*, and has nothing to do with Rake.
>>> IIRC newer versions of Vagrant has built-in authentication of the boxes,
>>> so that patch can be dropped.
>>
>> Yes, understood.
>>
>>>> Although the devs are keen to move to some other tech (Docker was
>>>> mentioned), I'm looking at removing Rake (and thus the Vagrant library
>>>> calls) from the build process if relatively easy to do so.
>>>>
>>>> I suspect rake was used to front end Vagrant in earlier days when
>>>> perhaps Vagrant was less complete, but from quick examination, I don't
>>>> think Rake is required now (nor I suspect the patching). It would
>>>> simplify things enormously and bring wider Vagrant version compatibility
>>>> across (including non-Debian) build OS environments.
>>>
>>> For the list of issues we have with Vagrant, see:
>>>
>>> https://tails.boum.org/blueprint/replace_vagrant/
>>
>> Also looked at that & related https://labs.riseup.net/code/issues/7527
>> some time back. Most of the issues appear to be solved except for the
>> library calls in the rakefile(?)
>
> Please look a bit closer. Beyond importing some constants, we hack in
> some stuff for backwards-compatibility with older versions of Vagrant
> (see more about this issue below), but there's nothing interesting there
> to be concerned about (unless I'm mistaken -- please enlighten me in
> that case).
That's pretty much what I see. Modern versions of Vagrant have internal
conditionals for Vagrant versions now, and environment variables of
course can be manipulated.
>> Both Vagrant & vagrant-libvirt (installation through available though
>> vagrant) have matured to some degree. Qemu/KVM and VirtualBox images can
>> be built in parallel, or on choice of provisioning environment from a
>> Vagrantfile.
>
> Ok, that sounds great! However, before I lost hope about Vagrant as our
> "official" build tool, my impression was that they as a project were
> moving things too fast, not caring much about backwards compatibility
> (including plugins, like vagrant-libvirt hard-depending on
> ever-increasing versions of base Vagrant), and making it very hard to
> support different versions of Vagrant at the same time. Hence our hope
> to support Debian stable + Debian testing + Debian sid + latest Ubuntu
> LTS + Ubuntu current (if not LTS). Also, it looked painful
> maintenance-wise (and has proved to be so). Perhaps it's better now, but
> it's not clear to me. Lastly, from our bluepint: "Vagrant hasn't been
> actively maintained in Debian for a while. It'll be part of Jessie, but
> that was by a very short margin", which is problematic from Tails'
> perspective.
Thanks for your insight. I was not aware of the Debian maintenance
background. Complete Vagrant eco-systems (especially with multiple
providers/provisioners) is often tricky to set up. Vagrant is a ruby/gem
application, it has its own OS dependencies, it reels in its own plugins
which also have their own OS dependencies. I happen to use a Fedora
build environment - these issues are not confined to Debian (other than
dist philosophies of conservative vs. bleeding edge, etc) :/
>> But granted my current experience has been with veewee, Vagrant, ansible
>> and VirtualBox/Qemu/KVM so may not be entirely appropriate here.
>
> It sounds relevant. Patches are certainly welcome to improve the current
> situation. Even if "we" (the "core" developers, whatever) move towards
> docker it wouldn't hurt to also keep Vagrant (with the Virtualbox
> backend, and preferably with Libvirt too) as an alternative if someone
> is committed to maintain it in Tails. And to make sure Vagrant is
> well-maintained in Debian.
>
> However, it's a bit painful that veewee (and other stuff in the Vagrant
> world we need?) isn't packaged in Debian. If "we" move to docker, it'd
> be nice if there was a tool which could convert the docker image we will
> provide into a Vagrant box.
Good thought. Haven't looked into that, although there is some emerging
Vagrant/Docker support.
>> I still hope to put in small amount of time to at least strip rake out
>> of the mix to then suggest/assess what may be possible after that :)
>
> The current Rake logic is quite nice, IMHO, and I think you must have
> misunderstood something about the whole situation. Rake is nothing else
> than a Make-like system, and we don't do anything crazy with it. I
> wouldn't be surprised if we end up adapting our current Rakefile to use
> docker in case we move to it.
Please do not misunderstand me on this! The Rakefile is indeed a clean
thing of beauty. I was just applying a self-centred KISS principle
(having used direct Vagrant build techniques), where if rake was not
adding much from a build perspective, then can it be removed from the
build process without losing functionality?
OK. Your comments have added some clarity to my thoughts. The most
simple way forward seems to be keeping rake (even if as an indirection
for future Docker or other alternatives) and just remove version
dependent vagrant library calls, checking env variables and calling
Vagrant via rake exec() or system() calls where required.
Does that sound like a sensible way forward?
Cheers!
Adam.
