Closed Bug 756076 Opened 12 years ago Closed 10 years ago

Clean up TBPL Vagrant/Puppet setup warnings

Categories

(Tree Management Graveyard :: TBPL, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: emorley, Assigned: emorley)

References

Details

Attachments

(1 file)

Using http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/rev/0c3f709b0c37 I get the following warnings after running vagrant up with VirtualBox v4.1.14 & Vagrant v1.0.3 on Win7 x64:

{
c:\mozilla\tbpl>vagrant up
[default] Importing base box 'lucid32'...
[default] Matching MAC address for NAT networking...
[default] Clearing any previously set forwarded ports...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] Creating shared folders metadata...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Running any VM customizations...
[default] Booting VM...
[default] Waiting for VM to boot. This can take a few minutes.
[default] VM booted and ready for use!
[default] Configuring and enabling network interfaces...
[default] Mounting shared folders...
[default] -- v-root: /vagrant
[default] -- tbpl-code: /var/www/tbpl
[default] -- manifests: /tmp/vagrant-puppet/manifests
[default] Running provisioner: Vagrant::Provisioners::Puppet...
[default] Running Puppet with /tmp/vagrant-puppet/manifests/init.pp...
stdin: is not a tty
warning: Could not retrieve fact fqdn
warning: Host is missing hostname and/or domain: lucid32
notice: /Stage[main]/Tbpl-base/Exec[/usr/bin/apt-get update]/returns: executed successfully
...
...
}

The VM starts successfully (most of the time at least; but that's a Vagrant/VirtualBox problem) - it's just the warnings led me down a false trail when debugging the other issue, so it would be ideal if they were suppressed or otherwise remedied :-)
Summary: Clean up TBPL Vagrant setup warnings → Clean up TBPL Vagrant/Puppet setup warnings
With Vagrant 1.5.3 I get:

[/c/src/tbpl]$ vagrant up
There were warnings and/or errors while loading your Vagrantfile
for the machine 'default'.

Your Vagrantfile was written for an earlier version of Vagrant,
and while Vagrant does the best it can to remain backwards
compatible, there are some cases where things have changed
significantly enough to warrant a message. These messages are
shown below.

Warnings:
* `config.vm.customize` calls are VirtualBox-specific. If you're
using any other provider, you'll have to use config.vm.provider in a
v2 configuration block.

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'lucid32' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Adding box 'lucid32' (v0) for provider: virtualbox
    default: Downloading: http://files.vagrantup.com/lucid32.box
    default: Progress: 100% (Rate: 17.1M/s, Estimated time remaining: --:--:--)
==> default: Successfully added box 'lucid32' (v0) for 'virtualbox'!
There were warnings and/or errors while loading your Vagrantfile
for the machine 'default'.

Your Vagrantfile was written for an earlier version of Vagrant,
and while Vagrant does the best it can to remain backwards
compatible, there are some cases where things have changed
significantly enough to warrant a message. These messages are
shown below.

Warnings:
* `config.vm.customize` calls are VirtualBox-specific. If you're
using any other provider, you'll have to use config.vm.provider in a
v2 configuration block.

==> default: Importing base box 'lucid32'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: tbpl_default_1397737075333_27065
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
    default: The guest additions on this VM do not match the installed version of
    default: VirtualBox! In most cases this is fine, but in rare cases it can
    default: prevent things such as shared folders from working properly. If you see
    default: shared folder errors, please make sure the guest additions within the
    default: virtual machine match the version of VirtualBox you have installed on
    default: your host and reload your VM.
    default:
    default: Guest Additions Version: 4.2.0
    default: VirtualBox Version: 4.3
==> default: Configuring and enabling network interfaces...
==> default: Mounting shared folders...
    default: /vagrant => C:/src/tbpl
    default: /var/www/tbpl => C:/src/tbpl
    default: /tmp/vagrant-puppet-1/manifests => C:/src/tbpl/puppet/manifests
