WIP: Refactor code out of main package

[cjellick]

This PR does the following:

• Moves the store.go and host.go code out of the main package and into a package called store
• Introduces an api package to provide a single entry point for all operations on hosts

Motivation and benefits

First, hopefully this will better organize business logic and separate concerns in the machine code base. It should give future developers better guidance on where business logic should go and force them to think through how it can be cleanly exposed. This should make machine more maintainable in the long run.

It should allow commands.go to be concerned only with interpreting CLI requests and passing them to the API. With the code in it's current state, it isn't clear where new functionality should drop. Here's a few examples where it seems the current model is falling short:

• We've seen some PRs where important store-specific logic is dropped directly into ``commands.go` add export and import #29 is a possible example of this.
• The way one performs state changing operations is inconsistent. For example, to start a host you call host.Start(), to restart it you call host.DriverRestart(), and to remove it you call store.Remove(), but there is also a host.Remove() function exposed.

Second, this provides access to machine as a library so that integrators don't have to exec out to it. This is a good stop-gap measure while we work towards building a REST API for machine.

As @shykes and @ehazlett mentioned in an IRC conversation, a risk is that introducing a public api at this point means being forced to maintain it. It should be understood that the api provides no stability or backwards compatibility guarantees with regards to public consumption. It is first and foremost an internal API for better separating concerns within the machine code base. Users calling machine as a library would do so at their own risk. Would calling this out explicitly as a comment in the api package be sufficient for conveying this?

Current deficencies or concerns

There a few deficencies with the PR as-is:

The SSH command code has note been refactored. This was just done for time savings. I wanted to get some feedback on the concept before spending the time to refactor it.

The abstraction is a little leaky. All state changing functions on the host struct have been unexposed, but the Driver field is still exposed and it exposes state changing operations. The reason for this is that the machine inspect command marshals the Driver field to json. I couldn't simply hide the Driver field because it would cause inspect to be much less useful. Suggests on how to address this are welcome.

There is some logic in store.go and host.go that perhaps now should be moved directly into the api package. This was done intentionally to minimize the impact of the PR. Future PRs could be address further refactoring made possible by this PR.

Some more testing may be needed

[sthulb]

I agree that a some of the main package needs to be moved. The "api" package seems a bit generic for a name :)

[cjellick]

@sthulb I agree with the name. I struggled with the name and decided to use api as a strawman. If you have anything else in mind, I'd welcome the suggestion. Meanwhile, I'll think on it some more.

[sthulb]

@cjellick I think naming things are hard at this stage in a project.

[sthulb]

The api package should be reserved for when we offer a HTTP API perhaps

[ehazlett]

@cjellick sorry for the delayed response. this is awesome. +1 to @sthulb api comment as we will have that in the near future (hopefully). This is great for the internals. As you mention above, even creating something that someone can use means there has to be stability. I will spend some cycles thinking on the naming and see if we can come together on something.

@cjellick Could you also rebase?

Thanks!

[sthulb]

I guess the obvious one is to rename api to host or machine

[ehazlett]

+1 for machine

[cjellick]

This one got away from me. Sorry for leaving it open for so long.

[ehazlett]

@cjellick hey no problem. would love to have your feedback on the related issues (#500, #550) :)

[ehazlett]

looks like you did -- thanks!