= Proposed Self Contained Change: Vagrant = https://fedoraproject.org/wiki/Changes/Vagrant
Change owner(s): Alex Drahon adrahon@redhat.com
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
Jaroslav Reznik (jreznik@redhat.com) said:
= Proposed Self Contained Change: Vagrant = https://fedoraproject.org/wiki/Changes/Vagrant
Change owner(s): Alex Drahon adrahon@redhat.com
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
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.
On Wed, Jul 17, 2013 at 11:39 AM, Matthew Miller mattdm@fedoraproject.orgwrote:
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
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?
On Wed, Jul 17, 2013 at 3:10 PM, Matthew Miller mattdm@fedoraproject.orgwrote:
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
Dne 17.7.2013 21:19, Julian C. Dunn napsal(a):
On Wed, Jul 17, 2013 at 3:10 PM, Matthew Miller <mattdm@fedoraproject.org mailto:mattdm@fedoraproject.org> 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
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.)
On Thu, Jul 18, 2013 at 5:30 PM, Matthew Miller mattdm@fedoraproject.org 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