-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add boto3action to aws pack #37
Conversation
…d json_serial into lib
Thanks for opening this - might be worth including a link to https://github.com/StackStorm-Exchange/exchange-incubator, as there was some useful context captured there. Summarizing the intention in the description would be good too. I have a feeling the future of this pack will refer back to this PR at least a few times 😄 |
@Mierdin Good call. I brought over, what I thought important points to description. Please see if I am missing anything. |
Thanks for the PR. Per our conversation, I'd suggest updating the README with examples on how to use the new actions. Document examples with and without using assume_role. |
as discussed with Dinesh the main issue i have with this approach is it stops actions being discreet and independent - you'd need to call the assume_role action each time before any other action, which means to run any action against a second account will force each action to become a workflow. The model I'd prefer is to have the assume_role and region as arguments within each action, which would then be passed through run.py and lib/action.py so each action can still be called individually have raised #38 to show this approach. Haven't regenerated the actions in the pack though to make it easier to see the actual change |
Andy, case you are making is useful for testing and debugging cross account calls. I agree that we should consider adding assume_role to boto3action, to make it independent. However, in a workflow, I don't think it is make sense to call assume_role for every action. In a workflow, I prefer to assume_role once and reuse credentials in actions. |
the difference is the action run at the beginning to get credentials, and everything else relying on that being there, as opposed to all actions standing on their own and being discrete you either have to update every action to be able to take credentials, which i'd prefer not to pass between actions - that's managed on a pack level imo - or you're updating every action to be able to assume a role. both require every action to be updated (via the generator), but its whether you allow a user to enter credentials, or whether you let stackstorm/aws pack look after credentials under the hood instead. obviously both could be added and maybe that's the way that allows the most flexibility, but then you have a large generated pack with one single non-generated action one for the stackstorm guys as it's not really a technical question @warrenvw |
Should we close this ? As we have same PR against boto3 branch. |
Closing. This PR is replaced by #44. |
I create this pull request as a result of discussion happened in, StackStorm-Exchange/exchange-incubator#10. Main features in this pull request are,
For example, I have a st2 deployment in aws account 123456 and us-east-1. I want to deploy VPC in account 456789 and us-west-1.
In addition,
aws.boto3action
created with following opinions.Boto3 is the official SDK for AWS. As a user/developer, If I have boto3 configured I expect
aws
pack to work without doing any additional configuration. For example,In addition, if I want to use use boto3 profiles
yaml generation
Long term, I don’t believe yaml generation scale based on the number of services AWS have and introduce. In addition, IMO Boto3 documentation is detailed, has examples. Having yaml for each action is redundant and add no value to the end user.
pack maintenance
Since there are no yaml to generate, this pack should be easy to maintain. Any new service boto3 introduce, available to pack user right away.