F20 Self Contained Change: Vagrant

[Jaroslav Reznik]

= Proposed Self Contained Change: Vagrant =
https://fedoraproject.org/wiki/Changes/Vagrant

Change owner(s): Alex Drahon <adrahon(a)redhat.com&gt;

Provide Vagrant http://www.vagrantup.com/ with the KVM plugin. 

== Detailed description ==
Vagrant is an automation tool used to manage development environments using 
virtualization and configuration management tools. It allows developers and 
teams to work on their projects and test them in an environment similar to 
production. Historically, Vagrant had a dependency on VirtualBox, but the 
newer versions have a plugin system allowing it to work with other 
virtualization technologies, including KVM. 

== Scope ==
Proposal owners: There's still some work to be done on the vagrant-kvm plugin 
to make it work seamlessly, eg. with SELinux and Firewalld, but it should be 
simple enough. Most of the work is about packaging Vagrant and its 
dependencies as rubygems RPMs and ensuring integration with the Fedora Ruby 
environment.

Other developers: N/A (not a System Wide Change) 
Release engineering: N/A (not a System Wide Change) 
Policies and guidelines: N/A (not a System Wide Change) 
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

[Bill Nottingham]

Jaroslav Reznik (jreznik(a)redhat.com) said: 
>  = Proposed Self Contained Change: Vagrant =
>  https://fedoraproject.org/wiki/Changes/Vagrant
>  
>  Change owner(s): Alex Drahon <adrahon(a)redhat.com&gt;
>  
>  Provide Vagrant http://www.vagrantup.com/ with the KVM plugin. 
>  
>  == Detailed description ==
>  Vagrant is an automation tool used to manage development environments using 
>  virtualization and configuration management tools. It allows developers and 
>  teams to work on their projects and test them in an environment similar to 
>  production. Historically, Vagrant had a dependency on VirtualBox, but the 
>  newer versions have a plugin system allowing it to work with other 
>  virtualization technologies, including KVM. 
>  
>  == Scope ==
>  Proposal owners: There's still some work to be done on the vagrant-kvm plugin 
>  to make it work seamlessly, eg. with SELinux and Firewalld, but it should be 
>  simple enough. Most of the work is about packaging Vagrant and its 
>  dependencies as rubygems RPMs and ensuring integration with the Fedora Ruby 
>  environment.
>  
>  Other developers: N/A (not a System Wide Change) 
>  Release engineering: N/A (not a System Wide Change) 
>  Policies and guidelines: N/A (not a System Wide Change)  
It would likely push this to a system-wide change, but wouldn't it be
logical for this feature to also make a vagrant-able image as well?

Bill

[Matthew Miller]

On Wed, Jul 17, 2013 at 11:20:17AM -0400, Bill Nottingham wrote:
>  It would likely push this to a system-wide change, but wouldn't
> it be
>  logical for this feature to also make a vagrant-able image as well? 
To be an official Vagrant image, we need Chef, and while Sam Kottler is
working with Opscode to make that finally happen (awesome!), I don't think
we want that to be a blocker.

Additionally, the conventions for a Vagrant image are significantly
different from what we want for the cloud image. (Root password set to
"vagrant", for example.) So, the plan is to provide those
"semi-officially"
from fedorpeople.org and the Cloud SIG wiki.

As we get easier technology in Koji for making images, we might revisit for
F20.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Julian C. Dunn]

On Wed, Jul 17, 2013 at 11:39 AM, Matthew Miller
<mattdm(a)fedoraproject.org&gt;wrote:

>  On Wed, Jul 17, 2013 at 11:20:17AM -0400, Bill Nottingham wrote:
>  > It would likely push this to a system-wide change, but wouldn't it be
>  > logical for this feature to also make a vagrant-able image as well?
>
>  To be an official Vagrant image, we need Chef, and while Sam Kottler is
>  working with Opscode to make that finally happen (awesome!), I don't think
>  we want that to be a blocker.
>  
I work for Opscode. Sam and I have talked; we are still blocked on
yajl-ruby vendoring YAJL C and the maintainer is unresponsive about taking
the patch that Josef Stribny worked on.

https://github.com/brianmario/yajl-ruby/pull/113

I talked with our engineering folks about using stdlib JSON but they prefer
YAJL, for a number of reasons I won't go into here. It would also be a huge
change for us with little return.

- Julian

[Matthew Miller]

