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

starting some docs for our next meeting discussions #15

Merged
merged 2 commits into from
Oct 4, 2022
Merged

Conversation

bnlawrence
Copy link
Collaborator

These docs may or may not yet render as proper diagrams

@bnlawrence bnlawrence added the excalibur Needs discussion by the excalibur team label Oct 1, 2022
@bnlawrence bnlawrence marked this pull request as ready for review October 1, 2022 08:02
@valeriupredoi valeriupredoi added the documentation Improvements or additions to documentation label Oct 3, 2022
If however, it is possble to break down the logic of `_from_storage` so that individual "part_chunks" which are contiguous are processed on the storage side of the LAN (in the ost or nearby) then meaningful performance is possible. The Python client in the end would simply see a list of partial products of the computational method which have come direct from the osts. It will not care whether those parts came from a different breakdown of storage than it anticpated in the chunking (though of course the storage will need to do the necessary mapping to generate the partial sums).

In the longer term, where we expect that we will have to pass a decompression method down through the `_decode_chunk` interface, it _will_ be necessary for the computational storage to respect the `_decode_chunk` interface server-side. This is of course what is required with S3, where we effectively need an S3 proxy to do the work. It might be that this is also required in some implementations of POSIX storage systems if they wish to implement computational storage OR they will need to somehow respect block contiguous placement in some way.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bnlawrence I think this is probably better suited in the README?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, but for the moment this is intended for discussion this Friday ...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah okay then it's fine to have it in the pseudo-docs repo, cheers @bnlawrence

@valeriupredoi
Copy link
Collaborator

cheers for this @bnlawrence - I think any operational example should probably go in the README for now, before we actually get sphinx-ed dox, feel free to say no to that - I also requested changes to get you used with a GH review that requests changes (in case you're not used to, am not sure of your GH user level, apols if I grossly underestimated it 😁 )

@bnlawrence
Copy link
Collaborator Author

(Not possible to underestimate my GH foo)

@valeriupredoi valeriupredoi merged commit 3e7804e into main Oct 4, 2022
@valeriupredoi valeriupredoi deleted the docs branch October 4, 2022 11:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation excalibur Needs discussion by the excalibur team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants