Create an internal API so Machine can be used as a library

[ehazlett]

This will enable machine to be used as a lib and lay the groundwork for machine server.

This will provide a more manageable way to interact with machine instead of working directly with the store and host individually. For example, right now we use store.Create which calls host.Driver.Create etc. This will split up those operations so that the store does not handle provisioning, simply storing machine configuration data.

• Utilize new Driver architecture (proposal: driver refactor #554)
• Move store into package
• Provide abstraction around common operations (see https://github.com/docker/machine/pull/550/files#diff-604f4192deea5adf9c159e5f88f64630)
• Create internal library to use instead of directly using store and host #767

Refs: #550

[nathanleclaire]

We should loop in @ibuildthecloud and others who are interested in the design of the lib since there has been an expressed interest in using it (Go bindings at least).

[ehazlett]

That is what this is.

[ehazlett]

Sorry I was responding to your email which had a different comment.

Yes, this is the placeholder for an internal, non-http API to be used as a lib.

[sthulb]

• Share flags
• Driver structure
• Metadata
• Error handling
• Logging

[ehazlett]

@sthulb added your checklist to the description -- thx!

[nathanleclaire]

Yep, I realized that after my first comment so I updated it to just say we should loop potential consumers of the API / bindings in on it.

[ehazlett]

Updated scope to be more manageable for this first pass. We can iterate after feedback.

[ehazlett]

This is pending #699 as they both affect the backend provisioning.