-
Notifications
You must be signed in to change notification settings - Fork 2
Unorganized
The Vagrant box should never touch the vagrant-subutai.yml file. It should not write it out. If some values need to be stored or reported then they can be dumped into a different YAML file like status.yaml. This should probably go into the right place in the dot.vagrant hidden directory which vagrant will be cleared out on vagrant destroy. This way we can avoid the situation of users and vagrant changing things and everything gets jumbled up.
Need to consider the lifecycle here very carefully when dealing with mac addresses in the bridges.
The Vagrantfile should automatically install the Subutai Plugin. We can do this by system command if we have to but other mechanisms also exist. This way we can combine plugin capabilities and ruby utility functions together. But best comes from supporting REST and CLI APIs to further automate Subutai features to build intricate configurations. Some automation ideas:
- Register the Peer with the Bazaar
- In Multi-VM configurations register Resource Hosts with a Peer
- Connect Peers in different networks with each other without the Bazaar
All these operations can actually be done using the ruby file loading scheme and their packaging into the box. Perhaps that's the first step. Then we can move on to providing more integrated Subutai Vagrant commands. I would love to for example, start up a container and provision it with Vagrant. Or better yet start up an entire environment and provision it. These scenarios should be possible in a local, distributed, hub-less or with bazaar manner. Pre-requisites for this are REST API's for the Bazaar, the Subutai Console, and for Resource Hosts.