Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

create installer event for tracking provider lock hashes #31406

Conversation

liamcervante
Copy link
Member

This is an attempt to implement @apparentlymart's suggestion in #31399.

I can merge this back into the original PR if we like it.

I also noticed HashPackageFailure was not in use so removed it.

Copy link
Member

@apparentlymart apparentlymart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great! I think this strikes a nicer compromise of being a bit more certain about the advice we're generating in this warning.

I have some little notes inline just about naming where things didn't resonate with my mental model while I was reading. Naming is subjective of course, so feel free to disagree with my suggestions!

// It not just likely, but expected that there will be duplicates shared
// between all three collections of hashes i.e. the local hash and remote
// hashes could already be in the cached hashes.
ProvidersLockUpdated func(provider addrs.Provider, version getproviders.Version, local getproviders.Hash, remote []getproviders.Hash, cached []getproviders.Hash)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like a reasonable design for this installer event indeed, though it did take me a little "squinting" to get my head around what each of these arguments means, so I have some suggestions for other names that I think would resonate better with me at least, based on my model of how the protocol behaves:

  • localHashes: hashes computed on the local system by analyzing files on disk. It is true that right now there can be only one, but the system was designed to support adding new hashing schemes in future and so I'd prefer to keep this plural just so the system design is consistent about that so it's clearer to a future maintainer how they might plug in a hypothetical h2: scheme while retaining the h1: scheme. (YAGNI perhaps, but with other parts of this already designed around this possibility I'd like to keep things consistent so we'll have an easier time evolving this design in future.)
  • signedHashes: hashes that were signed by the private key that the origin registry claims is the owner of this provider. (Note: "origin registry" is the term we use to refer to the registry whose hostname is embedded in the provider source address, so e.g. registry.terraform.io/hashicorp/aws has registry.terraform.io as its "origin registry".)
  • priorHashes: hashes that were already present in the lock file before we made any changes. "prior" instead of "cached" I don't really have any strong argument for other than that "cached" makes me think of the provider plugin cache just due to the overlapping noun, and so "prior" hopefully avoids that false cognate.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we could document a guarantee here that these sets of hashes will always be presented in the same arbitrary-but-consistent order we use within the serialized lock file, so we can get the same ease-of-testing and ease-of-comparison benefits we get from there.

(This does seem to be asking for a "set of hashes" data type, rather than using a sorted slice by convention only, but I'm expecting the stdlib will get a "set of T" type before too long now that we have generic type support in the language so seems reasonable to hold on until we're ready to use the stdlib one, rather than writing yet another Terraform-specific set type -- of which we already have quite a few! 😬 )

@liamcervante liamcervante merged commit 2695db4 into liamcervante/init-provider-checksums Jul 12, 2022
@liamcervante liamcervante deleted the liamcervante/init-provider-checksums-ext branch July 12, 2022 10:37
@github-actions
Copy link

Reminder for the merging maintainer: if this is a user-visible change, please update the changelog on the appropriate release branch.

liamcervante added a commit that referenced this pull request Jul 20, 2022
…#31399)

* terraform init: add warning and guidance when lock file is incomplete

* make the provider list in the warning deterministic

* create installer event for tracking provider lock hashes (#31406)

* create installer event for tracking provider lock hashes

* address comments

* fix tests

* improve error message

* Update internal/command/init.go

Co-authored-by: Martin Atkins <mart@degeneration.co.uk>

Co-authored-by: Martin Atkins <mart@degeneration.co.uk>
@github-actions
Copy link

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 12, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants