planet-client-python
planet-client-python copied to clipboard
planetlabs
Helper method for creating cloud configs
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.
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]'
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).
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
for orders
clouds supported: close but not exactly the same. json schemas: close but not exactly the same.
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'
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.
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:
- Start with subscriptions, get a command that generates the delivery.json from input. (subscriptions format will be the future, and in general is the more future-oriented API, so I think it should be the canonical storage format).
- Add ability to get an order delivery.json. Ideally you could input a subs delivery.json, and also use the same command but with like an '--output orders' flag.
- Add 'init' type functionality, so you can set one default cloud config
- Explore 'profiles', how you can have two different clouds. There's good precedence on aws / google cloud command lines.
- Explore further convenience - like is there a way to just look-up / use info that's set up with the cloud CLI's
Great @cholmes !! Will try to get the design doc out soon (probably in a day or two)
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.
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: @.***>
Hey @cholmes, saw that comment. Went back to the docs, i.e.
- https://developers.planet.com/apis/orders/delivery/#delivery-to-cloud-storage
- https://developers.planet.com/docs/subscriptions/delivery/#supported-delivery-options
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.