Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Revisit environment agnostic operation #219

Open
t0yv0 opened this issue Nov 14, 2024 · 1 comment
Open

Revisit environment agnostic operation #219

t0yv0 opened this issue Nov 14, 2024 · 1 comment
Labels
kind/enhancement Improvements or new features

Comments

@t0yv0
Copy link
Member

t0yv0 commented Nov 14, 2024

Hello!

  • Vote on this issue by adding a 👍 reaction
  • If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

CDK has two modes of operation:

  • environment agnostic (no account/region)
  • user explicitly sets account/region

We need to revisit what is best for Pulumi CDK:

  1. how to map this and explain for users that are used to CDK, how does it "translate to Pulumi"?
  2. should we consider getting ambient AWS credentials and automatically injecting account/region into CDK stack or not (what the defaults should be)

Affected area/feature
@t0yv0 t0yv0 added kind/enhancement Improvements or new features needs-triage Needs attention from the triage team labels Nov 14, 2024
@t0yv0
Copy link
Member Author

t0yv0 commented Nov 14, 2024

This came up in discussion of Fn::If - the conditionals are mostly in practice used for the environment agnostic operation. THanks @corymhall

@flostadler flostadler removed the needs-triage Needs attention from the triage team label Nov 14, 2024
@t0yv0 t0yv0 mentioned this issue Nov 19, 2024
Open
corymhall added a commit that referenced this issue Nov 22, 2024
@corymhall
Add ability to specify resource options at the stack level
0109a47 
It has been possible to specify Pulumi resource options at the stack
level, but it did not flow through to the actual resources. This PR
makes sure that the inheritance works correctly.

This PR also adds functionality to automatically set the Stack
environment based on the App provider. Because the App creates the
stacks in an async context, we can use provider functions to lookup the
environment and then pass the resolved environment to the stack. This
means that all Stacks have their environment provided by default. This
will cut down on the number of Intrinsics used in the generated
template.

If the user provides a provider to the Stack we are no longer in an
async context which means we can't determine the environment from the
provider and fall back to an environment agnostic stack.

re #61, re #219
@corymhall corymhall mentioned this issue Nov 22, 2024
Merged
corymhall added a commit that referenced this issue Nov 22, 2024
@corymhall
Add ability to specify resource options at the stack level
08be058 
It has been possible to specify Pulumi resource options at the stack
level, but it did not flow through to the actual resources. This PR
makes sure that the inheritance works correctly.

This PR also adds functionality to automatically set the Stack
environment based on the App provider. Because the App creates the
stacks in an async context, we can use provider functions to lookup the
environment and then pass the resolved environment to the stack. This
means that all Stacks have their environment provided by default. This
will cut down on the number of Intrinsics used in the generated
template.

If the user provides a provider to the Stack we are no longer in an
async context which means we can't determine the environment from the
provider and fall back to an environment agnostic stack.

re #61, re #219
corymhall added a commit that referenced this issue Nov 25, 2024
@corymhall
Add ability to specify resource options at the stack level
4d2e85a 
It has been possible to specify Pulumi resource options at the stack
level, but it did not flow through to the actual resources. This PR
makes sure that the inheritance works correctly.

This PR also adds functionality to automatically set the Stack
environment based on the App provider. Because the App creates the
stacks in an async context, we can use provider functions to lookup the
environment and then pass the resolved environment to the stack. This
means that all Stacks have their environment provided by default. This
will cut down on the number of Intrinsics used in the generated
template.

If the user provides a provider to the Stack we are no longer in an
async context which means we can't determine the environment from the
provider and fall back to an environment agnostic stack.

re #61, re #219
corymhall added a commit that referenced this issue Nov 25, 2024
@corymhall
Add ability to specify resource options at the stack level (#245)
596084d 
It has been possible to specify Pulumi resource options at the stack
level, but it did not flow through to the actual resources. This PR
makes sure that the inheritance works correctly.

This PR also adds functionality to automatically set the Stack
environment based on the App provider. Because the App creates the
stacks in an async context, we can use provider functions to lookup the
environment and then pass the resolved environment to the stack.

For now this is something that the user will have to specify (example in
the `lookups` example test). This would mean that all Stacks have their
environment provided by default. This will cut down on the number of
Intrinsics used in the generated template. The reason I am not turning
this on by default is because it requires lookups to be enabled
(environment agnostic stacks use Intrinsics to find availability zones,
but explicit environment stacks use lookups).

If the user provides a provider to the Stack we are no longer in an
async context which means we can't determine the environment from the
provider and fall back to an environment agnostic stack.

re #61, re #219
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/enhancement Improvements or new features
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@t0yv0 @flostadler