Skip to content

Helper method for creating cloud configs #613

@cholmes

Description

@cholmes
Member

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.

Activity

jreiberkyle

jreiberkyle commented on Feb 9, 2023

@jreiberkyle
Contributor

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]'

added this to the 2.0b3 milestone on Mar 7, 2023
cholmes

cholmes commented on Mar 7, 2023

@cholmes
MemberAuthor

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

jreiberkyle commented on Mar 9, 2023

@jreiberkyle
Contributor

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

cholmes commented on Mar 9, 2023

@cholmes
MemberAuthor

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'

modified the milestones: 2.0b3, 2.0.1: Major improvements on Mar 13, 2023
JSee98

JSee98 commented on Jul 19, 2023

@JSee98
Contributor

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

cholmes commented on Jul 21, 2023

@cholmes
MemberAuthor

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
JSee98

JSee98 commented on Jul 24, 2023

@JSee98
Contributor

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

JSee98

JSee98 commented on Jul 29, 2023

@JSee98
Contributor

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

cholmes commented on Jul 29, 2023

@cholmes
MemberAuthor
JSee98

JSee98 commented on Aug 3, 2023

@JSee98
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @cholmes@jreiberkyle@asonnenschein@JSee98

        Issue actions

          Helper method for creating cloud configs · Issue #613 · planetlabs/planet-client-python