Channels
pulumi-ai
package-authoring
pulumi-cdk
oracle-cloud-infrastructure
learn-pulumi-events
linen
registry
built-with-pulumi
pulumi-cloud
contribex
testingtesting321
hacktoberfest
cloudengineering
yaml
pulumi-crosscode
content-share
finops
multi-language-hackathon
office-hours
workshops
blog-posts
localstack
welcome
gitlab
pulumi-kubernetes-operator
jobs
aws
pulumi-deployments
dotnet
golang
announcements
java
pulumiverse
python
install
getting-started
cloudengineering-support
testingtesting123
hackathon-03-19-2020
typescript
google-cloud
contribute
azure
kubernetes
docs
automation-api
status
general
Title
t
tall-needle-56640
12/07/2020, 6:44 PMThe new versioning namespaces create a lot of (what I feel is) unnecessary noise. Also, I can find no precedent for this kind of organization as even the official Azure SDK doesn't do anything like this. I realize that it opens up some interesting scenarios, but it also makes a lot of normal scenarios more challenging.
Example 1: Someone want to create a library for setting smart defaults (think reset.css). In
Pulumi.Azurepublic class ResourceFactory
{
public Account StorageAccount(string name, AccountArgs? args = null)
{
args ??= new AccountArgs();
args.ResourceGroupName = _resourceGroupName;
args.Location ??= _locationInput;
args.AccountKind ??= "StorageV2";
args.AccountReplicationType ??= "LRS";
args.AccountTier ??= "Standard";
return new Account(name, args);
}
}Pulumi.AzureNextGent
tall-librarian-49374
12/07/2020, 7:04 PMYeah, that’s a trade-off to make.
1. Azure Go SDK does that.
2. arm2pulumi would be really challenging without multiple versions.
3. “Latest” is quite often a lemon as Azure rolls out new versions. We’d have to manually pick “the best version”.
4. We’d also have to force upgrades on everyone as we make those decisions, which creates friction.
High-level libraries likely need to pick a version for each resource and stick with it for a while.
t
tall-needle-56640
12/07/2020, 8:28 PM@tall-librarian-49374 What do you think of this?
Packages:
Packages are broken up, like the below. Note that non-version-named packages like The major version of "latest" packages updates with each API version change. Using the above
v1.0.0 contains latest (which would be V20200601)
v1.x.x contains minor/patch changes to the API
v2.0.0 contains the next API release (i.e. V20210601)
...
Developers should understand SemVer and thus realize that major version changes could mean breaking changes.
For
Pulumi.AzureNextGen.WebPulumi.AzureNextGen.WebPulumi.AzureNextGen.Web.V20180201.Latestt
tall-librarian-49374
12/07/2020, 8:48 PMWhat is the benefit of two naming convensions used in parallel (v1.0.0 and V20180201)? Why is semver easier to use?
t
tall-needle-56640
12/07/2020, 9:23 PM1.0.01.0.02018020120180201I don't know if SemVer is "easier", but with SemVer, developers know that a new major version number means that there may be breaking changes. So if
Web.LatestV20200601Web.LatestV20210601e
early-sugar-1496
12/08/2020, 12:04 AMAzure-nextgen resources follow the same versioning as the actual azure apis. If the provider were to use semver for the resources instead of, for example, V20200601, pulumi would then be making the decision across the entire azure api surface on what is a breaking change. That decision should be made by the azure team responsible for that api, not pulumi
As a user of the provider, my only confusion is when a resource only exists in latest and not in a dated namespace but I'm not sure if that's a provider bug
t
tall-needle-56640
12/08/2020, 1:13 AMI don't care if the major version numbers are 1, 2, 3. That was one suggestion and can be ignored. But the major version number should be changed whenever the Azure team puts out a new API version.
20200601t
tall-librarian-49374
12/08/2020, 7:11 AM@early-sugar-1496
a resource only exists in latest and not in a dated namespaceCan you point me to an example? I’m relatively sure that’s not possible and happy to take a look.
@tall-needle-56640 There are cases when users need to use two versions of the same resource provider (namespace). This sounds impossible in the package-per-version model?
t
tall-needle-56640
12/08/2020, 3:07 PM@tall-librarian-49374 The package-per-version model would retain the version number in the namespace. I do think we should drop
Latestt
tall-librarian-49374
12/08/2020, 3:12 PMAh I see. So, mostly, everything is the same, just multiple packages.
I see how this makes
Users who just want to use the latest can easily do soa bit more straightforward but I’m not sure I see other benefits.
t
tall-needle-56640
12/08/2020, 3:29 PMIt also reduces noise and bloat. Why would I want a package that has X different versions, starting from 6 years ago, when I only want one or two of the most recent? It can slow down development as shown in this image. Visual Studio is trying to be helpful by finding namespaces that contain the type name. But it's recommending old versions, because there are just too many options. If I could pin the one or two versions, then it would recommend to me what I actually want.
t
tall-librarian-49374
12/08/2020, 3:32 PMMakes sense. I wonder if that outweighs the process of discovery of all the NuGet packages that one wants to bring in.
t
tall-needle-56640
12/08/2020, 4:23 PMYou could always set the meta-package as the default, but searching "Pulumi" in a package feed is pretty easy.