8000 Adding support for EMR resources by alonsodomin · Pull Request #421 · cloudtools/troposphere · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Adding support for EMR resources #421

8000
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

Merged
merged 30 commits into from
Apr 4, 2016
Merged

Conversation

alonsodomin
Copy link

Created new module to hold all the new EMR resources and types plus a basic example that creates an EMR cluster will all the applications (Hadoop, Spark, etc.) installed in it.


class Application(AWSProperty):
props = {
'AdditionalInfo': (dict, False),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't appear to be a dict in the Cloudformation docs - it might call for it's own validator.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AdditionalInfo seems to be documented as a JSON Object, that's why I chose the dict to represent it. Is there a better way?

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-emr-cluster.html#cfn-emr-cluster-additionalinfo

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh yes! sorry, it's using another colon-separated key-value pair list... ¬¬

@alonsodomin
Copy link
Author

Right, so I added more strict validations and enriched the test template with more details plus the sample step from AWS docs.

There seems to be some incongruences in the AWS docs anyway. One of them is regarding that self-recursive Configuration "dictionary" as in here the docs say that it's compound of three attributes: Classification, ConfigurationProperties and additional Configurations. However when getting into more detail here, now the attribute ConfigurationProperties is named simply as Properties.

Another incongruence can be seen in the configuration of the step. The HadoopJarStepConfig structure documente in here has an Args attribute which, apparently, is of type String. In the other hand, in the sample JSON given for an step configuration in here, we can see that the Args attribute is not a list of strings instead.

Will try to test the last version of the example template once I get a chance in our cluster to see what is the correct encoding.

@phobologic
Copy link
Member

Cool - thanks for diving into this @alonsodomin - I'll try to get a chance to look at it today!

@alonsodomin
Copy link
Author

Sorry for the delay on this, getting a slot to experiment cluster configuration in the cluster usually doesn't sit at the top of the priority list ;)

Anyway, it seems that the correct encoding for the cluster & instance group configuration, using ConfigurationProperties instead of Properties as some other docs says, is the right one.

Same for the HadoopJarStepConfig, the example JSON is right.

@alonsodomin
Copy link
Author

btw, also took the chance to rebase my fork on top of master.

class Application(AWSProperty):
props = {
'AdditionalInfo': (additional_info_validator, False),
'Args': (list, False),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be [basestring]

@alonsodomin
Copy link
Author

Long time since last update. I managed to test the incongruence in the AWS docs regarding the HadoopJarStepConfig showing that the Args attribute is a String in one place but an array in another. As it is right now seems to be the correct implementation.

Let me know your thoughts about the other comments (i.e.: the validator for the self-recursive Configuration type) and whether you are happy or not to start the standard rebase-squash process to get the branch ready for being merged...

@phobologic phobologic merged commit f5eeaa5 into cloudtools:master Apr 4, 2016
@phobologic
Copy link
Member

Great - thanks @alonsodomin - I went ahead and used the new 'squash & merge' feature of github to merge this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0