Add Neon provider

[kislerdm]

Description

Hello, Pulumi team! This PR adds the Neon provider package to the Pulumi Registry. The provider will enable users to provision Neon resources, e.g., project, database, branch etc. It's the initial release which only supports minimal functionality to provision the project resource.

Adding a new package?

If this pull request adds a new package:

• The package's schema URL in this PR is correct.
• The package metadata file, if present, contains:
  • a supported category (Database).
  • a valid plugin download URL. See Publish Your Package.
  • a description that explains what the package does.
  • a valid logo URL that points to a PNG whose dimensions conform to the others in this repo (e.g., 100x100).
• The package repo contains an Overview doc (/docs/_index.md) that includes:
  • a brief explanation of what the package is and what it does.
  • at least one representative example in all supported languages.
  • a front-matter property for the layout set to package.
• The package repo contains an Installation and Configuration doc (/docs/installation-configuration.md) that includes:
  • links to SDKs in all supported languages.
  • a copyable command for installing the resource plugin if necessary.
  • an example of configuring the provider with pulumi config set.
  • an example of configuring the provider with environment variables.
• The repository has:
  • a version tag prefixed with v that corresponds with a valid GitHub release and published package SDKs
• A CODEOWNER has reviewed the PR.
• A member of the @pulumi/docs team has reviewed all documentation.

[mjeffryes]

Thanks for your contribution @kislerdm! A couple notes/questions:

1. Is this an official effort of Neon? and if so who will be the primary maintainer contact? I noted a reference to them sponsoring the terraform provider.
2. We do require SDKs to be published in all the language package managers (npm, pypi, nuget) and working examples documented for each before we can publish to our registry.

[guineveresaenger]

Hi @kislerdm, thank you for opening this pull request!

Adding to @mjeffryes - please ensure you have both an installation-configuration.md as well as an _index.md file in your docs/ folder, at least until #6191 is implemented.

Please let us know if you need any assistance. 🙇‍♀️

[kislerdm]

@mjeffryes @guineveresaenger Hello! Thank you for your prompt replies.

Is this an official effort of Neon? and if so who will be the primary maintainer contact?

It's the community-driven provider with me as the main contact person.

I'm the author and core maintainer of the Neon terraform provider. Many Neon users and terraform community members indicated strong interest in Pulumi provider as well, so here we are 😀

We do require SDKs to be published in all the language package managers (npm, pypi, nuget) and working examples documented for each before we can publish to our registry.

Would it be possible for initial release to include SDKs only for the following technologies: typescript, python, go? The motivation: to cover the technologies with the most demand to acquire first feedback. Thanks for understanding!

please ensure you have both an installation-configuration.md as well as an _index.md file in your docs/ folder, at least until #6191 is implemented.

@guineveresaenger could you please advise: is it OK for both pages to have identical content? I noticed that it's the case for some providers, e.g., aivan. The motivation: get the initial release publish ASAP without overthinking basic documentation to gain adoption momentum and collect feedback.

Thank you for your help!

[guineveresaenger]

@kislerdm - we really truly just check for existence of each page, so either a placeholder or identical content is absolutely fine. 👍 Just don't want your docs to fail. :)

I notice that you've implemented a Pulumi native provider. Just in case you weren't aware, if a terraform provider already exists, it is also possible to "bridge" the existing terraform provider into a Pulumi provider using the Pulumi Terraform Bridge.
You'd want to look at https://github.com/pulumi/pulumi-tf-provider-boilerplate for the expected repo structure.
That way you get two providers but need to write features to only one of them.

[kislerdm]

@guineveresaenger thank you for the reply!

we really truly just check for existence of each page, so either a placeholder or identical content is absolutely fine. 👍 Just don't want your docs to fail. :)

Cool, I'll add the missing page to be identical with "_index.md" for now then.

I notice that you've implemented a Pulumi native provider. Just in case you weren't aware, if a terraform provider already exists, it is also possible to "bridge"...

I decided to develop a native provider to avoid coupling to the terraform provider to enable both communities for independent development. Would you recommend building Pulumi provider as a proxy to terraform provider instead? Could you maybe share pro/cons from your experience? Thanks!

[mjeffryes]

@kislerdm

I'm the author and core maintainer of the Neon terraform provider. Many Neon users and terraform community members indicated strong interest in Pulumi provider as well, so here we are 😀

That's great to hear!

Would it be possible for initial release to include SDKs only for the following technologies: typescript, python, go? The motivation: to cover the technologies with the most demand to acquire first feedback. Thanks for understanding!

Pulumi users will absolutely be able to use this provider without dotnet support, we just won't be able to list it in our registry until packages are available in all our core languages. (We realize this is a bit of a pain as a provider author; we're trying to figure out how we can make it less of a burden.)

[kislerdm]

Pulumi users will absolutely be able to use this provider without dotnet support, we just won't be able to list it in our registry until packages are available in all our core languages.

@mjeffryes thanks for clarification! I'll add the SDKs for missing languages and update the PR checklist once it's done.

[kislerdm]

@mjeffryes Unfortunately, there seem to be a blocker for dotnet, see the issue. I suspect that other provider developers may face it as well.

[t0yv0]

@kislerdm @mjeffryes unfortunately when .NET SDK generator picks names for SDK elements it may occasionally conflict (as is the case with pulumi/pulumi#17826 indeed). This is highly unfortunate indeed, but a comprehensive fix for this is very expensive. As the team maintaining providers we are able to work around these issues by customizing the names picked for SDK elements by hand to avoid the conflict. I've sketched out some notes in the attached issue.

Do you think a workaround can also be applicable to the neon provider or the specific details of Neon make it harder than what we have in 1826? If you could provide a few more specifics and a repro we could take a look 🙏

[kislerdm]

@t0yv0 @mjeffryes hey folks! The root cause in my case was the clash of namespaces which was causing the compiler's confusion:

// file Provider.cs

namespace Pulumi.Neon
{
    [NeonResourceType("pulumi:providers:neon")]
    public partial class Provider : global::Pulumi.ProviderResource
    {
// ...

The method Provider is clashing with the namespace Pulumi.Neon.Provider which contains the definition of the resources:

// file Provider/Project.cs
namespace Pulumi.Neon.Provider
{
// ...

My fix: to configure the ModuleMap property to swap Pulumi.Neon.Provider with Pulumi.Neon.Resource:

package provider

import (
    // ...
    "github.com/pulumi/pulumi/sdk/v3/go/common/tokens"
    // ...
)

// ...
ModuleMap: map[tokens.ModuleName]tokens.ModuleName{
	"provider": "resource",
},
// ...

WDYT?

[t0yv0]

I think this is very reasonable, Provider is indeed one of those essentially reserved keywords in Pulumi, so if you have a namespace called "provider" it makes sense to rename it to something else. Hope this works out end to end!