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

FAB-17160 Ensure peer can be started without any docker requirements #384

Merged
merged 1 commit into from
Dec 12, 2019

Conversation

wlahti
Copy link
Contributor

@wlahti wlahti commented Dec 9, 2019

With the introduction of external builders for chaincode, docker is no longer required. This PR
ensures that a peer can be started with an external builder/launcher for chaincode and zero docker requirements.

Signed-off-by: Will Lahti wtlahti@us.ibm.com

internal/peer/node/start.go Outdated Show resolved Hide resolved
internal/peer/node/start.go Outdated Show resolved Hide resolved
if err != nil {
logger.Panicf("cannot create docker client: %s", err)

if coreConfig.VMEndpoint != "" {
Copy link
Contributor

Choose a reason for hiding this comment

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

shouldn't we also add a check for coreConfig.ExternalBuilders[] being empty ... we need either a VMEndpoint or a list of ExternalBuilders

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 at the very least we should print a warning indicating that the peer will not be able to execute chaincode.

I suppose it's possible that someone simply wants to stand up a peer to pull and validate blocks, though without a chaincode to access state, I don't see any real usefulness for this configuration.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

Copy link
Member

Choose a reason for hiding this comment

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

@jyellick one use case could be to construct state db for direct query against it?

Copy link
Contributor

Choose a reason for hiding this comment

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

It's easy enough to create a no-op external builder -- for instance:

mkdir -p mybuilder/bin
ln -s /bin/false mybuilder/bin/detect

Now you have a functioning external builder that will never build anything, and you can successfully make your peer start. If we find lots of users needing to do a workaround like this, we can look into relaxing the check, but we can always relax checks, but adding constraints later is hard.

@denyeart
Copy link
Contributor

Remember to add commit message and use PR template.

internal/peer/node/start.go Show resolved Hide resolved
@wlahti
Copy link
Contributor Author

wlahti commented Dec 11, 2019

/ci-run

@github-actions
Copy link

AZP build triggered!

jyellick
jyellick previously approved these changes Dec 11, 2019
@wlahti
Copy link
Contributor Author

wlahti commented Dec 11, 2019

/ci-run

@github-actions
Copy link

AZP build triggered!

Signed-off-by: Will Lahti <wtlahti@us.ibm.com>
Copy link
Member

@guoger guoger left a comment

Choose a reason for hiding this comment

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

LGTM

@jyellick jyellick dismissed mastersingh24’s stale review December 12, 2019 02:56

I believe this has been addressed. The peer now panics if there are no externalbuilders nor a docker daemon available.

@jyellick jyellick merged commit c3a3723 into hyperledger:master Dec 12, 2019
@wlahti wlahti deleted the FAB-17160 branch December 12, 2019 20:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants