Feedback needed: local testing tools.

[hbj]

Hi everyone,

Coconut (https://github.com/getcoconut/coconut) is a new open source project that provides tools to make serverless development around the Pulumi Cloud Framework (https://github.com/pulumi/pulumi-cloud) more simple. It allows you to emulate infrastructure locally & develop without deciding on a cloud provider to get started.

Coconut is currently in alpha stage and we would like to validate the project idea and technical decisions. So if you are interested, please take a look, give it a try and respond to this short survey: https://forms.gle/deueNHSjiu4kFR9Y6.

Thanks a lot and happy coding!

@leezen perhaps you can take a look from the Pulumi team side? Your feedback would be very valuable.

[leezen]

@hbj Thanks for the pointer to the tool! I'll try to take a look either later this week or early next.

[hbj]

Cool, thanks!

[leezen]

I tried out the example and browsed the code a bit. This is great! It's definitely the case that having a local, non-AWS/Azure option for @pulumi/cloud makes a ton of sense. So what you're doing makes total sense. Also a great example of using Automation API to abstract away some of this to help the user get started quickly.

One thought I had while looking is it seems like when you 'mock' something, you create a new backend path each time, so there's no carryover of state from one invocation to the next. This makes sense in many contexts, but I also imagine there are scenarios where someone would want to actually try making an update and seeing what happens during the update (e.g. update the application code and make sure that the table update takes place with it so that things continue to work correctly) vs. being always in 'create' mode. I'm not sure if you've thought about those kinds of scenarios and it'd be neat to have that work as well.

Also, there's no way to do pulumi config set cloud:provider mock and have this work as "plain" Pulumi since the upstream module expects to load something of the form @pulumi/cloud-${provider} -- would be happy to take a PR to allow loading of other providers that conform to the pulumi/cloud interface such as coconut.

[hbj]

Thanks a lot for your feedback @leezen ! Very happy to see you find the idea useful, this motivates us to invest time and energy on it :)

The fact that a new backend is created every time is actually intentional, because the created services aren't persistent, like it's the case for the cloud. They are shut down when the Coconut command is interrupted. If we work with the normal Pulumi flow, i.e. the 'up' command, Pulumi would create all services in the first run, but in the next runs it would avoid creating those that didn't change and so they won't be available during those mock session.

Having this work as "plain" Pulumi didn't work in our tests, not only because of the naming convention of the provider package, but also because:

• the services that are creating listeners, like the HTTServer service, would block the Pulumi command which will never finish the update phase and won't show the outputs
• we want to do more after the services are created, e.g. write the outputs to some files that can be imported by client applications to access the backend services, so we need more control

In general, the 'mock' provider and the standard cloud providers have different objectives: the standard cloud providers handle the creation, update and deletion of services, and the cloud handles running those services, while the 'mock' provider actually runs the services locally. This is why the 'mock' provider needs to be handled differently.

Please let me know if anything is unclear and whether there are technical solutions to these points that we might be missing.