==> default: Running provisioner: puppet...
Running Puppet with init.pp...
stdin: is not a tty
notice: /Stage[main]/Tbpl-base/Exec[/usr/bin/apt-get update]/returns: executed successfully
...
...
notice: Finished catalog run in 153.52 seconds


We should update to the version 2 Vagrantfile config format, which is used with Vagrant v1.2 and above:
http://docs.vagrantup.com/v2/vagrantfile/version.html
Assignee: nobody → emorley
Status: NEW → ASSIGNED
It appears that the "stdin: is not a tty" is due to https://github.com/mitchellh/vagrant/issues/1673

Given that the workaround can cause issues and the output doesn't affect the success of the vagrant up, let's just leave that for now.
This suppresses depreciation warnings shown in Vagrant v1.2+
Mainly cribbed from the example Vagrantfile produced after
using |vagrant init|.

config.vm.synced_folder now automatically chooses the type of
synced folder, so we don't need to manually specify whether
to enable NFS.

The config.vm.customize change is because Vagrant now supports
providers other than Virtualbox.

config.vm.network and config.vm.boot_mode have slight syntax
changes in the new API.
Attachment #8408220 - Flags: review?(rhelmer)
Comment on attachment 8408220 [details] [diff] [review]
Update Vagrantfile to configuration API version 2

>-  # Try to use NFS only on platforms other than Windows
>-  nfs = !Kernel.is_windows?
>-  config.vm.share_folder("tbpl-code", "/var/www/tbpl", "./", :nfs => nfs)
>+  config.vm.synced_folder "./", "/var/www/tbpl"
> end

So this won't use NFS anymore? Should be fine as long as you're not trying to do a lot of I/O in the shared folder.
Comment on attachment 8408220 [details] [diff] [review]
Update Vagrantfile to configuration API version 2

lgtm! I'd suggest changing 33.33.33.10 to an actual private network like 10.x (they stopped promoting using 33.x a while back for Vagrant since it's actually reserved and public just not used anymore). Also would be nice to upgrade from lucid. Both separate issues though really.
Attachment #8408220 - Flags: review?(rhelmer) → review+
(In reply to Robert Helmer [:rhelmer] from comment #5)
> lgtm! I'd suggest changing 33.33.33.10 to an actual private network like
> 10.x (they stopped promoting using 33.x a while back for Vagrant since it's
> actually reserved and public just not used anymore). Also would be nice to
> upgrade from lucid. Both separate issues though really.

Agree with the IP change. And I also thought it would be good to try and switch to the precise{32.64} images.... until I spent about 3 hours trying to debug the resultant problems and decided not to fix what isn't broken hehe :-) (that and TBPL will be EOL later this year)

(In reply to Robert Helmer [:rhelmer] from comment #4)
> So this won't use NFS anymore? Should be fine as long as you're not trying
> to do a lot of I/O in the shared folder.

It will still use NFS is it's available, the default is now 'auto', so doesn't need to be specified manually.
remote:   https://hg.mozilla.org/webtools/tbpl/rev/45f1196da19c

I'll handle the IP change separately, since I think port forwarding mode might actually make things simpler.
Also landed an update to README.vagrant since the patch here simplifies the instructions for non-Windows when a NFS server is not installed. In addition, TBPL doesn't do a huge amount of non-DB I/O, so NFS shouldn't make much of a difference and so this really should be an optional step.

remote:   https://hg.mozilla.org/webtools/tbpl/rev/9f572aef1fe3
I've tried using things like:
> config.vm.network "forwarded_port", guest: 80, host: 8080

...so we could remove the hardcoded IP & the need for people to adjust their hosts file, but using localhost messes with the Apache VirtualHosts config & I don't have the time to play around with it more at the moment - so I've just kept the fixed IP mode and changed it to 10.33.33.33:

remote:   https://hg.mozilla.org/webtools/tbpl/rev/79597a29ab41
Depends on: 1000304
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Product: Webtools → Tree Management
Product: Tree Management → Tree Management Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: