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

fix(tools): fabric all-in-one fabric-samples v2.2.0 breaking change #632

Closed
petermetz opened this issue Mar 5, 2021 · 0 comments · Fixed by #646
Closed

fix(tools): fabric all-in-one fabric-samples v2.2.0 breaking change #632

petermetz opened this issue Mar 5, 2021 · 0 comments · Fixed by #646
Assignees
Labels
bug Something isn't working

Comments

@petermetz
Copy link
Contributor

Describe the bug

Either I'm losing it or the Fabric Samples repo has their release tags changed from before and this has broken our AIO 2.x image where we made the assumption that locking to a specific git tag (via the bootstrap script) would guarantee that our builds are reproducible and stable.

Exhibit #1: https://github.com/hyperledger/fabric-samples/releases

  1. The different releases appear to have been made on the same day in January this year which would imply that they were changed after the fact.
  2. The 2.2.0 release of Fabric Samples (that we started locking our image to on the 16th of December 2020 in our PR feat(fabric): user defined fabric samples version #403) appears as if it was issued on January 19th 2021 which should not be possible without time traveling (2020 was a particularly sinister year so malicious time traveling robots is not beyond the realm possibilities at all either)
  3. Multiple release tags are actually all identify the same commit hash as the underlying revision of theirs.

To Reproduce

Build the Fabric AIO image locally, try to run it and observe that the health check is failing, forever.

Expected behavior

Build the Fabric AIO image locally, try to run it and observe that the health check is not failing.

Logs/Stack traces

Can help maintainers identify root causes

Screenshots

Healthcheck output from docker:

"Health": {
      "Status": "unhealthy",
      "FailingStreak": 2812,
      "Log": [
        {
          "Start": "2021-03-04T19:38:23.020430266-08:00",
          "End": "2021-03-04T19:38:23.190027948-08:00",
          "ExitCode": 1,
          "Output": "2.2.0\nError: endorsement failure during query. response: status:500 message:\"error in simulation: failed to execute transaction 75180da6905cc0d554f7ab340a8647733d1f34ed649feb02170c19b5415787b3: invalid invocation: chaincode 'fabcar' has not been initialized for this version, must call as init first\" \n"
        },
        {
          "Start": "2021-03-04T19:38:24.193786418-08:00",
          "End": "2021-03-04T19:38:24.339522509-08:00",
          "ExitCode": 1,
          "Output": "2.2.0\nError: endorsement failure during query. response: status:500 message:\"error in simulation: failed to execute transaction 217da5a7af414699699eb16ff3eeb7a3817617dcd351e1689177fa7289211ce4: invalid invocation: chaincode 'fabcar' has not been initialized for this version, must call as init first\" \n"
        },
        {
          "Start": "2021-03-04T19:38:25.347753087-08:00",
          "End": "2021-03-04T19:38:25.47330272-08:00",
          "ExitCode": 1,
          "Output": "2.2.0\nError: endorsement failure during query. response: status:500 message:\"error in simulation: failed to execute transaction 93d66d0ef6b4f836b8664e52043d434ec706c954edf53a77c5d60f83038025b1: invalid invocation: chaincode 'fabcar' has not been initialized for this version, must call as init first\" \n"
        },
        {
          "Start": "2021-03-04T19:38:26.476701264-08:00",
          "End": "2021-03-04T19:38:26.625673703-08:00",
          "ExitCode": 1,
          "Output": "2.2.0\nError: endorsement failure during query. response: status:500 message:\"error in simulation: failed to execute transaction fcedd1272b5ca7f02ec3f75552f7fa0ef9a3cd8441c4af2e82ce97ec2fbd44db: invalid invocation: chaincode 'fabcar' has not been initialized for this version, must call as init first\" \n"
        },
        {
          "Start": "2021-03-04T19:38:27.629681092-08:00",
          "End": "2021-03-04T19:38:27.763080358-08:00",
          "ExitCode": 1,
          "Output": "2.2.0\nError: endorsement failure during query. response: status:500 message:\"error in simulation: failed to execute transaction 2b96d919e14ea18c21063ea4ce8cac71debbe1443488079c93020dbfd04208b3: invalid invocation: chaincode 'fabcar' has not been initialized for this version, must call as init first\" \n"
        }
      ]
    }

Cloud provider or hardware configuration:

Dev machine

Operating system name, version, build:

Linux 5.4.0-54-generic x86_64
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

Hyperledger Cactus release version or commit (git rev-parse --short HEAD):

main

Hyperledger Cactus Plugins/Connectors Used

fabric

Additional context

Discovered this while working on the SSH connection issue of the Fabric AIO image.

cc: @takeutak @sfuji822 @hartm @jonathan-m-hamilton @AzaharaC @jordigiam @kikoncuo

@petermetz petermetz added the bug Something isn't working label Mar 5, 2021
@petermetz petermetz self-assigned this Mar 5, 2021
petermetz added a commit to petermetz/cacti that referenced this issue Mar 9, 2021
…ger-cacti#632

Primary change
============

Not sure how exactly, but the rug got pulled from under our
image build despite it specifying all tags/versions for fabric
explicitly. Suspicion right now is that the release tags were force
pushed to something new which no longer supported the fabcar
example chaincode that we were depending on.
Evidence to the above is also that our old image works just fine
that was built back in December 2020 (who knew 2020 was
going to be the year we depend on for stability...)

The fix itself: Migrated over the image to be compatible with
the 2.x fabric-samples code which meant no more fabcar
instead of which we now have the basic asset transfer
chaincode that gets deployed by default and then also serves
as the backbone for the healthchecks.

Secondary/misc. changes
====================

Updated the README.md file of the fabric AIO image to
state that it's using fabric-samples interanlly instead of
a hand-rolled deployment (which is what we had in the
very early phases of the Fabric AIO, but that's long gone
by now so the README update was badly needed)

Updated the example build commands to use DOCKER_BUILDKIT=1
where applicable because it is much faster
than the old builder so people should probably
use it.

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to petermetz/cacti that referenced this issue Mar 10, 2021
…ger-cacti#632

Primary change
============

Not sure how exactly, but the rug got pulled from under our
image build despite it specifying all tags/versions for fabric
explicitly. Suspicion right now is that the release tags were force
pushed to something new which no longer supported the fabcar
example chaincode that we were depending on.
Evidence to the above is also that our old image works just fine
that was built back in December 2020 (who knew 2020 was
going to be the year we depend on for stability...)

The fix itself: Migrated over the image to be compatible with
the 2.x fabric-samples code which meant no more fabcar
instead of which we now have the basic asset transfer
chaincode that gets deployed by default and then also serves
as the backbone for the healthchecks.

Secondary/misc. changes
====================

Updated the README.md file of the fabric AIO image to
state that it's using fabric-samples interanlly instead of
a hand-rolled deployment (which is what we had in the
very early phases of the Fabric AIO, but that's long gone
by now so the README update was badly needed)

Updated the example build commands to use DOCKER_BUILDKIT=1
where applicable because it is much faster
than the old builder so people should probably
use it.

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to petermetz/cacti that referenced this issue Mar 10, 2021
…ger-cacti#632

Primary change
============

Not sure how exactly, but the rug got pulled from under our
image build despite it specifying all tags/versions for fabric
explicitly. Suspicion right now is that the release tags were force
pushed to something new which no longer supported the fabcar
example chaincode that we were depending on.
Evidence to the above is also that our old image works just fine
that was built back in December 2020 (who knew 2020 was
going to be the year we depend on for stability...)

The fix itself: Migrated over the image to be compatible with
the 2.x fabric-samples code which meant no more fabcar
instead of which we now have the basic asset transfer
chaincode that gets deployed by default and then also serves
as the backbone for the healthchecks.

Secondary/misc. changes
====================

Updated the README.md file of the fabric AIO image to
state that it's using fabric-samples interanlly instead of
a hand-rolled deployment (which is what we had in the
very early phases of the Fabric AIO, but that's long gone
by now so the README update was badly needed)

Updated the example build commands to use DOCKER_BUILDKIT=1
where applicable because it is much faster
than the old builder so people should probably
use it.

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit that referenced this issue Mar 11, 2021
Primary change
============

Not sure how exactly, but the rug got pulled from under our
image build despite it specifying all tags/versions for fabric
explicitly. Suspicion right now is that the release tags were force
pushed to something new which no longer supported the fabcar
example chaincode that we were depending on.
Evidence to the above is also that our old image works just fine
that was built back in December 2020 (who knew 2020 was
going to be the year we depend on for stability...)

The fix itself: Migrated over the image to be compatible with
the 2.x fabric-samples code which meant no more fabcar
instead of which we now have the basic asset transfer
chaincode that gets deployed by default and then also serves
as the backbone for the healthchecks.

Secondary/misc. changes
====================

Updated the README.md file of the fabric AIO image to
state that it's using fabric-samples interanlly instead of
a hand-rolled deployment (which is what we had in the
very early phases of the Fabric AIO, but that's long gone
by now so the README update was badly needed)

Updated the example build commands to use DOCKER_BUILDKIT=1
where applicable because it is much faster
than the old builder so people should probably
use it.

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
AzaharaC pushed a commit to kikoncuo/cactus that referenced this issue Mar 12, 2021
…ger-cacti#632

Primary change
============

Not sure how exactly, but the rug got pulled from under our
image build despite it specifying all tags/versions for fabric
explicitly. Suspicion right now is that the release tags were force
pushed to something new which no longer supported the fabcar
example chaincode that we were depending on.
Evidence to the above is also that our old image works just fine
that was built back in December 2020 (who knew 2020 was
going to be the year we depend on for stability...)

The fix itself: Migrated over the image to be compatible with
the 2.x fabric-samples code which meant no more fabcar
instead of which we now have the basic asset transfer
chaincode that gets deployed by default and then also serves
as the backbone for the healthchecks.

Secondary/misc. changes
====================

Updated the README.md file of the fabric AIO image to
state that it's using fabric-samples interanlly instead of
a hand-rolled deployment (which is what we had in the
very early phases of the Fabric AIO, but that's long gone
by now so the README update was badly needed)

Updated the example build commands to use DOCKER_BUILDKIT=1
where applicable because it is much faster
than the old builder so people should probably
use it.

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
jordigiam pushed a commit to kikoncuo/cactus that referenced this issue Apr 8, 2021
…ger-cacti#632

Primary change
============

Not sure how exactly, but the rug got pulled from under our
image build despite it specifying all tags/versions for fabric
explicitly. Suspicion right now is that the release tags were force
pushed to something new which no longer supported the fabcar
example chaincode that we were depending on.
Evidence to the above is also that our old image works just fine
that was built back in December 2020 (who knew 2020 was
going to be the year we depend on for stability...)

The fix itself: Migrated over the image to be compatible with
the 2.x fabric-samples code which meant no more fabcar
instead of which we now have the basic asset transfer
chaincode that gets deployed by default and then also serves
as the backbone for the healthchecks.

Secondary/misc. changes
====================

Updated the README.md file of the fabric AIO image to
state that it's using fabric-samples interanlly instead of
a hand-rolled deployment (which is what we had in the
very early phases of the Fabric AIO, but that's long gone
by now so the README update was badly needed)

Updated the example build commands to use DOCKER_BUILDKIT=1
where applicable because it is much faster
than the old builder so people should probably
use it.

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant