Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resources design #2

Open
fridex opened this issue Feb 7, 2016 · 1 comment
Open

Resources design #2

fridex opened this issue Feb 7, 2016 · 1 comment

Comments

@fridex
Copy link
Contributor

fridex commented Feb 7, 2016

In the original proposal, there are proposed three main components - Storages, Providers ad Controllers (bac6372).

I would like to hide this logic and put it one step further. The only thing the resources module would provide are ready to serve (and configurable) classes which instances offer API. This will prevent of doing Storages-Providers-Controllers communication every time, moreover it will encapsulate all the logic besides it.

In the source code it will look like (just a quick shot):

obj = SomeClassHandlingTarballs(work_dir = 'tmp/')
obj.set_max_workdir_size(100) # 100MB
path = obj.get_tarball(project, commit)

SomeClassHandlingTarballs would hide how the tarball is received, how work_dir is organized, how it caches tarballs or when/how are tarballs removed etc.

@ingvagabund
Copy link
Contributor

Agree, only controllers would be provided as they offer the complete solution for resource handling. Storages and Resources are building blocks only supporting controller's functionality.
It does not make sense to have a storage running on one node and provider on other. The decomposition is here to provide reusable block, e.g. for caching.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants