https://pulumi.com logo
#azure
Title
# azure
t

tall-needle-56640

12/07/2020, 6:44 PM
The 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.Azure
 , this could be done by something like:
Copy code
public 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);
    }
}
But in order to do this with 
Pulumi.AzureNextGen
 , the developer now has to create an overload for every version? And even if they did, when a new API version was released, the library would be broken until the developer add additional overloads.
t

tall-librarian-49374

12/07/2020, 7:04 PM
Yeah, 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
Pulumi.AzureNextGen.Web
represent the latest stable releases, but drop the identifier since it should be obvious now (and ideally is dropped from the namespace as well). Pulumi.AzureNextGen.Web Pulumi.AzureNextGen.Web.V20180201 Pulumi.AzureNextGen.Web.V20200601 Pulumi.AzureNextGen.Storage Pulumi.AzureNextGen.Storage.V20190601 Pulumi.AzureNextGen.Storage.V20200801Preview Pulimi.AzureNextGen - Contains the latest packages - Pulumi.AzureNextGen.Storage - Pulumi.AzureNextGen.Web - ... Pulumi.AzureNextGen.All - Contains all old and new sub-packages - Pulumi.AzureNextGen.Web - Pulumi.AzureNextGen.Web.V20180201 - Pulumi.AzureNextGen.Web.V20200601 - Pulumi.AzureNextGen.Storage - Pulumi.AzureNextGen.Storage.V20190601 - Pulumi.AzureNextGen.Storage.V20200801Preview - ... Versioning: [Update] The major version of "latest" packages corresponds to the newest API version 20200601.0.0 20210601.0.0 The major version of "latest" packages updates with each API version change. Using the above
Pulumi.AzureNextGen.Web
as an example
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.Web.V20180201
, maybe continue to use the same versioning scheme in place. Results - Removing
.Latest
makes it much easier to migrate from Pulumi.Azure - Users who just want to use the latest can easily do so - Users are not blindly updated to a new version - Users who want to pin versions can easily do so - Users are not forced to upgrade - Old version-named packages do not need to be republished every time - arm2pulumi can continue as-is without any significant change
t

tall-librarian-49374

12/07/2020, 8:48 PM
What 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 PM
1.0.0
is not for naming, that is just a potential versioning scheme as
1.0.0
seems more digestible version than
20180201
. But having
20180201
as the major version number is fine too.
I 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.Latest
represents
V20200601
in some package version x.1, I would not expect
Web.Latest
to represent
V20210601
in version x.2. The APIs are (potentially) now incompatible. (On a side note, I thought SemVer was pretty industry standard.)
e

early-sugar-1496

12/08/2020, 12:04 AM
Azure-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 AM
I 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.
20200601
is fine as a major version number.
t

tall-librarian-49374

12/08/2020, 7:11 AM
@early-sugar-1496
a resource only exists in latest and not in a dated namespace
Can 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
Latest
from the namespace as it makes migration easier and seems unnecessary for a package that only represents the latest, but that's just my opinion. And ignoring that suggestion doesn't eliminate the other benefits.
t

tall-librarian-49374

12/08/2020, 3:12 PM
Ah 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 so
a bit more straightforward but I’m not sure I see other benefits.
t

tall-needle-56640

12/08/2020, 3:29 PM
It 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 PM
Makes 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 PM
You could always set the meta-package as the default, but searching "Pulumi" in a package feed is pretty easy.
3 Views