This PR includes changes from PR #89. As I expect that to be finished first. So don't review this too closely yet. But if you could take a look at the proposed naming and directory structure of the storage classes.

Eg, I'm thinking:
For a new "foo" serving warehouse type we'd have.

• feast.store.warehouse.FooWarehouseFactory
• feast.store.warehouse.FooWarehouseWrite

And for a new "bar" serving store type, we'd have

• feast.store.serving.BarServingFactory
• feast.store.serving.BarServingWrite
• feast.store.serving.BarServingClient

The factories implement FeatureStoreFactory.
The writes extend FeatureStoreWrite which extends PTransform<PCollection, PDone>.
The factories create the Write transforms.

[An inconsistency I'm bothered by is that in source we just call it FeatureSource, not FeatureSourceRead.]

I think the factories should be able to validate storage specs, and create clients for accessing the serving stores (future work).

Then the goal will be to make this it's own module and (without the beam dependencies)

• serving can import it for creating it's clients.
• core can import it to validate specs and options before it starts a job.

Thanks @tims. Seems like you've done a gargantuan amount of work here. So we should just wait for #89 before reviewing?

Had a cursory look, and it looks great so far @tims! It would be nice to be able to share the storage modules across feast for sure

/cancel hold

rebased (effectively) to master, @zhilingc @pradithya can you re-review?

/hold cancel

/approve
Looks good, thanks!
One minor comment - is there a better package name than logging for the stdout/stderr error logging?

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: zhilingc

The full list of commands accepted by this bot can be found here.

The pull request process is described here

/approve
Looks good, thanks!
One minor comment - is there a better package name than logging for the stdout/stderr error logging?

any suggestions?

/lgtm