search

planetlabs / planet-client-python

Python client for Planet APIs
https://planet-sdk-for-python-v2.readthedocs.io/en/latest/
Apache License 2.0
271 stars 91 forks source link

Helper method for creating cloud configs #613

Open cholmes opened 2 years ago

cholmes commented 2 years ago

Right now we make users just specify a json file for their cloud configuration.

It'd be great if we could help them a bit, with a CLI to more easily create a cloudconfig json without having to think about JSON.

Most people will likely just create one or at most a handful of these, and likely store them somewhere they could easily access them. So we could try to do a more interactive approach, where they enter the cloud they want to configure for, and then it asks them the questions, perhaps with pointers on how to get the info.

That could also open the possibility to try to do more streamlined things, like if there are ways to integrate with the cloud CLI's and extract the auth from them or make calls on the user's behalf.

Right now orders and subscriptions are basically the same, but have slightly different syntaxes, just like in #601. So a top level planet cloudconfig option likely makes sense. It sounds like the Planet API team is up for orders to support the subscriptions syntax before too long, so we could default to subscription style, but have an alternate --order option that would make it in the order style to be used before the API accepts both.

Could be nice to be able to set cloudconfig as an environmental variable, so you don't have to keep referring to it. Or some other mechanism to just set it and use it, and maybe easily change to one of a handful of options.

jreiberkyle commented 1 year ago

Similar to #601, the formats (and even the clouds supported) vary between the APIs. It would be easier to treat them separately (and it will be easy to switch over when orders supports subscription style). My suggestion is planet orders request-cloud [OPTIONS] and `planet subscriptions request-delivery [OPTIONS]'

cholmes commented 1 year ago

What's the difference between clouds supported? In my quick look it seems like it's amazon, google, azure and oracle for both.

This is one where as a user I'd much prefer to just run 'request-cloud' once and have that in a location where I can just refer to it, and ideally refer to it with both the subscriptions and orders functions. Like it'd output in 'subscriptions' format, but when you do --delivery delivery.json in an orders request it'd transform delivery.json into the proper 'orders' parameters.

We also could consider an experience where there's just like an 'init cloud-delivery' function, where it'd store your credentials, and you could just refer to them. Perhaps you name each cloud-delivery option you want. And then you can just do --delivery <cloud-delivery name> (could also take JSON file as an option).

jreiberkyle commented 1 year ago

ohhh the init cloud-delivery function sounds cool!

In regard to one function to rule them all, that would be nice but it is just complex at the implementation level right now. But, now that we have pathways for orders and subscriptions, eventually they could be combined.

For clouds supported: for subscriptions image

for orders image

clouds supported: close but not exactly the same. json schemas: close but not exactly the same.

cholmes commented 1 year ago

I think us doing the work so user's don't have to figure out the complexity is more than worth it. If the D&D wasn't so busy I'd push them to reduce complexity at their end. But if it's too complex for you then it's fine to do them separately. I do think the 'init cloud-delivery' function would be good (or at least a recommend pattern for what to name the json's you create for cloud delivery and where you put them - maybe encourage an environment variable or something). But I guess it could 'planet orders init cloud-delivery' and 'planet subscriptions init cloud-delivery'

JSee98 commented 1 year ago

Hi, @cholmes and @jreiberkyle. I'd b more than happy to help with this task. I like the single global config file approach that can be transformed into the order or subscription schema. I understand that will take long so if there isn't a very strict deadline that is coming up soon I'd love to implement this. If not I think separate schemas can be generated.

If it seems fine with you guys, I can sketch up a basic design of the feature implementation and can share for you guys to analyze.

cholmes commented 1 year ago

Hey @JSee98! That'd be awesome to help on this task. A basic design proposal before starting would be great, with the exact signatures you'd see for the commands . I think I'd break it up into a few phases, as I think you could do a set of PR's where each advances things, and that'd be the best way to work. I'd recommend something like:

JSee98 commented 1 year ago

Great @cholmes !! Will try to get the design doc out soon (probably in a day or two)

JSee98 commented 1 year ago

Hey @cholmes, Here is the doc https://docs.google.com/document/d/1WaKvxdAlOK-s4ZfSVq3fw6jUTan6cXZyrXTBrqClxfk/edit?usp=sharing Please add any suggestions or changes that you might want via comments. I'm currently working on creating a delivery.json as the subscription format. Will raise the PR for the same.

cholmes commented 1 year ago

Looks good! I put one small comment in the doc, but definitely looks good enough to start on, and I can give feedback when you have something working. Just aim for granular pr’s, like feel free to do the python api first then the cli, and for each part.

On Sat, Jul 29, 2023 at 6:24 AM Jayant Chhillar @.***> wrote:

Hey @cholmes https://github.com/cholmes, Here is the doc https://docs.google.com/document/d/1WaKvxdAlOK-s4ZfSVq3fw6jUTan6cXZyrXTBrqClxfk/edit?usp=sharing Please add any suggestions or changes that you might want via comments. I'm currently working on creating a delivery.json as the subscription format. Will raise the PR for the same.

— Reply to this email directly, view it on GitHub https://github.com/planetlabs/planet-client-python/issues/613#issuecomment-1656708855, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADDL2OBCHOSSWDW7G5KQHDXSTXFHANCNFSM52D24OYA . You are receiving this because you were mentioned.Message ID: @.***>

JSee98 commented 1 year ago

Hey @cholmes, saw that comment. Went back to the docs, i.e.

However, couldn't find much difference between the two. My current assumption is that delivery.json will only contain the delivery object defined in the docs above.

I had started with the dev as per my current understanding and can update the same if needed.