Resurrect the Package about aws.ec2 HOT 2 OPEN

I completely agree on the target for a baseline!

I'm going to start with the separate-by-API-action functions, and then we can figure out wrappers for them.

I can also imagine building in wrappers for things like launching an instance using the Rstudio server GPU snapshot, etc. Basically I think once we have it buttoned down, if we do anything using the marketplace, we should consider adding it as its own function :D

Updating the checklist to reflect your MVP suggestions.

I did describe_account_attributes simply because that file was first (alphabetically) in the original project, but I don't think it hurts to have that baked.

from aws.ec2.

Here's what I think the MVP for this package should include functionality-wise:

• Launch / create-new instances (run_instances())
  • doing this
• Get a list of running instances (or a single isntance) with basic attributes (describe_instances())
  • Unfortunately (probably because of the API?) this is currently spread out over a few functions including:
    • describe_instances()
    • instance_status()
    • get_instance_public_ip()
  • From a user's perspective it feels like there should be one call that would return all of these things (even if that doesn't match the API exactly). Maybe we start out matching the API and then add wrappers on top to return more user-friendly objects?
• Start / stop instances (start_instances(), stop_instances())
• Terminate instances (terminate_instances())

I think the next tier down are functions for managing VPCs and Security groups, e.g.,

• create_keypair()
• create_sgroup()
• authorize_ingress(), authorize_egress()

In general I think it's a good principle that for every *_create() function we have a matching *_describe() and a matching *_terminate() or *_stop() or *_delete()

I would say everything else that's in the package comes in the third tier -- I'd rather have a package that supports the core use-cases well than one that extensively covers every possible thing you can do with AWS -- if you really need to be tightly managing EBS's, images, security groups, and VPCs there are other better tools out there (e.g., terraform & friends).

I think the use-case we should focus on supporting is the small data science team that wants to be able to script setting up ad-hoc computing instances which I think the above covers well. Anything that doesn't happen in this library, they can always do from the AWS CLI (which is really good!) or from the admin panel, so I am not very concerned about "completeness". I want to identify the most common workflows, and support those really well.

from aws.ec2.