OCI Object Storage Repository [RFC]

[sam-herman]

RFC - OCI Object Storage Repository

Overview

Currently the existing blob store repositories do not support OCI object storage. Therefore we have developed an OCI native plugin for object storage that is convenient to use on the OCI platform.
We would like to contribute the plugin back to the community and would love to get the community feedback on a couple of topics.

Plugin Features

In addition to compatibility with OCI Object store API we have also added a couple of features that help to better leverage the OCI platform:

1. Integration with instance principals - Very popular example on the OCI platform is that you can configure the below repository and take advantage of instance principal authentication without the need to push credentials explicitly into the OpenSearch keystore. This saves a lot of operational overhead of secret management
2. Force bucket creation - If repository bucket doesn't exist go ahead and create it. This can often make automation of deployments and snapshot configuration easier as we don't need to have an extra step required to create the object storage bucket.

Here is a configuration example that demonstrates both:

curl -XPUT "https://localhost:9200/_snapshot/oci_repository" -H 'Content-Type: application/json' -d"
{
  \"type\": \"oci\",
  \"settings\": {
    \"client\": \"default\",
    \"endpoint\": \"https://objectstorage.${OCI_REGION}.oraclecloud.com\",
    \"bucket\": \"${OCI_BUCKET}\",
    \"namespace\": \"${NAMESPACE}\",
    \"bucket_compartment_id\": \"${OCI_BUCKET_COMPARTMENT}\",
    \"useInstancePrincipal\": true,
    \"forceBucketCreation\" : true
  }
}
" -u <user>:<password> --insecure

Plugin location

Currently we have the plugin as a standalone plugin and would like to contribute it, the question though is whether we should create a new repository for it like we do with other plugins or put it under the OpenSearch repo with the 3 main blob store plugins (S3/Azure/GCP).

There is also a preference from our side to contribute initially in a separate repo since we run into some difficulties to incorporate directly as part of the OpenSearch repo. So our suggestion would be to start with a standalone repo and later consolidate with OpenSearch repo or any other that the community finds appropriate.

Moreover, at some point, we as a community would have to decide what is the long term approach for the location of vendor specific blob store plugins, should it go within main OpenSearch repo or be consistent with all other plugins.

Feedback requested

1. Plugin location.
2. Additional features.

Old post:

Hey folks,

Currently the existing blob store repositories do not support OCI object storage.

Therefore we have developed an OCI native plugin for object storage that is convenient to use on the OCI platform.

For example you can configure the below repository and take advantage of instance principal authentication without the need to push credentials explicitly into a secret store. Can also force bucket creation if the bucket is missing.

curl -XPUT "https://localhost:9200/_snapshot/oci_repository" -H 'Content-Type: application/json' -d"
{
  \"type\": \"oci\",
  \"settings\": {
    \"client\": \"default\",
    \"endpoint\": \"https://objectstorage.${OCI_REGION}.oraclecloud.com\",
    \"bucket\": \"${OCI_BUCKET}\",
    \"namespace\": \"${NAMESPACE}\",
    \"bucket_compartment_id\": \"${OCI_BUCKET_COMPARTMENT}\",
    \"useInstancePrincipal\": true,
    \"forceBucketCreation\" : true
  }
}
" -u <user>:<password> --insecure

We actually already have the plugin ready as a standalone plugin and would like to contribute it, the question though is whether we should create a new repository for it like we do with other plugins.

There is also a preference from our side to contribute initially in a separate repo since we run into some difficulties to incorporate directly as part of the OpenSearch repo. So perhaps we can start with that and later consolidate with OpenSearch repo or any other that the community finds appropriate?

Thanks in advance,
Sam.

[jcgraybill]

How great! A standalone repo does make intuitive sense as the way to start, and I see no reason the user experience couldn't match that for the other object-store plugins (azure, s3, etc.) @CEHENKLE @anirudha @dblock and @bbarani can you connect with @samuel-oci and get an RFC together for community input?

[stockholmux]

I'm excited about this!

@jcgraybill regarding the user experience: the one difference would be that having it external would mean that -min distributions would exclude this plugin yet the other object-store plugins would be in -min distributions.

[sam-herman]

Hi @anirudha @dblock @bbarani @CEHENKLE , if you can refer me to a document that describe RFC format I can take a stab at it.

[sam-herman]

Also how would you prefer to go about the RFC? start a new issue or edit this one? or just add the full RFC in the comments?

[dblock]

I don't think we standardized on a format, but start with something like #1694, and I would edit this one unless the scope changes.

[sam-herman]

Thanks @dblock I updated this original post to match the RFC format, if you would rather have it moved to another issue feel free to do so. In any case would love to hear your feedback.

[jcgraybill]

Let's post to the forums to get some eyes on it, and also could we bring this up at a community meeting?

[stockholmux]

@samuel-oci If you want to talk about this at a community meeting, pick out a date that works for you here:

https://opensearch.org/events/

Then add it as a comment in the agenda (anyone can comment) - we'll approve it and mark it in the agenda.

[sam-herman]

Hey @stockholmux @jcgraybill I added this as an agenda item in the next meeting:
https://hackmd.io/@HmdZWaVnQU6M8icdvC5TwQ/ByKuRz8hK

[sam-herman]

Hey @anirudha @stockholmux @jcgraybill @dblock just trying to bring this back on your radar. Any thoughts on how you would like to proceed on this one?

[dblock]

@samuel-oci This is what I would do:

1. Publish code in a new repo anywhere to GitHub with an APLv2 license. Is it somewhere already?
2. Open an issue in that repo similar to Move repo to opensearch-project opensearch-plugin-template-java#4 to move the repo to the opensearch-project organization if that's your preferred next step. We will have something actionable and can discuss it.
3. If we decide (2) doesn't make sense, you'll always have the option to PR the change on top/next to azure and other plugins, just because that's an existing pattern.

WDYT?

[sam-herman]

Hey @dblock , I see the repository was created with default template. Thank you for that!
I think what I can do next is to submit a PR with what we currently have for the plugin as the initial commit.

[CEHENKLE]

@samuel-oci Hi -- Yup, I created the repo yesterday :) I'm working to close out the last step to add you as a maintainer, which I hope to close out today (slightly tangled in tooling over here). If you open a PR, hopefully you'll be able to merge it yourself tonight.

Thanks,

[dblock]

Hey @dblock , I see the repository was created with default template. Thank you for that! I think what I can do next is to submit a PR with what we currently have for the plugin as the initial commit.

@CEHENKLE did all the work here!

[sam-herman]

Thank you @CEHENKLE I got the email with the invite to collaborate, but it seems after accepting it I only have view privileges. Should I be getting another one later?

[sam-herman]

For reference here is the PR
opensearch-project/opensearch-oci-object-storage#1

[dblock]

I'll close this issue here (I am sure @CEHENKLE will fix permissions soon), everyone can go contribute to https://github.com/opensearch-project/opensearch-oci-object-storage. Run with it @samuel-oci, all yours.