On Wed, Jul 17, 2013 at 02:34:40PM -0400, Julian C. Dunn wrote:
>  > To be an official Vagrant image, we need Chef, and while Sam
> Kottler is
>  > working with Opscode to make that finally happen (awesome!), I don't think
>  > we want that to be a blocker.
>  I work for Opscode. Sam and I have talked; we are still blocked on
>  yajl-ruby vendoring YAJL C and the maintainer is unresponsive about taking
>  the patch that Josef Stribny worked on. 
Thanks for chiming in. The (stalled) review bug is
https://bugzilla.redhat.com/show_bug.cgi?id=823351, by the way.

>  https://github.com/brianmario/yajl-ruby/pull/113
>  I talked with our engineering folks about using stdlib JSON but they prefer
>  YAJL, for a number of reasons I won't go into here. It would also be a huge
>  change for us with little return. 
Okay. Anything we can do to get the de-vendorization patch moving?


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Julian C. Dunn]

On Wed, Jul 17, 2013 at 3:10 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt;wrote:


>  On Wed, Jul 17, 2013 at 02:34:40PM -0400, Julian C. Dunn wrote:
>  > > To be an official Vagrant image, we need Chef, and while Sam Kottler is
>  > > working with Opscode to make that finally happen (awesome!), I don't
>  think
>  > > we want that to be a blocker.
>  > I work for Opscode. Sam and I have talked; we are still blocked on
>  > yajl-ruby vendoring YAJL C and the maintainer is unresponsive about
>  taking
>  > the patch that Josef Stribny worked on.
>
>  Thanks for chiming in. The (stalled) review bug is
>  https://bugzilla.redhat.com/show_bug.cgi?id=823351, by the way.
>  
Yep... it's one of mine that I took over from Jonas when he became
unresponsive.


>  > https://github.com/brianmario/yajl-ruby/pull/113
>  > I talked with our engineering folks about using stdlib JSON but they
>  prefer
>  > YAJL, for a number of reasons I won't go into here. It would also be a
>  huge
>  > change for us with little return.
>
>  Okay. Anything we can do to get the de-vendorization patch moving?
>  
It looks tough. The patch that Josef and Vit worked on is against the
yajl-ruby 2.0 branch (an unreleased version). I'll let Josef/Vit chime in
here with more details about what's in there.

- Julian

[Vít Ondruch]

Dne 17.7.2013 21:19, Julian C. Dunn napsal(a):
>  On Wed, Jul 17, 2013 at 3:10 PM, Matthew Miller 
>  <mattdm(a)fedoraproject.org <mailto:[e-mail]>> wrote:
>
>      On Wed, Jul 17, 2013 at 02:34:40PM -0400, Julian C. Dunn wrote:
>
>
>      > https://github.com/brianmario/yajl-ruby/pull/113
>      > I talked with our engineering folks about using stdlib JSON but
>      they prefer
>      > YAJL, for a number of reasons I won't go into here. It would
>      also be a huge
>      > change for us with little return.
>
>      Okay. Anything we can do to get the de-vendorization patch moving?
>
>
>  It looks tough. The patch that Josef and Vit worked on is against the 
>  yajl-ruby 2.0 branch (an unreleased version). I'll let Josef/Vit chime 
>  in here with more details about what's in there.
>
>  - Julian 

There is one missing method in upstream YAJL in comparison to bundled 
version. I am afraid we cannot move forward without upstream interaction :/

Vít

[Matthew Miller]

On Thu, Jul 18, 2013 at 09:27:43AM +0200, Vít Ondruch wrote:
>  There is one missing method in upstream YAJL in comparison to
>  bundled version. I am afraid we cannot move forward without upstream
>  interaction :/ 
It looks like upstream was previously responsive but isn't to this one for
some reason?

If we're confident that the feature will get into upstream when the
unreleased version finally comes out, and if this is really the last
blocker, we may be able to get an exception to the bundled libraries policy.
(This is one of the listed cases for a possible exception.)


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Gianluca Sforna]

On Thu, Jul 18, 2013 at 5:30 PM, Matthew Miller
<mattdm(a)fedoraproject.org&gt; wrote:
>  If we're confident that the feature will get into upstream when
> the
>  unreleased version finally comes out, and if this is really the last
>  blocker, we may be able to get an exception to the bundled libraries policy.
>  (This is one of the listed cases for a possible exception.) 
Or add the required patch to the package to provide the missing method?
It will be removed at the next upstream release anyway.

--
Gianluca Sforna

http://morefedora.blogspot.com
http://identi.ca/giallu - http://twitter.com/giallu