10 Jul
2019
10 Jul
'19
10:10 a.m.
Dear Ceph developers,
Recently in the context of reviewing PR:
https://github.com/ceph/ceph/pull/28787 we got into a conversation about
what would be a good practice to introduce an AWS-S3 unsupported feature in
Ceph and how upstream libraries/SDKs would react to the new feature
addition.
More specifically, I'm intending to introduce a feature through which a
bucket can be deleted by lifecycle (LC) configuration upon expiry, subject
to a few conditions such as the bucket being empty + it should be past the
expiry date (or aged beyond expiry_days since ctime).
The RFC here is around how the end-user should specify this LC-Rule for
bucket expiry. I've chosen to convert the 'State' field in the LC-Rule into
a tri-state from a boolean i.e.
'Disabled'/'Enabled'/'Purge_Enabled'
(instead of having only the first two states) and it has the following
advantages:
a) It is non-intrusive i.e. existing users of LC who have no interest in
bucket purge need not make any changes to their code
b) It can be easily enabled by interested users without requiring a patch
on their SDKs (which allow a pass-through of the Status string).
Does the community feel that this approach is good or are there any better
suggestions?
Thanks,
K.Prasad
10 Jul
10 Jul
11:52 a.m.
Hi Prasad,
As I and Casey noted in the PR, the obvious way would be to extend the
lifecycle grammar to introduce a new rule element. As I noted, this
is the path we've already followed with IAM policy, without any
notable issue. The schema checking that existing tools may be doing
(sometimes just by using XML interfaces, I suspect) reveals a need for
processes (contributions to those tools, perhaps reference to
different schema when using them?) to allow for more orderly evolution
of S3 in the community. From what I understand, haven't you also
found that some tool versions took issue with new status code tokens,
as well?
Matt
On Wed, Jul 10, 2019 at 6:10 AM Prasad Krishnan
<prasad.krishnan(a)flipkart.com> wrote:
Dear Ceph developers,
Recently in the context of reviewing PR: https://github.com/ceph/ceph/pull/28787 we got
into a conversation about what would be a good practice to introduce an AWS-S3 unsupported
feature in Ceph and how upstream libraries/SDKs would react to the new feature addition.
More specifically, I'm intending to introduce a feature through which a bucket can be
deleted by lifecycle (LC) configuration upon expiry, subject to a few conditions such as
the bucket being empty + it should be past the expiry date (or aged beyond expiry_days
since ctime).
The RFC here is around how the end-user should specify this LC-Rule for bucket expiry.
I've chosen to convert the 'State' field in the LC-Rule into a tri-state from
a boolean i.e. 'Disabled'/'Enabled'/'Purge_Enabled' (instead of
having only the first two states) and it has the following advantages:
a) It is non-intrusive i.e. existing users of LC who have no interest in bucket purge
need not make any changes to their code
b) It can be easily enabled by interested users without requiring a patch on their SDKs
(which allow a pass-through of the Status string).
Does the community feel that this approach is good or are there any better suggestions?
Thanks,
K.Prasad
_______________________________________________
Dev mailing list -- dev(a)ceph.io
To unsubscribe send an email to dev-leave(a)ceph.io
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103
http://www.redhat.com/en/technologies/storage
tel. 734-821-5101
fax. 734-769-8938
cel. 734-216-5309
4:33 p.m.
Hi Matt,
Thank you for the reply.....my responses inline.
On Wed, Jul 10, 2019 at 5:22 PM Matt Benjamin <mbenjami(a)redhat.com> wrote:
Hi Prasad,
As I and Casey noted in the PR, the obvious way would be to extend the
lifecycle grammar to introduce a new rule element. As I noted, this
is the path we've already followed with IAM policy, without any
notable issue.
Will be glad if you can provide me a link to the patch/PR which introduced
this.
I'm assuming that none of the SDKs needed additional support for this?
The schema checking that existing tools may be doing
(sometimes just by using XML interfaces, I suspect) reveals a need for
processes (contributions to those tools, perhaps reference to
different schema when using them?) to allow for more orderly evolution
of S3 in the community.
True, S3 is becoming a de-facto standard for object store and without a
standards body where proposals can be submitted and discussed I'm not sure
how requirements such as ours can be handled.
Having said that, let me do some more research on the feasibility of
expanding
the LC Rule syntax and get back to this mailing list.
From what I understand, haven't you also
found that some tool versions took issue with new status code tokens,
as well?
That was with ageing boto and wasn't a problem with Boto3.
Thanks,
K.Prasad
Matt
On Wed, Jul 10, 2019 at 6:10 AM Prasad Krishnan
<prasad.krishnan(a)flipkart.com> wrote:
Dear Ceph developers,
Recently in the context of reviewing PR:
https://github.com/ceph/ceph/pull/28787
we got into a conversation about
what would be a good practice to introduce an AWS-S3 unsupported feature in
Ceph and how upstream libraries/SDKs would react to the new feature
addition.
More specifically, I'm intending to introduce a feature through which a
bucket
can be deleted by lifecycle (LC) configuration upon expiry, subject
to a few conditions such as the bucket being empty + it should be past the
expiry date (or aged beyond expiry_days since ctime).
The RFC here is around how the end-user should specify this LC-Rule for
bucket
expiry. I've chosen to convert the 'State' field in the LC-Rule into
a tri-state from a boolean i.e.
'Disabled'/'Enabled'/'Purge_Enabled'
(instead of having only the first two states) and it has the following
advantages:
a) It is non-intrusive i.e. existing users of LC
who have no interest in
bucket purge need not make any changes to their code
b) It can be easily enabled by interested users
without requiring a
patch on their SDKs (which allow a pass-through of the Status
string).
Does the community feel that this approach is good or are there any
better
suggestions?
Thanks,
K.Prasad
_______________________________________________
Dev mailing list -- dev(a)ceph.io
To unsubscribe send an email to dev-leave(a)ceph.io
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103
http://www.redhat.com/en/technologies/storage
tel. 734-821-5101
fax. 734-769-8938
cel. 734-216-5309
1781
days inactive
1781
days old
2 comments
2 participants
participants (2)
-
Matt Benjamin -
Prasad Krishnan