Skip to content
This repository has been archived by the owner on Jun 5, 2020. It is now read-only.

(WIP)(CLOUD-184, CLOUD-205) Make the region param and ENV var interchangable #117

Closed

Conversation

garethr
Copy link
Contributor

@garethr garethr commented Mar 18, 2015

(Note that I've put this up just applying to security groups so as to get feedback on whether we should do some/all/none this as much as the implementation)

This allows for creating and deleting resources from puppet resource by
passing the environment variable (which is already used for scoping).

Prior to this change you would have to pass the information twice. If
you do pass both we maintain the same approach as previous, giving the
param a higher precedence.

This also allows for not specifying the region in the DSL, and instead
using the AWS_REGION variable. This matches the standard behaviour of
other AWS tools, and means in the case of not providing anything the
correct error bubbles through.

@garethr garethr changed the title Make the region param and ENV var interchangable (CLOUD-184, CLOUD-205) Make the region param and ENV var interchangable Mar 18, 2015
@Iristyle Iristyle changed the title (CLOUD-184, CLOUD-205) Make the region param and ENV var interchangable (DO NOT MERGE)(CLOUD-184, CLOUD-205) Make the region param and ENV var interchangable Mar 20, 2015
@@ -98,6 +98,12 @@ def self.tags_for(item)
tags
end

def target_region
target = resource ? resource[:region] || region : region
Copy link
Contributor

Choose a reason for hiding this comment

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

Where does region come from? Should this method have a parameter list (region = default_region)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

region in this context is the value of the region property. This basically says:

  • If you specify a region (ie. on the command line like puppet resource ec2_securitygroup bob region=blah or in the DSL, use that
  • If that isn't present, fall back to the value of region for the resource

@garethr
Copy link
Contributor Author

garethr commented Mar 20, 2015

Agreed. I'm unsure about this too.

I'm tempted to say if the env variable ever doesn't match the region value of a type we fail in the type validation. That blocks the entire run. Thoughts?

I think we should do that whether we merge this PR or not.

@Iristyle
Copy link
Contributor

Yes @garethr I was talking with @cmurphy and this seems like a tough nut to crack. At first I suggested that we could use apply a rule that AWS_REGION env var takes over everything... but that's not a very good idea.

So your suggestion is to blow up the run when the resource defined in the manifest has a region that doesn't match the env var? I think that's probably a good thing to do...

@garethr
Copy link
Contributor Author

garethr commented Mar 21, 2015

@Iristyle yup. I like the filtering ability. It's a great performance optimisation, and it would allow for scaling out by region if you had lots of ec2 resources. But that power comes with complexity that I don't like.

If we stop the run at compile time if any resource has a region that doesn't match the ENV then I think it's much safer. It means we never hit issues like the one you describe. We also catch issues we're you forget you have the ENV set.

This allows for creating and deleteing resources from puppet resource by
passing the environment variable (which is already used for scoping).

Prior to this change you would have to pass the information twice. If
you do pass both we maintain the same approach as previous, giving the
param a higher presendence.

This also allows for not specifying the region in the DSL, and instead
using the AWS_REGION variable. This matches the standard behaviour of
other AWS tools, and means in the case of not providing anything the
correct error bubbles through.
@garethr
Copy link
Contributor Author

garethr commented Mar 21, 2015

@Iristyle @cmurphy I've changed this as discussed. Let me know if this works for you and I'll expand to the other relevant types.

garethr added a commit to garethr/puppetlabs-aws that referenced this pull request Mar 24, 2015
If using the AWS_REGION environment variable and a manifest where the
region property of one or more resources doesn't match you can see
unspecified behaviour. See
puppetlabs-toy-chest#117 for discussions.

This PR extracted from the above simply stops that from happening. If
the env is present and doesn't match All of the region properties then
we fail. This maintains the utility of the env var as an optimisation
but stops us shooting ourselves in the foot.
@garethr
Copy link
Contributor Author

garethr commented Mar 24, 2015

I've extracted the region type and made a separate PR for just the blocking behaviour #132

@garethr garethr changed the title (DO NOT MERGE)(CLOUD-184, CLOUD-205) Make the region param and ENV var interchangable (WIP)(CLOUD-184, CLOUD-205) Make the region param and ENV var interchangable Dec 8, 2015
@garethr
Copy link
Contributor Author

garethr commented Dec 8, 2015

I'm going to close this. It has a bunch of unanswered questions. It's hopefully useful as and when the core issue gets some time.

@garethr garethr closed this Dec 8, 2015
MWilkinson pushed a commit to ctidigital/puppetlabs-aws that referenced this pull request Mar 23, 2017
If using the AWS_REGION environment variable and a manifest where the
region property of one or more resources doesn't match you can see
unspecified behaviour. See
puppetlabs-toy-chest#117 for discussions.

This PR extracted from the above simply stops that from happening. If
the env is present and doesn't match All of the region properties then
we fail. This maintains the utility of the env var as an optimisation
but stops us shooting ourselves in the foot.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants