On Fri, Jul 31, 2015 at 8:26 AM, Tim Landscheidt <[email protected]> 
wrote:
> +1 (well, not with regard to nano :-)).  I especially like
> that "vagrant provision" is much less flappy than
> "labs-vagrant provision"; the only actions on subsequent
> runs are:
>
> | ==> default: Notice: /Stage[main]/Postfix/Exec[postmap_virtual]/returns: 
> executed successfully
> | ==> default: Info: /Stage[main]/Postfix/Exec[postmap_virtual]: Scheduling 
> refresh of Service[postfix]
> | ==> default: Notice: /Stage[main]/Postfix/Service[postfix]: Triggered 
> 'refresh' from 1 events

This is one of the great benefits of using a container. Now ops/puppet
and mediawiki-vagrant aren't fighting over the contents of several
files. It will also make starting over much easier as the LXC
container can be destroyed and recreated without requiring you to drop
the whole Labs VM.

One problem I have noticed is that aborting a `vagrant up` or similar
command can leave LXC in a state where `vagrant destroy` doesn't clean
everything up nicely. When this happens the next `vagrant up` command
is likely to hang and fail to create the container. It would probably
be nice to at least have a wiki page on correcting this and ideally a
custom command in our Vagrant plugin that can automate as much of it
as possible.

Bryan
-- 
Bryan Davis              Wikimedia Foundation    <[email protected]>
[[m:User:BDavis_(WMF)]]  Sr Software Engineer            Boise, ID USA
irc: bd808                                        v:415.839.6885 x6855

_______________________________________________
Labs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/labs-l

Reply via email to