It's still done in vagrant under controlled conditions by default - it's just done through test kitchen, so that we can have more control over providers, local overrides, et al.I understand how you feel - we should work together to get you back to a place where things are cool.AdamOn Sun, Apr 13, 2014 at 1:34 PM, John E. Vincent (lusis) < " target="_blank"> > wrote:
On Apr 13, 2014 4:25 PM, "Adam Jacob" < " target="_blank"> > wrote:
>
> Yes. Not to be a pain in the ass, but essentially, you're argument is that you got to piggyback on Vagrants choice of installation ecosystem to ensure your build lab/develops didn't have to have the actual software required to run the software you use to build your applications. And now you can't. You see how that was always a deeply leaky abstraction, right?
>Actually no I thought that was always the intention. The vagrant file was generated by omnibus to do just that thing. The actual building of the packages was done inside vagrant under the controlled conditions.
In fact I'm pretty sure the original generated readme for new projects pointed this ability out exactly under "vagrant build lab".
> I'm not the primary authority on omnibus futures, but I would say that yes - we probably won't go back to a world where you could rely on that assumption always being true.
>Again I don't think these assumptions were unsafe based on what I said above.
> You need ruby to run omnibus. You always did. You just got away with pretending you didn't need it. I can see how that smarts, because I can see how quickly you would have relied on that being true.
>
> An omnibus build of omnibus would solve for this, most likely, which I think is the avenue you are already on.
>
> Also, what stops you from just injecting omnibus 3 into vagrant in the same way - except for the fact that the people who maintained vagrant-berkshelf are no longer interested in doing it (because they've moved on to the mechanism the new generators use.) All the effort is on execution after the fact - you don't need to "load" anything other than the omnibus code into the VM like you always did.This is what I'm working on likely involving no vagrant plugins whatsoever.
>
> Adam
>
>
> On Sun, Apr 13, 2014 at 1:17 PM, John E. Vincent (lusis) <lusis.org+ " target="_blank"> > wrote:
>>
>> I'll try and clarify. As long as you had vagrant and the two plugins you could clone any omnibus project and call vagrant up. You didn't need a local ruby or anything outside of vagrant or it's own plugin system. Everything was done inside the vm.
>>
>> To generate projects, yes, you needed a ruby install to run the omnibus cli.
>>
>> Specifics, I have a bunch of repos on GitHub that are omnibus projects (already generated). Any user can clone one of those repos and (assuming they already had vagrant-omnibus and vagrant-berkshelf plugins installed) they only needed to run vagrant up and have the packages built for them.
>>
>> I realize that under the covers vagrant has it's own ruby where those plugins are but that didn't require any full blown local ruby environment just to build them.
>>
>> That same pattern is the one we use internally. We rarely generate new projects but we have existing ones that we tweak and rebuild on systems that don't have a single ruby binary installed outside of vagrant's plugin system.
>>
>> That's what we lost.
>>
>> Make sense?
>>
>>
>> On Sunday, April 13, 2014, Adam Jacob < " target="_blank"> > wrote:
>>>
>>> I'm not sure I understand. What changed for you is that you now have to run "bundle install" instead of just install vagrant, and that's whats up?
>>>
>>> You always needed ruby, you always needed vagrant, and you always needed Berks. So what's the deal? Can you show some more specifics?
>>>
>>> Adam
>>>
>>>
>>> On Sun, Apr 13, 2014 at 11:11 AM, John E. Vincent (lusis) <lusis.org+ " target="_blank"> > wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I (probably inappropriately) got into a discussion about this one twitter earlier today. I wanted to try and get some understanding of the direction here because it does directly impact the viability of omnibus for us.
>>>>
>>>> Previously in the original omnibus, ruby + omnibus was only required to create the project. A common workflow on our side was this:
>>>>
>>>> - Clone project repo
>>>> - install vagrant-omnibus and vagrant-berkshelf plugins
>>>> - vagrant up
>>>> - collect and publish packages
>>>>
>>>> Yes, I know that vagrant 1.5 broke that model because vagrant-berkshelf didn't work with it but we actually weren't upgrading BECAUSE of this. Understand, we're not a ruby shop. We use ruby very sparingly in our workflow. The only reason most of us have a ruby install is to use knife.
>>>>
>>>> Now it seems that with Omnibus 3, the understanding is that a ruby environment will not only be required to create a project but to actually run the process to build the project. This apparently is due to moving to test-kitchen instead of vagrant straight.
>>>>
>>>> This REALLY complicates having people involved internally in our omnibus builds to the point of probably having to drop using it.
>>>>
>>>> I'm also curious as well because omnibus 3 brought in an unreleased dependency on Berkshelf 3.xbeta which also complicates things as there appears to be a move to have berkshelf be a requirement of everything.
>>>>
>>>> So now I'm stuck in a weird spot. I need to have a ruby toolchain to run knife but now I need a different ruby toolchain to run omnibus (where I *DIDN'T* need one before) because every thing seems to be pulling in conflicting versions of Berkshelf. We're right back in the json mess again.
>>>>
>>>> So I'd love to have someone help me understand if this is a definitive way forward for omnibus and if possible what the reasoning is behind making Berkshelf so core to everything.
>>>>
>>>> Thanks!
>>>> John
>>>
>>>
>>>
>>>
>>> --
>>> Opscode, Inc.
>>> Adam Jacob, Chief Dev Officer
>>> T: (206) 619-7151 E: " target="_blank">
>
>
>
>
> --
> Opscode, Inc.
> Adam Jacob, Chief Dev Officer
> T: (206) 619-7151 E: " target="_blank">
Archive powered by MHonArc 2.6.16.