Michael,

If you are still interesting in that idea, the VBoxManage CLI script to 
bring VMs with defined IP address is 
here: https://gist.github.com/mikhailov/740fbfc58767fc495fe2

Anatoly

On Sunday, August 24, 2014 at 6:32:24 PM UTC+1, Michael DeHaan wrote:
>
> For development environments a lot of our workflow often uses repeated 
> configuration on the same box, and a lot of things just run out of source. 
>  "make migrate" to run DB migrations and so on.
>
> Though we also do a lot of cloud provisioning, often and usually from 
> scratch, so it's stuff using the ec2 modules then running a playbook on top 
> of them, etc.  I don't see much need for Vagrant when deploying into cloud 
> VMs, since Ansible can do that, though we do have some folks that are fans.
>
> Mostly I don't because I liked VMware fusion at the time and didn't want a 
> proprietary plugin.
>
> But no, everytime we make a code change for something like Ansible Tower 
> we don't re-run the automation, but Jenkins absolutely *does* kick off and 
> do provisioning from scratch on those changes, end to end.
>
>
>
>
>
>
>
> On Sun, Aug 24, 2014 at 12:54 PM, Anatoly Mikhailov <[email protected] 
> <javascript:>> wrote:
>
>> Michael, do you have an advice how other devops guys to manage VMs 
>> without an overhead? 
>> It would be great if you can share with your approach. Thanks!
>>
>>
>> On Saturday, August 16, 2014 4:16:46 PM UTC+1, Michael DeHaan wrote:
>>
>>> I do recognize that people often struggle with the Vagrant provisioner.
>>>
>>> I've occasionally wanted a virtualization abstraction that did not bring 
>>> on the complexity of vagrant, though I think the one general theme of a 
>>> vagrant file is the ability to specify a starter image to download, and 
>>> then some steps to get it prepared before cloning.  I like the idea of 
>>> getting started with a new instance faster, but usually I'm content with 
>>> cloning existing instances (which is why I personally don't use vagrant).
>>>
>>> A more ansible-native wrapper around VMware, KVM, and Virtualbox could 
>>> be amusing, though I can't say I've got time to chase it -- might be nice 
>>> to see what something could evolve to, if in python with such an 
>>> abstraction layer.
>>>
>>>
>>> On Sat, Aug 16, 2014 at 8:44 AM, Anatoly Mikhailov <
>>> [email protected]> wrote:
>>>
>>>> Since I lost hope on Vagrant from high complexity to extend to Ruby 
>>>> syntax for VMs configuration I tried to build some simple version of 
>>>> VBoxManage CLI that based on .vagrant configuration (pretty weird data 
>>>> structure with files): https://gist.github.com/mikhailov/8104790
>>>>
>>>> The misconception of Vagrant is the configuration is a Ruby code to 
>>>> execute which is totaly wrong in terms of Ansible approach. Perhaps, many 
>>>> Ansbile users tend to keep Vagrant just to bootstrap VM, that is it, all 
>>>> the provisioning, orchastration and life-cycle management happens via 
>>>> Ansbile.
>>>>
>>>> Ansible has modules set 
>>>> <http://docs.ansible.com/list_of_cloud_modules.html> for Rackspace, 
>>>> EC2, DigitalOcean, Azure, AWS and VMware. Is there plan to build the same 
>>>> for VirtualBox without Vagrant?
>>>>  
>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "Ansible Project" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to [email protected].
>>>> To post to this group, send email to [email protected].
>>>>
>>>> To view this discussion on the web visit https://groups.google.com/d/
>>>> msgid/ansible-project/5cdf52cc-d038-4276-91f3-
>>>> 7ff37763298c%40googlegroups.com 
>>>> <https://groups.google.com/d/msgid/ansible-project/5cdf52cc-d038-4276-91f3-7ff37763298c%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Ansible Project" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> To post to this group, send email to [email protected] 
>> <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/ansible-project/596f3642-56b6-4ead-905b-4e9e44f098f1%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/ansible-project/596f3642-56b6-4ead-905b-4e9e44f098f1%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/b1f42803-88b8-4003-af95-9ec43a02604b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to