Add more store for machine

[Fangfenghua]

From now on,the storage part of machines create by docker-machine is in local file.In simple use-case it sufficient.But in use case need high reliability it's unsufficient. That mybe have problem are:
--If the host we execute the docker-machine CMD is going down, we will can't find out the machine we have create.
--We wiil can't share machines info between different node;
So, we want add more backend store like etcd、cosful、zk. There is a default storage solution for machine but also pluggable backends if the store is operated by the user.

$docker-machine  ls etcd:// etcd://<etcd_ip>/machine

Will add a dir include all store backends:

|--machine
   |--libmachine
      |--store
         |--file
         |--etcd
         |--consul
        ...

Every storage backend must implement interface：

type Store interface {
    // Exists returns whether a machine exists or not
    Exists(name string) (bool, error)
    // GetActive returns the active host
    GetActive() (*Host, error)
    // GetPath returns the path to the store
    GetPath() string
    // GetCACertPath returns the CA certificate
    GetCACertificatePath() (string, error)
    // GetPrivateKeyPath returns the private key
    GetPrivateKeyPath() (string, error)
    // IsActive returns whether the host is active or not
    IsActive(host *Host) (bool, error)
    // List returns a list of hosts
    List() ([]*Host, error)
    // Load loads a host by name
    Get(name string) (*Host, error)
    // Remove removes a machine from the store
    Remove(name string, force bool) error
    // RemoveActive removes the active machine from the store
    RemoveActive() error
    // Save persists a machine in the store
    Save(host *Host) error
    // SetActive sets the specified host as the active host
    SetActive(host *Host) error
}

[ehazlett]

I think the direction we are leaning towards is a declarative syntax (see #773). This would replace the store and would itself be the source of truth. What are your thoughts for something like that?

[Fangfenghua]

@ehazlett I am thoughts about that let machine work like swarm, if we use zk、etcd...we can get the machine state in any nodes which can access zk or etcd.I think this maybe part of #773.

[ehazlett]

@Fangfenghua yeah i see where you are going but having a distributed state is something more along the lines of machine server I think. It makes sense in Swarm because it's orchestrating and is continuously active. In machine, you bring up a machine and then pass it on. I'm not sure in it's current state, that it fits our usage.

[Fangfenghua]

@ehazlett If the node we create the machine is going down,then how can we stop it or kill it?

[ehazlett]

Right now there is no way even if we had a backend with zk. Since Machine has to be run by the user (we have no persistent running server instance to monitor) there is no way to react from an event like that from the machine side yet. I think having a declaration of what the machines should look like and then having machine make that happen is a better way. There is less to keep in sync.

Perhaps some sort of integration between swarm and machine to act on node events would be something -- this sounds like a good plugin to me.

[Fangfenghua]

@ehazlett You mean docker-machine didn't maintaining the state of the machine wo had create? So I don't know why we need the cmd stop or kill? By the way, i didn't mean the node running machine down,I mean the node we execute docker-machine cli cmd node going down,then we can't access the local file record!

[ehazlett]

You mentioned having machine access information from zk or etcd. I'm assuming this is for other things to access it. If those things change the state of the machines, things start to get out of sync. Yes, machine knows what it creates -- unless that data is changed from outside of machine.

The failure upon create is a different issue not related to the store. We have refactored the creation so that as soon as the driver says it's created we persist it. That way we can always get to it. In that case, it wouldn't matter if the store is local or zk -- if it doesn't persist it won't persist anywhere.

Like I said, this sounds like a good integration with Swarm I'm just not sure where it fits in "today's" machine -- it seems better suited for a machine server.

[Fangfenghua]

@ehazlett I got it! If we can find a way monitor the state of the machine we created will sound good.I will follow #773 and close the issue.