HELP NEEDED - Can you provide feedback on OCI SDKs?

[kishore-oracle]

Are you an OCI customer and would you be willing to spend a few minutes on a call and provide feedback about your experience of using the OCI SDK? email: zack.menegakis@oracle.com. Thanks.

[lenon]

Hi @kishore-oracle. Unfortunately I can't join on a call, but I can share a few thoughts about the SDK.

We are using the OCI SDK in Puppet to implement custom functions. As Puppet is written in Ruby and has a powerful Ruby API for custom functions, having a Ruby SDK is very helpful. We sure could use the SDK for another language (like Python) or even make HTTP calls directly, but having a Ruby version makes our life much easier.

We also use the SDK in a Ruby application to make some calls to the OCI API. It would be possible for us to replace it by plain HTTP requests, but having the SDK speeds up our development process and our ability to make automated tests.

The question that we are asking right now is regarding the future of the Ruby SDK: it will be maintained or you folks plan to discontinue the project? I know that the README includes a notice saying that "This project is no longer being actively developed by Oracle", but I also noticed new releases and activity over the past few weeks. It would be nice if you can clarify about the future and which path should we follow, if you recommend us to find an alternative or we can keep using the SDK.

Thanks!

[apitta]

Hi,

as a oracle partner company, we use puppet as part of our solution to manage our resources on the cloud. We created puppet types and providers for oci, like oci_instance, oci_loadbalancer, oci_vcn, oci_subnets and so on. Using this implementation, we can declare this resources on puppet manifests (static or dynamic) and interact with oci. So, the puppet providers have oci sdk as a requirement to be able to interact and manage all the resources supported by us on OCI.

we are currently on version 2.7.0 but we are planning to migrate to 2.10.0 to support E3 flex shapes in our platform. We would like to know if the current status in terms of support and evolution will be reviewed for this sdk or if we should start to check other possibilities to solve our problem.

best regards, AP

[zackatoracle]

Hi @lenon and @apitta! Can't thank you enough for providing your feedback and experience using the Ruby SDK. The team here is planning to update the documentation to reflect that we plan on contributing quarterly releases to the Ruby SDK, so yes, we will indeed continue development. We're very glad you're making use of it and will continue to do so. If you have additional suggestions or wish to see certain improvements, please let us know!

[lenon]

Hi @zackatoracle Thanks for the fast response! That's great news, we are happy that you folks are planning to continue developing the SDK. We'll for sure share any suggestions and ask or contribute with improvements.

[jjlimepoint]

Hi there

we also use the OCI SDK in our devops product (MintPress - http://limepoint.com), and we have 3 reasonably large customers using that. I'd be happy to jump on a call to talk about about it if you wanted.

[b-dean]

@zackatoracle and @kishore-oracle, I just logged #70 for a problem that's making it impossible to use the oci-ruby-sdk for us. It kind of relates to a problem I've seen a lot, that aside from making the ~/.oci/config file a very particular way, many things just fail.

What seems to be missing is a set of environment variables that work ubiquitously across all SDK, cli, etc. By comparison, in AWS I can set AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY environment variables and pretty much everything just works, regardless of what API or tool is being used, and it doesn't even care if I've set up a config file or not. Being able to work without config files is pretty useful on builds where we might set environment variables from some secrets, but we don't want to have to make a bunch of files on disk every time. Or worse, commit some ~/.oci/config file in a docker image to use in builds.

[KartikShrikantHegde]

Hi @b-dean ,

Thanks for raising the #70. We will take a look at it and respond to it.

Regarding, using env variables, it is possible to do that today in our SDKs including Ruby SDK. Meaning, that the config file is not a must for the SDKs to authenticate and work.

You can define the auth either directly in your code or as env variables and then use it in your code or through the config file.

Once you set the env var, you can set the config object to read that by doing something like this:

config.user = ENV['oci_user/or_some_other_name']

You might find this useful as well as how you can set env variables in Ruby:

https://www.rubyguides.com/2019/01/ruby-environment-variables/#:~:text=How%20to%20Set%20Environment%20Variables

Hope this helps, Let us know of any issues. Thanks.

[b-dean]

@KartikShrikantHegde, I know how to set environment variables, that's not the problem.

The problem is that in OCI and its various SDKs, there's no standard set of environment variables to set for authentication. There are the oci cli environment variables but these aren't used by the SDKs, at least not ubiquitously like AWS's environment variables.

To confuse matters, there's things like in the oci-go-sdk, environment variables have a TF_VAR prefix, I'm guessing because the oci-go-sdk is used by the oci terraform provider, and TF_VAR is how Terraform allows input variables to be set from environment variables. But it hardly makes sense for that to be how it works all the time, as "standard" environment variables. The terraform provider isn't the only thing that uses the oci-go-sdk.

None of the other OCI sdk problems are exactly related to the ruby sdk. Other than to serve as examples that OCI does not have a cohesive set of environment variables that can be used to configure any SDK.

[KartikShrikantHegde]

Hi @b-dean ,

Got it. Yes for SDK, we don't have a standard set of env vars that can be used instead of a standard config file. We will take a look into this. Thanks for pointing this out for us.