You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Roman Coedo <ro...@gmail.com> on 2014/03/17 14:09:14 UTC
[GSoC] Amazon Glacier Support: Proposal Draft
Hi,
I've made a draft for my proposal to implement jclouds' support for Amazon
Glacier and I'd like to share it with you. Any suggestions would be really
appreciated.
You can check it on this link:
https://drive.google.com/file/d/0B3lMiDkiDwpUanRrZUphSkNEX2s/edit?usp=sharing
Thanks for your time.
Re: [GSoC] Amazon Glacier Support: Proposal Draft
Posted by Roman Coedo <ro...@gmail.com>.
Ok, it's done. I made the necessary changes and sent the proposal through
the GSoC website to the ASF. Thanks to all of you for your help!
Regards.
2014-03-18 23:32 GMT+01:00 Andrew Gaul <ga...@apache.org>:
> In section 2.3, development process, I suggest reordering the vault
> operations based on assumed complexity:
>
> 1. Authentication and Vault
> 2. Archive list and delete
> 3. Archive upload
> 4. Archive multi-part upload (optional)
> 5. Provider implementation
>
> You can use the AWS console to bootstrap a few sample archives for list
> and delete.
>
> I think we should further break down step 1 into:
>
> 0. Provider skeleton
> 1. Vault operations
>
> Step 0 might require some more time to for general ramp up, creating the
> skeleton in jclouds-labs-aws, and creating API metadata. We should pad
> this time out a little bit so your do not start the summer behind
> schedule.
>
> Discussed offline, but having a BlobStore view would make a good step 6.
> While the Glacier model does not lend itself well to random read
> operations, we should allow applications written against Glacier
> expectations to move to other traditional blobstore providers, e.g.,
> Swift. We may need to add an accommodation in the BlobStore API to hint
> that an archive will be read in the future which would help with
> multiple archive reads. For Glacier this would initiate a job and for
> other providers this would have no operation.
>
> Some nits: decapitalize jclouds, capitalize "I"
>
> Overall this looks like an exciting proposal!
>
> On Mon, Mar 17, 2014 at 02:09:14PM +0100, Roman Coedo wrote:
> > Hi,
> >
> > I've made a draft for my proposal to implement jclouds' support for
> Amazon
> > Glacier and I'd like to share it with you. Any suggestions would be
> really
> > appreciated.
> >
> > You can check it on this link:
> >
> https://drive.google.com/file/d/0B3lMiDkiDwpUanRrZUphSkNEX2s/edit?usp=sharing
> >
> > Thanks for your time.
>
> --
> Andrew Gaul
> http://gaul.org/
>
Re: [GSoC] Amazon Glacier Support: Proposal Draft
Posted by Andrew Gaul <ga...@apache.org>.
In section 2.3, development process, I suggest reordering the vault
operations based on assumed complexity:
1. Authentication and Vault
2. Archive list and delete
3. Archive upload
4. Archive multi-part upload (optional)
5. Provider implementation
You can use the AWS console to bootstrap a few sample archives for list
and delete.
I think we should further break down step 1 into:
0. Provider skeleton
1. Vault operations
Step 0 might require some more time to for general ramp up, creating the
skeleton in jclouds-labs-aws, and creating API metadata. We should pad
this time out a little bit so your do not start the summer behind
schedule.
Discussed offline, but having a BlobStore view would make a good step 6.
While the Glacier model does not lend itself well to random read
operations, we should allow applications written against Glacier
expectations to move to other traditional blobstore providers, e.g.,
Swift. We may need to add an accommodation in the BlobStore API to hint
that an archive will be read in the future which would help with
multiple archive reads. For Glacier this would initiate a job and for
other providers this would have no operation.
Some nits: decapitalize jclouds, capitalize "I"
Overall this looks like an exciting proposal!
On Mon, Mar 17, 2014 at 02:09:14PM +0100, Roman Coedo wrote:
> Hi,
>
> I've made a draft for my proposal to implement jclouds' support for Amazon
> Glacier and I'd like to share it with you. Any suggestions would be really
> appreciated.
>
> You can check it on this link:
> https://drive.google.com/file/d/0B3lMiDkiDwpUanRrZUphSkNEX2s/edit?usp=sharing
>
> Thanks for your time.
--
Andrew Gaul
http://gaul.org/
Re: [GSoC] Amazon Glacier Support: Proposal Draft
Posted by Roman Coedo <ro...@gmail.com>.
Hi Andrew,
1. As Provider implementation I meant creating the provider's metadata and
provider specific API classes, as Ignasi pointed in a previous mail. By the
way, maybe i should be clearer on that point.
2. Yes, that's a great idea, thanks for pointing it out. I wrote about it
on the list of deliverable results but i should explain it as part of the
project planning.
3. I was wondering about the same too. I don't know yet if it will really
fit the Blobstore View, because it takes literally hours to read a file.
It's not a common storage service and their use cases will be different
from the use cases for common storage services.
Thanks for the suggestions, your help is really appreciated!
Regards
2014-03-17 20:39 GMT+01:00 Andrew Phillips <ap...@qrmedia.com>:
> Hi Roman
>
> Thanks for putting this together! A couple of initial questions:
>
> * > 5. Provider Implementation
>
> If I understand the planned iterations before that, you will *already* be
> implementing the provider. Is this supposed to be "finish provider
> implementation", or are you thinking of something else here?
>
> * You may want to mention the creation of an working example in the
> jclouds-examples repo [1] as part of the documentation effort
>
> * Would you be intending to try to make the Glacier API support one of the
> abstract views (BlobStore, probably?), or keep it as an API and a provider?
>
> Hope those questions make some kind of sense!
>
> Regards
>
> ap
>
> [1] https://github.com/jclouds/jclouds-examples
>
Re: [GSoC] Amazon Glacier Support: Proposal Draft
Posted by Andrew Phillips <ap...@qrmedia.com>.
Hi Roman
Thanks for putting this together! A couple of initial questions:
* > 5. Provider Implementation
If I understand the planned iterations before that, you will *already*
be implementing the provider. Is this supposed to be "finish provider
implementation", or are you thinking of something else here?
* You may want to mention the creation of an working example in the
jclouds-examples repo [1] as part of the documentation effort
* Would you be intending to try to make the Glacier API support one of
the abstract views (BlobStore, probably?), or keep it as an API and a
provider?
Hope those questions make some kind of sense!
Regards
ap
[1] https://github.com/jclouds/jclouds-examples