jaypipes / ghw

Go HardWare discovery/inspection library
Apache License 2.0
1.62k stars 174 forks source link

bring in github.com/jaypipes/pcidb@v1.0.0 #311

Closed jaypipes closed 2 years ago

jaypipes commented 2 years ago

I cut a new release of the pcidb library (v1.0.0) to address a particular issue (jaypipes/pcidb#28) that was causing pain for the maintainers of the PCI-IDS database. This PR simply brings in that latest patched version of pcidb, which includes disabling by default the network fetch of the PCI-IDS database when no local database file is found.

Signed-off-by: Jay Pipes jaypipes@gmail.com

ffromani commented 2 years ago

I'll check all the CIs of the projects I know they consume ghw and make sure they move to the up to date ghw (or at very least pcidb) ASAP, or if this is not possible provide mitigations to avoid https://github.com/jaypipes/pcidb/issues/28

ffromani commented 2 years ago

gh actions outage: https://www.githubstatus.com/incidents/y5hdmv0p49x3 monitoring and merging once CI runs and passes.

taigrr commented 2 years ago

@jaypipes can you cut a new release of this so libraries can bring the changes in?

ffromani commented 2 years ago

In some projects it could be simpler to just update the pcidb dependency. Version 1.0.0 of pcidb is fully compatible with 0.6.0 except for the network fetch behaviour.

Example: https://github.com/k8stopologyawareschedwg/resource-topology-exporter/pull/102/commits/469e51e4ab916e2e66a59529a171fa45aefeaae7

disclosure: this project is consuming ghw + pcidb but is very unlikely to have contributed to the excessive request load, but as contributor I'm updating anyway because not hitting the network by default is a good behaviour per se.

jaypipes commented 2 years ago

@jaypipes can you cut a new release of this so libraries can bring the changes in?

yep, doing so now... sorry, there was something going on with Github Actions yesterday... also, I wanted to revert the iSCSI drive type change.

taigrr commented 2 years ago

@fromanirh that would work on more recent versions of go, but iirc some don't let you bring in a newer package in go.mod that you're not using expressly/as a direct dependency, if it's only a subdependency. Making sure at least one dependency is bringing in the new subdependency (assuming they're all the same major version, which they are) should work on all go versions.

Thanks jay!