You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@allura.apache.org by Dave Brondsema <da...@brondsema.net> on 2014/04/03 00:40:10 UTC
packaging source into vagrant image?
I'm working on building a new vagrant image, since the last image we built was
back in August. Our instructions [1] specify doing a git clone of the repo (and
I actually missed that and got tripped up by lack of source!). But would it
make more sense to include the git repo within the machine image? That'd make
it easier to get up and running (especially if you don't have git installed on
the host). Code getting stale wouldn't be an issue since our Vagrant
instructions specify to run update.sh which includes a git pull.
The downside is that the allura source wouldn't be in a shared vagrant folder
for easy access with your favorite editor, it'd have to be edited with vim
inside the vagrant box. But shared vagrant folders are pretty slow anyway, so
its probably better to recommend development via a different shared method
(vagrant supports NFS or rsync now). See speed comparison at [2].
A different option would be to recommend downloading an official release instead
of git clone.
Yes? No?
[1]
https://forge-allura.apache.org/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/
[2] http://mitchellh.com/comparing-filesystem-performance-in-virtual-machines
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: packaging source into vagrant image?
Posted by Ross Gardler <rg...@opendirective.com>.
I did a session at ApacheCon on using Vagrant to manage a dev VM for open
source projects. I suggest that it is best to start from a plain vanilla
Linux distro and provision the VM from initial setup. This makes it easier
for the community to maintain (just scripts).
I recently published a screencast based on the presentation. This uses
shell scripting for provisioning but it would be better to use Chef or
Puppet (or other) to provide more potential for reuse in final deployment.
Thought I'd share here for feedback since you already do some of this. See
http://msopentech.com/blog/2014/04/23/using-virtual-machine-images-community-development-open-source-project/
If the team here are interested I'd be happy to help to this (actually I
tried to use Allura as the demo but failed to get it working, happy to try
again now I font have an imminent deadline).
On 3 Apr 2014 13:36, "Dave Brondsema" <da...@brondsema.net> wrote:
>
>
https://forge-allura.apache.org/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/
> is now updated with a new vagrant box URL. (No changes to how it works)
>
>
> On 4/3/14 2:43 PM, Dave Brondsema wrote:
> > Yeah, we can put a script inside the image (e.g. like ~/start_allura).
I like
> > that idea.
> >
> > I think for today I'll just keep everything as-is though. Maybe during
PyCon
> > sprints I'll work on a script.
> >
> > On 4/3/14 10:42 AM, Cory Johns wrote:
> >> Ugh. Of course update.sh won't be there if the repo is missing, but I
> >> meant having some sort of script in the VM image that handles checking
out
> >> the repo and running the setup steps (including update.sh).
Alternatively,
> >> could be a wrapper script that handles cloning the repo and
initializing
> >> the VM (similar to ievms).
> >>
> >>
> >> On Thu, Apr 3, 2014 at 10:15 AM, Cory Johns <jo...@gmail.com> wrote:
> >>
> >>> +1 for shared folder, as well, but could we possibly make update.sh
handle
> >>> the git clone from the vagrant side if the code is missing?
> >>>
> >>>
> >>> On Thu, Apr 3, 2014 at 6:41 AM, Wayne Witzel III <wwitzel3@gmail.com
>wrote:
> >>>
> >>>> +1 shared folder. Like Tim said, it is what people who are used to
> >>>> developing with Vagrant expect. FWIW I've also never felt the shared
> >>>> folders in Vagrant were slow.
> >>>>
> >>>>
> >>>> On Thu, Apr 3, 2014 at 1:31 AM, Igor Bondarenko <je...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> +1 for leaving shared folder setup as is
> >>>>>
> >>>>>
> >>>>> On Thu, Apr 3, 2014 at 7:12 AM, Tim Van Steenburgh <
> >>>>> tvansteenburgh@gmail.com
> >>>>>> wrote:
> >>>>>
> >>>>>> FWIW, I would leave the shared folder setup as-is. I use this
vagrant
> >>>>>> setup regularly for other projects and I've never noticed a
> >>>> performance
> >>>>>> penalty - it's always felt as responsive as accessing local files.
I
> >>>>> would
> >>>>>> think people kind of expect this setup when using vagrant (if
they've
> >>>>> used
> >>>>>> it before anyway). And if we change it, we'll only end up replacing
> >>>> the
> >>>>>> `git clone` instructions with nfs mount or rsync instructions.
> >>>>>>
> >>>>>>
> >>>>>> On Wednesday, April 2, 2014 at 6:40 PM, Dave Brondsema wrote:
> >>>>>>
> >>>>>>> I'm working on building a new vagrant image, since the last image
we
> >>>>>> built was
> >>>>>>> back in August. Our instructions [1] specify doing a git clone of
> >>>> the
> >>>>>> repo (and
> >>>>>>> I actually missed that and got tripped up by lack of source!). But
> >>>>> would
> >>>>>> it
> >>>>>>> make more sense to include the git repo within the machine image?
> >>>>> That'd
> >>>>>> make
> >>>>>>> it easier to get up and running (especially if you don't have git
> >>>>>> installed on
> >>>>>>> the host). Code getting stale wouldn't be an issue since our
Vagrant
> >>>>>>> instructions specify to run update.sh (http://update.sh) which
> >>>>> includes
> >>>>>> a git pull.
> >>>>>>>
> >>>>>>> The downside is that the allura source wouldn't be in a shared
> >>>> vagrant
> >>>>>> folder
> >>>>>>> for easy access with your favorite editor, it'd have to be edited
> >>>> with
> >>>>>> vim
> >>>>>>> inside the vagrant box. But shared vagrant folders are pretty slow
> >>>>>> anyway, so
> >>>>>>> its probably better to recommend development via a different
shared
> >>>>>> method
> >>>>>>> (vagrant supports NFS or rsync now). See speed comparison at [2].
> >>>>>>>
> >>>>>>> A different option would be to recommend downloading an official
> >>>>> release
> >>>>>> instead
> >>>>>>> of git clone.
> >>>>>>>
> >>>>>>> Yes? No?
> >>>>>>>
> >>>>>>> [1]
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
https://forge-allura.apache.org/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/
> >>>>>>> [2]
> >>>>>>
> >>>>>
> >>>>
http://mitchellh.com/comparing-filesystem-performance-in-virtual-machines
> >>>>>>>
> >>>>>>> --
> >>>>>>> Dave Brondsema : dave@brondsema.net (mailto:dave@brondsema.net)
> >>>>>>> http://www.brondsema.net : personal
> >>>>>>> http://www.splike.com : programming
> >>>>>>> <><
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >
> >
> >
>
>
>
> --
> Dave Brondsema : dave@brondsema.net
> http://www.brondsema.net : personal
> http://www.splike.com : programming
> <><
On 3 Apr 2014 13:36, "Dave Brondsema" <da...@brondsema.net> wrote:
>
> https://forge-allura.apache.org/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/
> is now updated with a new vagrant box URL. (No changes to how it works)
>
>
> On 4/3/14 2:43 PM, Dave Brondsema wrote:
> > Yeah, we can put a script inside the image (e.g. like ~/start_allura).
> I like
> > that idea.
> >
> > I think for today I'll just keep everything as-is though. Maybe during
> PyCon
> > sprints I'll work on a script.
> >
> > On 4/3/14 10:42 AM, Cory Johns wrote:
> >> Ugh. Of course update.sh won't be there if the repo is missing, but I
> >> meant having some sort of script in the VM image that handles checking
> out
> >> the repo and running the setup steps (including update.sh).
> Alternatively,
> >> could be a wrapper script that handles cloning the repo and initializing
> >> the VM (similar to ievms).
> >>
> >>
> >> On Thu, Apr 3, 2014 at 10:15 AM, Cory Johns <jo...@gmail.com> wrote:
> >>
> >>> +1 for shared folder, as well, but could we possibly make update.sh
> handle
> >>> the git clone from the vagrant side if the code is missing?
> >>>
> >>>
> >>> On Thu, Apr 3, 2014 at 6:41 AM, Wayne Witzel III <wwitzel3@gmail.com
> >wrote:
> >>>
> >>>> +1 shared folder. Like Tim said, it is what people who are used to
> >>>> developing with Vagrant expect. FWIW I've also never felt the shared
> >>>> folders in Vagrant were slow.
> >>>>
> >>>>
> >>>> On Thu, Apr 3, 2014 at 1:31 AM, Igor Bondarenko <je...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> +1 for leaving shared folder setup as is
> >>>>>
> >>>>>
> >>>>> On Thu, Apr 3, 2014 at 7:12 AM, Tim Van Steenburgh <
> >>>>> tvansteenburgh@gmail.com
> >>>>>> wrote:
> >>>>>
> >>>>>> FWIW, I would leave the shared folder setup as-is. I use this
> vagrant
> >>>>>> setup regularly for other projects and I've never noticed a
> >>>> performance
> >>>>>> penalty - it's always felt as responsive as accessing local files. I
> >>>>> would
> >>>>>> think people kind of expect this setup when using vagrant (if
> they've
> >>>>> used
> >>>>>> it before anyway). And if we change it, we'll only end up replacing
> >>>> the
> >>>>>> `git clone` instructions with nfs mount or rsync instructions.
> >>>>>>
> >>>>>>
> >>>>>> On Wednesday, April 2, 2014 at 6:40 PM, Dave Brondsema wrote:
> >>>>>>
> >>>>>>> I'm working on building a new vagrant image, since the last image
> we
> >>>>>> built was
> >>>>>>> back in August. Our instructions [1] specify doing a git clone of
> >>>> the
> >>>>>> repo (and
> >>>>>>> I actually missed that and got tripped up by lack of source!). But
> >>>>> would
> >>>>>> it
> >>>>>>> make more sense to include the git repo within the machine image?
> >>>>> That'd
> >>>>>> make
> >>>>>>> it easier to get up and running (especially if you don't have git
> >>>>>> installed on
> >>>>>>> the host). Code getting stale wouldn't be an issue since our
> Vagrant
> >>>>>>> instructions specify to run update.sh (http://update.sh) which
> >>>>> includes
> >>>>>> a git pull.
> >>>>>>>
> >>>>>>> The downside is that the allura source wouldn't be in a shared
> >>>> vagrant
> >>>>>> folder
> >>>>>>> for easy access with your favorite editor, it'd have to be edited
> >>>> with
> >>>>>> vim
> >>>>>>> inside the vagrant box. But shared vagrant folders are pretty slow
> >>>>>> anyway, so
> >>>>>>> its probably better to recommend development via a different shared
> >>>>>> method
> >>>>>>> (vagrant supports NFS or rsync now). See speed comparison at [2].
> >>>>>>>
> >>>>>>> A different option would be to recommend downloading an official
> >>>>> release
> >>>>>> instead
> >>>>>>> of git clone.
> >>>>>>>
> >>>>>>> Yes? No?
> >>>>>>>
> >>>>>>> [1]
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> https://forge-allura.apache.org/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/
> >>>>>>> [2]
> >>>>>>
> >>>>>
> >>>>
> http://mitchellh.com/comparing-filesystem-performance-in-virtual-machines
> >>>>>>>
> >>>>>>> --
> >>>>>>> Dave Brondsema : dave@brondsema.net (mailto:dave@brondsema.net)
> >>>>>>> http://www.brondsema.net : personal
> >>>>>>> http://www.splike.com : programming
> >>>>>>> <><
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >
> >
> >
>
>
>
> --
> Dave Brondsema : dave@brondsema.net
> http://www.brondsema.net : personal
> http://www.splike.com : programming
> <><
>
Re: packaging source into vagrant image?
Posted by Dave Brondsema <da...@brondsema.net>.
https://forge-allura.apache.org/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/
is now updated with a new vagrant box URL. (No changes to how it works)
On 4/3/14 2:43 PM, Dave Brondsema wrote:
> Yeah, we can put a script inside the image (e.g. like ~/start_allura). I like
> that idea.
>
> I think for today I'll just keep everything as-is though. Maybe during PyCon
> sprints I'll work on a script.
>
> On 4/3/14 10:42 AM, Cory Johns wrote:
>> Ugh. Of course update.sh won't be there if the repo is missing, but I
>> meant having some sort of script in the VM image that handles checking out
>> the repo and running the setup steps (including update.sh). Alternatively,
>> could be a wrapper script that handles cloning the repo and initializing
>> the VM (similar to ievms).
>>
>>
>> On Thu, Apr 3, 2014 at 10:15 AM, Cory Johns <jo...@gmail.com> wrote:
>>
>>> +1 for shared folder, as well, but could we possibly make update.sh handle
>>> the git clone from the vagrant side if the code is missing?
>>>
>>>
>>> On Thu, Apr 3, 2014 at 6:41 AM, Wayne Witzel III <ww...@gmail.com>wrote:
>>>
>>>> +1 shared folder. Like Tim said, it is what people who are used to
>>>> developing with Vagrant expect. FWIW I've also never felt the shared
>>>> folders in Vagrant were slow.
>>>>
>>>>
>>>> On Thu, Apr 3, 2014 at 1:31 AM, Igor Bondarenko <je...@gmail.com>
>>>> wrote:
>>>>
>>>>> +1 for leaving shared folder setup as is
>>>>>
>>>>>
>>>>> On Thu, Apr 3, 2014 at 7:12 AM, Tim Van Steenburgh <
>>>>> tvansteenburgh@gmail.com
>>>>>> wrote:
>>>>>
>>>>>> FWIW, I would leave the shared folder setup as-is. I use this vagrant
>>>>>> setup regularly for other projects and I've never noticed a
>>>> performance
>>>>>> penalty - it's always felt as responsive as accessing local files. I
>>>>> would
>>>>>> think people kind of expect this setup when using vagrant (if they've
>>>>> used
>>>>>> it before anyway). And if we change it, we'll only end up replacing
>>>> the
>>>>>> `git clone` instructions with nfs mount or rsync instructions.
>>>>>>
>>>>>>
>>>>>> On Wednesday, April 2, 2014 at 6:40 PM, Dave Brondsema wrote:
>>>>>>
>>>>>>> I'm working on building a new vagrant image, since the last image we
>>>>>> built was
>>>>>>> back in August. Our instructions [1] specify doing a git clone of
>>>> the
>>>>>> repo (and
>>>>>>> I actually missed that and got tripped up by lack of source!). But
>>>>> would
>>>>>> it
>>>>>>> make more sense to include the git repo within the machine image?
>>>>> That'd
>>>>>> make
>>>>>>> it easier to get up and running (especially if you don't have git
>>>>>> installed on
>>>>>>> the host). Code getting stale wouldn't be an issue since our Vagrant
>>>>>>> instructions specify to run update.sh (http://update.sh) which
>>>>> includes
>>>>>> a git pull.
>>>>>>>
>>>>>>> The downside is that the allura source wouldn't be in a shared
>>>> vagrant
>>>>>> folder
>>>>>>> for easy access with your favorite editor, it'd have to be edited
>>>> with
>>>>>> vim
>>>>>>> inside the vagrant box. But shared vagrant folders are pretty slow
>>>>>> anyway, so
>>>>>>> its probably better to recommend development via a different shared
>>>>>> method
>>>>>>> (vagrant supports NFS or rsync now). See speed comparison at [2].
>>>>>>>
>>>>>>> A different option would be to recommend downloading an official
>>>>> release
>>>>>> instead
>>>>>>> of git clone.
>>>>>>>
>>>>>>> Yes? No?
>>>>>>>
>>>>>>> [1]
>>>>>>>
>>>>>>
>>>>>
>>>> https://forge-allura.apache.org/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/
>>>>>>> [2]
>>>>>>
>>>>>
>>>> http://mitchellh.com/comparing-filesystem-performance-in-virtual-machines
>>>>>>>
>>>>>>> --
>>>>>>> Dave Brondsema : dave@brondsema.net (mailto:dave@brondsema.net)
>>>>>>> http://www.brondsema.net : personal
>>>>>>> http://www.splike.com : programming
>>>>>>> <><
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: packaging source into vagrant image?
Posted by Dave Brondsema <da...@brondsema.net>.
Yeah, we can put a script inside the image (e.g. like ~/start_allura). I like
that idea.
I think for today I'll just keep everything as-is though. Maybe during PyCon
sprints I'll work on a script.
On 4/3/14 10:42 AM, Cory Johns wrote:
> Ugh. Of course update.sh won't be there if the repo is missing, but I
> meant having some sort of script in the VM image that handles checking out
> the repo and running the setup steps (including update.sh). Alternatively,
> could be a wrapper script that handles cloning the repo and initializing
> the VM (similar to ievms).
>
>
> On Thu, Apr 3, 2014 at 10:15 AM, Cory Johns <jo...@gmail.com> wrote:
>
>> +1 for shared folder, as well, but could we possibly make update.sh handle
>> the git clone from the vagrant side if the code is missing?
>>
>>
>> On Thu, Apr 3, 2014 at 6:41 AM, Wayne Witzel III <ww...@gmail.com>wrote:
>>
>>> +1 shared folder. Like Tim said, it is what people who are used to
>>> developing with Vagrant expect. FWIW I've also never felt the shared
>>> folders in Vagrant were slow.
>>>
>>>
>>> On Thu, Apr 3, 2014 at 1:31 AM, Igor Bondarenko <je...@gmail.com>
>>> wrote:
>>>
>>>> +1 for leaving shared folder setup as is
>>>>
>>>>
>>>> On Thu, Apr 3, 2014 at 7:12 AM, Tim Van Steenburgh <
>>>> tvansteenburgh@gmail.com
>>>>> wrote:
>>>>
>>>>> FWIW, I would leave the shared folder setup as-is. I use this vagrant
>>>>> setup regularly for other projects and I've never noticed a
>>> performance
>>>>> penalty - it's always felt as responsive as accessing local files. I
>>>> would
>>>>> think people kind of expect this setup when using vagrant (if they've
>>>> used
>>>>> it before anyway). And if we change it, we'll only end up replacing
>>> the
>>>>> `git clone` instructions with nfs mount or rsync instructions.
>>>>>
>>>>>
>>>>> On Wednesday, April 2, 2014 at 6:40 PM, Dave Brondsema wrote:
>>>>>
>>>>>> I'm working on building a new vagrant image, since the last image we
>>>>> built was
>>>>>> back in August. Our instructions [1] specify doing a git clone of
>>> the
>>>>> repo (and
>>>>>> I actually missed that and got tripped up by lack of source!). But
>>>> would
>>>>> it
>>>>>> make more sense to include the git repo within the machine image?
>>>> That'd
>>>>> make
>>>>>> it easier to get up and running (especially if you don't have git
>>>>> installed on
>>>>>> the host). Code getting stale wouldn't be an issue since our Vagrant
>>>>>> instructions specify to run update.sh (http://update.sh) which
>>>> includes
>>>>> a git pull.
>>>>>>
>>>>>> The downside is that the allura source wouldn't be in a shared
>>> vagrant
>>>>> folder
>>>>>> for easy access with your favorite editor, it'd have to be edited
>>> with
>>>>> vim
>>>>>> inside the vagrant box. But shared vagrant folders are pretty slow
>>>>> anyway, so
>>>>>> its probably better to recommend development via a different shared
>>>>> method
>>>>>> (vagrant supports NFS or rsync now). See speed comparison at [2].
>>>>>>
>>>>>> A different option would be to recommend downloading an official
>>>> release
>>>>> instead
>>>>>> of git clone.
>>>>>>
>>>>>> Yes? No?
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>
>>>>
>>> https://forge-allura.apache.org/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/
>>>>>> [2]
>>>>>
>>>>
>>> http://mitchellh.com/comparing-filesystem-performance-in-virtual-machines
>>>>>>
>>>>>> --
>>>>>> Dave Brondsema : dave@brondsema.net (mailto:dave@brondsema.net)
>>>>>> http://www.brondsema.net : personal
>>>>>> http://www.splike.com : programming
>>>>>> <><
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: packaging source into vagrant image?
Posted by Cory Johns <jo...@gmail.com>.
Ugh. Of course update.sh won't be there if the repo is missing, but I
meant having some sort of script in the VM image that handles checking out
the repo and running the setup steps (including update.sh). Alternatively,
could be a wrapper script that handles cloning the repo and initializing
the VM (similar to ievms).
On Thu, Apr 3, 2014 at 10:15 AM, Cory Johns <jo...@gmail.com> wrote:
> +1 for shared folder, as well, but could we possibly make update.sh handle
> the git clone from the vagrant side if the code is missing?
>
>
> On Thu, Apr 3, 2014 at 6:41 AM, Wayne Witzel III <ww...@gmail.com>wrote:
>
>> +1 shared folder. Like Tim said, it is what people who are used to
>> developing with Vagrant expect. FWIW I've also never felt the shared
>> folders in Vagrant were slow.
>>
>>
>> On Thu, Apr 3, 2014 at 1:31 AM, Igor Bondarenko <je...@gmail.com>
>> wrote:
>>
>> > +1 for leaving shared folder setup as is
>> >
>> >
>> > On Thu, Apr 3, 2014 at 7:12 AM, Tim Van Steenburgh <
>> > tvansteenburgh@gmail.com
>> > > wrote:
>> >
>> > > FWIW, I would leave the shared folder setup as-is. I use this vagrant
>> > > setup regularly for other projects and I've never noticed a
>> performance
>> > > penalty - it's always felt as responsive as accessing local files. I
>> > would
>> > > think people kind of expect this setup when using vagrant (if they've
>> > used
>> > > it before anyway). And if we change it, we'll only end up replacing
>> the
>> > > `git clone` instructions with nfs mount or rsync instructions.
>> > >
>> > >
>> > > On Wednesday, April 2, 2014 at 6:40 PM, Dave Brondsema wrote:
>> > >
>> > > > I'm working on building a new vagrant image, since the last image we
>> > > built was
>> > > > back in August. Our instructions [1] specify doing a git clone of
>> the
>> > > repo (and
>> > > > I actually missed that and got tripped up by lack of source!). But
>> > would
>> > > it
>> > > > make more sense to include the git repo within the machine image?
>> > That'd
>> > > make
>> > > > it easier to get up and running (especially if you don't have git
>> > > installed on
>> > > > the host). Code getting stale wouldn't be an issue since our Vagrant
>> > > > instructions specify to run update.sh (http://update.sh) which
>> > includes
>> > > a git pull.
>> > > >
>> > > > The downside is that the allura source wouldn't be in a shared
>> vagrant
>> > > folder
>> > > > for easy access with your favorite editor, it'd have to be edited
>> with
>> > > vim
>> > > > inside the vagrant box. But shared vagrant folders are pretty slow
>> > > anyway, so
>> > > > its probably better to recommend development via a different shared
>> > > method
>> > > > (vagrant supports NFS or rsync now). See speed comparison at [2].
>> > > >
>> > > > A different option would be to recommend downloading an official
>> > release
>> > > instead
>> > > > of git clone.
>> > > >
>> > > > Yes? No?
>> > > >
>> > > > [1]
>> > > >
>> > >
>> >
>> https://forge-allura.apache.org/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/
>> > > > [2]
>> > >
>> >
>> http://mitchellh.com/comparing-filesystem-performance-in-virtual-machines
>> > > >
>> > > > --
>> > > > Dave Brondsema : dave@brondsema.net (mailto:dave@brondsema.net)
>> > > > http://www.brondsema.net : personal
>> > > > http://www.splike.com : programming
>> > > > <><
>> > > >
>> > > >
>> > >
>> > >
>> > >
>> >
>>
>
>
Re: packaging source into vagrant image?
Posted by Cory Johns <jo...@gmail.com>.
+1 for shared folder, as well, but could we possibly make update.sh handle
the git clone from the vagrant side if the code is missing?
On Thu, Apr 3, 2014 at 6:41 AM, Wayne Witzel III <ww...@gmail.com> wrote:
> +1 shared folder. Like Tim said, it is what people who are used to
> developing with Vagrant expect. FWIW I've also never felt the shared
> folders in Vagrant were slow.
>
>
> On Thu, Apr 3, 2014 at 1:31 AM, Igor Bondarenko <je...@gmail.com>
> wrote:
>
> > +1 for leaving shared folder setup as is
> >
> >
> > On Thu, Apr 3, 2014 at 7:12 AM, Tim Van Steenburgh <
> > tvansteenburgh@gmail.com
> > > wrote:
> >
> > > FWIW, I would leave the shared folder setup as-is. I use this vagrant
> > > setup regularly for other projects and I've never noticed a performance
> > > penalty - it's always felt as responsive as accessing local files. I
> > would
> > > think people kind of expect this setup when using vagrant (if they've
> > used
> > > it before anyway). And if we change it, we'll only end up replacing the
> > > `git clone` instructions with nfs mount or rsync instructions.
> > >
> > >
> > > On Wednesday, April 2, 2014 at 6:40 PM, Dave Brondsema wrote:
> > >
> > > > I'm working on building a new vagrant image, since the last image we
> > > built was
> > > > back in August. Our instructions [1] specify doing a git clone of the
> > > repo (and
> > > > I actually missed that and got tripped up by lack of source!). But
> > would
> > > it
> > > > make more sense to include the git repo within the machine image?
> > That'd
> > > make
> > > > it easier to get up and running (especially if you don't have git
> > > installed on
> > > > the host). Code getting stale wouldn't be an issue since our Vagrant
> > > > instructions specify to run update.sh (http://update.sh) which
> > includes
> > > a git pull.
> > > >
> > > > The downside is that the allura source wouldn't be in a shared
> vagrant
> > > folder
> > > > for easy access with your favorite editor, it'd have to be edited
> with
> > > vim
> > > > inside the vagrant box. But shared vagrant folders are pretty slow
> > > anyway, so
> > > > its probably better to recommend development via a different shared
> > > method
> > > > (vagrant supports NFS or rsync now). See speed comparison at [2].
> > > >
> > > > A different option would be to recommend downloading an official
> > release
> > > instead
> > > > of git clone.
> > > >
> > > > Yes? No?
> > > >
> > > > [1]
> > > >
> > >
> >
> https://forge-allura.apache.org/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/
> > > > [2]
> > >
> >
> http://mitchellh.com/comparing-filesystem-performance-in-virtual-machines
> > > >
> > > > --
> > > > Dave Brondsema : dave@brondsema.net (mailto:dave@brondsema.net)
> > > > http://www.brondsema.net : personal
> > > > http://www.splike.com : programming
> > > > <><
> > > >
> > > >
> > >
> > >
> > >
> >
>
Re: packaging source into vagrant image?
Posted by Wayne Witzel III <ww...@gmail.com>.
+1 shared folder. Like Tim said, it is what people who are used to
developing with Vagrant expect. FWIW I've also never felt the shared
folders in Vagrant were slow.
On Thu, Apr 3, 2014 at 1:31 AM, Igor Bondarenko <je...@gmail.com> wrote:
> +1 for leaving shared folder setup as is
>
>
> On Thu, Apr 3, 2014 at 7:12 AM, Tim Van Steenburgh <
> tvansteenburgh@gmail.com
> > wrote:
>
> > FWIW, I would leave the shared folder setup as-is. I use this vagrant
> > setup regularly for other projects and I’ve never noticed a performance
> > penalty - it’s always felt as responsive as accessing local files. I
> would
> > think people kind of expect this setup when using vagrant (if they’ve
> used
> > it before anyway). And if we change it, we’ll only end up replacing the
> > `git clone` instructions with nfs mount or rsync instructions.
> >
> >
> > On Wednesday, April 2, 2014 at 6:40 PM, Dave Brondsema wrote:
> >
> > > I'm working on building a new vagrant image, since the last image we
> > built was
> > > back in August. Our instructions [1] specify doing a git clone of the
> > repo (and
> > > I actually missed that and got tripped up by lack of source!). But
> would
> > it
> > > make more sense to include the git repo within the machine image?
> That'd
> > make
> > > it easier to get up and running (especially if you don't have git
> > installed on
> > > the host). Code getting stale wouldn't be an issue since our Vagrant
> > > instructions specify to run update.sh (http://update.sh) which
> includes
> > a git pull.
> > >
> > > The downside is that the allura source wouldn't be in a shared vagrant
> > folder
> > > for easy access with your favorite editor, it'd have to be edited with
> > vim
> > > inside the vagrant box. But shared vagrant folders are pretty slow
> > anyway, so
> > > its probably better to recommend development via a different shared
> > method
> > > (vagrant supports NFS or rsync now). See speed comparison at [2].
> > >
> > > A different option would be to recommend downloading an official
> release
> > instead
> > > of git clone.
> > >
> > > Yes? No?
> > >
> > > [1]
> > >
> >
> https://forge-allura.apache.org/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/
> > > [2]
> >
> http://mitchellh.com/comparing-filesystem-performance-in-virtual-machines
> > >
> > > --
> > > Dave Brondsema : dave@brondsema.net (mailto:dave@brondsema.net)
> > > http://www.brondsema.net : personal
> > > http://www.splike.com : programming
> > > <><
> > >
> > >
> >
> >
> >
>
Re: packaging source into vagrant image?
Posted by Igor Bondarenko <je...@gmail.com>.
+1 for leaving shared folder setup as is
On Thu, Apr 3, 2014 at 7:12 AM, Tim Van Steenburgh <tvansteenburgh@gmail.com
> wrote:
> FWIW, I would leave the shared folder setup as-is. I use this vagrant
> setup regularly for other projects and I’ve never noticed a performance
> penalty - it’s always felt as responsive as accessing local files. I would
> think people kind of expect this setup when using vagrant (if they’ve used
> it before anyway). And if we change it, we’ll only end up replacing the
> `git clone` instructions with nfs mount or rsync instructions.
>
>
> On Wednesday, April 2, 2014 at 6:40 PM, Dave Brondsema wrote:
>
> > I'm working on building a new vagrant image, since the last image we
> built was
> > back in August. Our instructions [1] specify doing a git clone of the
> repo (and
> > I actually missed that and got tripped up by lack of source!). But would
> it
> > make more sense to include the git repo within the machine image? That'd
> make
> > it easier to get up and running (especially if you don't have git
> installed on
> > the host). Code getting stale wouldn't be an issue since our Vagrant
> > instructions specify to run update.sh (http://update.sh) which includes
> a git pull.
> >
> > The downside is that the allura source wouldn't be in a shared vagrant
> folder
> > for easy access with your favorite editor, it'd have to be edited with
> vim
> > inside the vagrant box. But shared vagrant folders are pretty slow
> anyway, so
> > its probably better to recommend development via a different shared
> method
> > (vagrant supports NFS or rsync now). See speed comparison at [2].
> >
> > A different option would be to recommend downloading an official release
> instead
> > of git clone.
> >
> > Yes? No?
> >
> > [1]
> >
> https://forge-allura.apache.org/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/
> > [2]
> http://mitchellh.com/comparing-filesystem-performance-in-virtual-machines
> >
> > --
> > Dave Brondsema : dave@brondsema.net (mailto:dave@brondsema.net)
> > http://www.brondsema.net : personal
> > http://www.splike.com : programming
> > <><
> >
> >
>
>
>
Re: packaging source into vagrant image?
Posted by Tim Van Steenburgh <tv...@gmail.com>.
FWIW, I would leave the shared folder setup as-is. I use this vagrant setup regularly for other projects and I’ve never noticed a performance penalty - it’s always felt as responsive as accessing local files. I would think people kind of expect this setup when using vagrant (if they’ve used it before anyway). And if we change it, we’ll only end up replacing the `git clone` instructions with nfs mount or rsync instructions.
On Wednesday, April 2, 2014 at 6:40 PM, Dave Brondsema wrote:
> I'm working on building a new vagrant image, since the last image we built was
> back in August. Our instructions [1] specify doing a git clone of the repo (and
> I actually missed that and got tripped up by lack of source!). But would it
> make more sense to include the git repo within the machine image? That'd make
> it easier to get up and running (especially if you don't have git installed on
> the host). Code getting stale wouldn't be an issue since our Vagrant
> instructions specify to run update.sh (http://update.sh) which includes a git pull.
>
> The downside is that the allura source wouldn't be in a shared vagrant folder
> for easy access with your favorite editor, it'd have to be edited with vim
> inside the vagrant box. But shared vagrant folders are pretty slow anyway, so
> its probably better to recommend development via a different shared method
> (vagrant supports NFS or rsync now). See speed comparison at [2].
>
> A different option would be to recommend downloading an official release instead
> of git clone.
>
> Yes? No?
>
> [1]
> https://forge-allura.apache.org/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/
> [2] http://mitchellh.com/comparing-filesystem-performance-in-virtual-machines
>
> --
> Dave Brondsema : dave@brondsema.net (mailto:dave@brondsema.net)
> http://www.brondsema.net : personal
> http://www.splike.com : programming
> <><
>
>