This message was deleted.

sparse-intern-71089

07/13/2018, 1:00 PM

This message was deleted.

stocky-spoon-28903

07/13/2018, 4:38 PM

Can you use the regular SDK for this?

👍 1

tall-librarian-49374

07/13/2018, 6:48 PM

I guess I can... would be handy to do it directly from pulumi though (from cloud API in my case)

tall-librarian-49374

07/13/2018, 7:06 PM

OK, it works. A bit verbose but good enough for now.

stocky-spoon-28903

07/13/2018, 8:02 PM

Maybe a simple API would be a good addition to the

pulumi-aws

package?

big-piano-35669

07/14/2018, 4:02 PM

We definitely want to enable these high level API wrappers over time. This is effectively the intersection of Pulumi's resource APIs and the AWSK SDK itself. I think we're still on the fence about how and where to add this, which is probably why it hasn't happened yet. There are two top-level options: 1) Exactly as @stocky-spoon-28903 suggests, by using overlays in the

pulumi-aws

package itself 2) In a higher level package, similar to https://github.com/pulumi/pulumi-aws-serverless (1) is very appealing, because it'll "just work" and discoverability will be improved, except that we tend to like to keep this layer unopinionated. (2) at least lets us call this what it is -- an optional opinionated layer atop the raw primitive resources -- however, that gets a big -1 in the "it just works" and easy-to-discover category. I also think @white-balloon-205 is worried about our ability to keep up with covering such a broad surface area (in the limit, the entire AWS SDK), however I suspect we can deliver most of the value by doing the Top 20 resource types (SQS queues, Dynamo Tables, etc).

big-piano-35669

07/14/2018, 4:03 PM

I'm not sure if we have a work item already for this -- @white-balloon-205, @lemon-spoon-91807, do we have anything for the broad issue of adding runtime APIs for these abstractions? Or has it been sufficiently just a vague idea that we haven't filed one yet?

lemon-spoon-91807

07/14/2018, 4:04 PM

i believe the latter

lemon-spoon-91807

07/14/2018, 4:04 PM

especially not at the pulumi-aws-serverless

lemon-spoon-91807

07/14/2018, 4:05 PM

it would make the most sense a the pulumi-cloud level, where the goal is to provide a more pleasant overall abstraction over these sorts of resources

big-piano-35669

07/14/2018, 4:05 PM

I will file in pulumi-aws for now, since it's not obvious where we'd add these. I do think as simple overlays they would work fine and, since it's the AWS SDK itself, it's less "opinionated" than many other layers like the cloud framework.

lemon-spoon-91807

07/14/2018, 4:06 PM

our examples to try to demonstrate this pattern. so, 'pulumi' for resource creation/organization, and aws-adk for interaction with broad surface area of AWS.

big-piano-35669

07/14/2018, 4:06 PM

Right, it's just so much nicer if the actual

sqs.Queue

type "just works" out of the box.

lemon-spoon-91807

07/14/2018, 4:07 PM

yes. i can definitely see the appeal

lemon-spoon-91807

07/14/2018, 4:07 PM

my concerns (not having looked too deeply into aws-sdk) would be:

lemon-spoon-91807

07/14/2018, 4:08 PM

1. how broad is this API. i.e. would basically every resource type get a large set of additional abstractions to support

lemon-spoon-91807

07/14/2018, 4:08 PM

2. how maintainable would that be. would we always have to be keeping these up to date with the aws sdk on top of everything else.

lemon-spoon-91807

07/14/2018, 4:09 PM

on the other hand, this is just code, and just JS. so part of me really likes the idea of having another library you can import. and it would just augment these libraries with the desired changes

lemon-spoon-91807

07/14/2018, 4:10 PM

this is not an uncommon pattern in the JS world.

lemon-spoon-91807

07/14/2018, 4:14 PM

i'll discuss this a bit with @white-balloon-205 this week. it actually ties into our design thoughts on 'serverless'. i.e. why have

serverless.sqs.onQueueEvent(queue, () => ...)

if you could just have the serverless package augment Queue itself so you could write:

queue.onEvent(() => ...)

big-piano-35669

07/14/2018, 4:31 PM

I definitely agree with the concerns and I'll admit, until just recently, I had always assumed we'd do this as a separate library. At this point I think it's a low risk add and that stuff like this should "just work", especially as it highlights the unique "it's just code" aspects of Pulumi. I filed https://github.com/pulumi/pulumi-aws/issues/271 -- let's move discussion there so it's not lost to the Slack sands of time 🙂

stocky-spoon-28903

07/14/2018, 4:34 PM

I think having a separate library for this is fine. The critical part (as compared to the AWS SDK for example) is that it can be made to work with the existing provider configuration IMO

Open in Slack

Previous Next

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.