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

Binary release and Devnet deployment #2005

Open
mishmosh opened this Issue Feb 16, 2019 · 13 comments

Comments

Projects
None yet
7 participants
@mishmosh
Copy link
Contributor

mishmosh commented Feb 16, 2019

Description

Upgrade our binary release and Devnet deploy process so that it is scrumptious, easy-to-do, and nice-to-consume. Here's a rough idea, but owner(s) should come up with a specific proposal:

  • tag a given commit
  • generates build artifacts as part of Github release
  • triggers User Devnet deploy, making the Devnet continually deployed (CD)

Acceptance criteria

  • A user can go to a fixed URL, and find a link to download a binary release (choosing Mac or Linux) that is based on a commit we choose (rather than the latest master branch).
  • The binary includes everything they need to run go-filecoin, including an archive of the paired rust-fil-proofs parameters so they don't need to generate them.
  • Ensure go-filecoin statically links libfilecoin_proofs (via @laser)
  • Ensure the User Devnet is deployed to the same binary version as the "latest" Github release, to ensure version compatibility and the integrity of data schema within the User Devnet

Risks + pitfalls

Protocol Changes

Where to begin

@mishmosh mishmosh added the Epic label Feb 16, 2019

@dignifiedquire

This comment has been minimized.

Copy link
Contributor

dignifiedquire commented Feb 19, 2019

@phritz phritz added the A-build label Feb 19, 2019

@gmasgras

This comment has been minimized.

Copy link
Contributor

gmasgras commented Feb 19, 2019

There is already a release process for go-filecoin that gets triggered whenever a commit gets tagged with something that matches x.x.x (where x is a positive integer).

This results in the creation of a GitHub release (see 0.0.1 at https://github.com/filecoin-project/go-filecoin/releases) with archives for Linux and OSX. These archives are made up of the platform-specific binary go-filecoin and a fixtures directory containing gengen related files, keys files, genesis.car (do these still need to be included in the release ? )

The things missing from the releases are rust-proofs params v9-zigzag-proof-of-replication-*. We could add these files in a subdirectory e.g. proofs-params and provide instructions on how to instruct go-filecoin of their location

@anorth

This comment has been minimized.

Copy link
Contributor

anorth commented Feb 20, 2019

If proof params are downloaded, rather than generated, that process should still be called out in the wiki (e.g. see #2008). Especially if they go to /tmp which is prone to garbage collection.

If this applies to source builds too, the README comment added in #2033 should be removed.

@travisperson

This comment has been minimized.

Copy link
Member

travisperson commented Feb 20, 2019

I did a little bit of investigation to try and determine what was required to connect to the user devent. I'm fairly certain at this point that the only files required are go-filecoin itself and the v9-zigzag-proof-of-replication-52....d8 params.

I built the go-filecoin binary from the devnet-user tag using go run build/*.go deps; go run build/*.go build. I then copied the go-filecoin binary to two fresh Ubuntu 18.04 systems. I took the IPFS hash for v9-zigzag-proof-of-replication-52....d8 from proofs/rust-proofs/parameters.json, and downloaded it to /tmp/filecoin-proof-parameters/params.out.

From there I was able to initialize and connect to the user devnet and sync the entire chain. I was also able to create a miner, propose a deal with the miner, and retrieve the data back.

I also observed rust-proof logs in the daemon output

Feb 20 03:53:22.576 INFO reading groth params from cache: "/tmp/filecoin-proof-parameters/params.out", target: params, place: storage-proofs/src/parameter_cache.rs:126 storage_proofs::parameter_cache, root: storage-proofs                                                                                                                                                              
Feb 20 03:53:51.302 INFO groth_parameter_bytes: 1670980536, target: stats, place: storage-proofs/src/parameter_cache.rs:131 storage_proofs::parameter_cache, root: storage-proofs  
Feb 20 07:37:11.684 INFO encoding, layer {}: 0, place: storage-proofs/src/layered_drgporep.rs:398 storage_proofs::layered_drgporep, root: storage-proofs
Feb 20 07:57:50.758 INFO returning tree, layer: 3, place: storage-proofs/src/layered_drgporep.rs:391 storage_proofs::layered_drgporep, root: storage-proofs

So it doesn't look like we need anything other than go-filecoin, and a way to fetch the params (paramfetch).

@phritz

This comment has been minimized.

Copy link
Contributor

phritz commented Feb 20, 2019

in addition to the issues noted above see also #1899 (comment). also cc @laser and @sidke who in https://filecoinproject.slack.com/archives/CEHHJNJS3/p1550600412442100 i have asked to provide a description of the rust proofs and params build process, as well as how any artifacts are used at runtime. i think this kind of description is appropriate for https://github.com/filecoin-project/go-filecoin/blob/master/CODEWALK.md as a single place that describes how gfc works.

anyhoo, i think the scope of this issue is brain dump and especially identifying requirements/goals. to that end here are a few things:

  • mosh has some good acceptance criteria above: 1 fixed url with mac and linux packages built at commits of our choice and 2 works in minutes, not tens of minutes ie dont generate params.
  • i'm not sure i understand her third criteria from laser staticialy linking the proofs library, is there some reason we need it?
  • primary goal: enable brave technical users to get started quickly using filecoin by downloading pre built binaries for mac and linux
  • also goals:
    • have this all working sufficiently smoothly that we use it for our next release, in 4-5ish weeks
    • avoid spofs
    • support arbitrary release cadence
    • be extensible for future improvements, eg pinning in ipfs on release, creating a changelog, maintainers signing artifacts, etc
    • automate automate automate: zero manual steps and maintenance
  • non-goals:
    • do exactly what ipfs does. there might or might not be some things to clone but we should do the thing that makes the most sense for us.
    • solve all the security problems we will need to eg maintainers signing. we dont need them yet
  • questions/thoughts:
    • should be easy to check what version is the latest eg so gfc can show a 'your code is outdated, please upgrade' message
    • accpetance criteria:
      • should be a short designdoc capturing how this works so that it is not a mystery, ideally we keep it up to date
      • should we have a test that verifies that the binary package actually works with the devnet and if so how?
    • since we dont have a model for change the binary releases should correspond to user devnet releases. this precipitates the question: should we have separate binaries/packages for nightly and user dev net? or do you just build from source for nightly? seems like we probably want pre built binaries for both, if for no other reason than to ensure that we can continue to build
    • there is presently no indication of the correlation between a gh release and the devnet it is for. we will need some indication if we have different binaries for different devnets.
    • i think we should NOT worry about rollback at this point. our strategy is to roll forward.
  • now that i'm thinking about it i'm feeling pretty strongly that the nightly should work exactly like the user devnet release, it just has a different name and happens more frequently. this will ensure that we catch any release affecting changes early, and releasing a new user devent and its binaries could be as simple and low risk as picking the last nightly and re-tagging it to release to user devnet.
@gmasgras

This comment has been minimized.

Copy link
Contributor

gmasgras commented Feb 20, 2019

  • there is presently no indication of the correlation between a gh release and the devnet it is for. we will need some indication if we have different binaries for different devnets.

As you mentioned above, a release tag x.x.x (which creates a GH release) will point at the same commit as devnet-user (which triggers a redeploy)

I agree that it would be nice to have binaries for nightly, we could create a nightly pre-release that gets overwritten every time the nightly devnet gets redeployed.

@laser

This comment has been minimized.

Copy link
Contributor

laser commented Feb 20, 2019

@phritz

  • i'm not sure i understand her third criteria from laser staticialy linking the proofs library, is there some reason we need it?

libfilecoin_proofs is the library used by go-filecoin when generating and verifying proofs.

We want this library baked into the go-filecoin binary (static linking).

We do not want to dynamically link libfilecoin_proofs into go-filecoin.

Dynamic linking of libfilecoin_proofs into go-filecoin would require us to distribute libfilecoin_proofs along with the go-filecoin binary. It would also require that we provide tooling to ensure that libfilecoin_proofs was moved to a place where go-filecoin could find it.

@phritz

This comment has been minimized.

Copy link
Contributor

phritz commented Feb 20, 2019

thanks @laser . i get that we want static linking. but whether that is a goal of this effort in the next month i think is a cost/benefit analysis. i dont think i have a good sense of how much work it is. i do think i have a good sense of what the benefit is.

@laser

This comment has been minimized.

Copy link
Contributor

laser commented Feb 20, 2019

@phritz

but whether that is a goal of this effort in the next month i think is a cost/benefit analysis.

Makes sense to me. Thanks for clarifying. I also do not have a good sense for how much work it is.

@gmasgras

This comment has been minimized.

Copy link
Contributor

gmasgras commented Feb 20, 2019

thanks @laser . i get that we want static linking. but whether that is a goal of this effort in the next month i think is a cost/benefit analysis. i dont think i have a good sense of how much work it is. i do think i have a good sense of what the benefit is.

Isn't libfilecoin-proofs already statically linked in the go-filecoin binary ? I'm pretty sure that there is no dynamic filecoin-proofs library in the docker image that's running on the usernet

@laser

This comment has been minimized.

Copy link
Contributor

laser commented Feb 20, 2019

already statically linked in the go-filecoin binary

It is possible that the go-filecoin binary produced when building in the Docker Linux environment does in fact statically link in libfilecoin_proofs.

I do not know if the go-filecoin binary built in non-Docker, non-Linux environments statically links libfilecoin_proofs.

@gmasgras

This comment has been minimized.

Copy link
Contributor

gmasgras commented Feb 20, 2019

already statically linked in the go-filecoin binary

It is possible that the go-filecoin binary produced when building in the Docker Linux environment does in fact statically link in libfilecoin_proofs.

I do not know if the go-filecoin binary built in non-Docker, non-Linux environments statically links libfilecoin_proofs.

The docker build executes almost the same build commands as the linux build, the exception being smartdeps in linux vs deps in Docker

https://github.com/filecoin-project/go-filecoin/blob/master/Dockerfile#L18-L19
https://github.com/filecoin-project/go-filecoin/blob/master/.circleci/config.yml#L171
https://github.com/filecoin-project/go-filecoin/blob/master/.circleci/config.yml#L202

OSX runs the same steps as Linux:
https://github.com/filecoin-project/go-filecoin/blob/master/.circleci/config.yml#L63
https://github.com/filecoin-project/go-filecoin/blob/master/.circleci/config.yml#L83

@travisperson

This comment has been minimized.

Copy link
Member

travisperson commented Feb 20, 2019

I agree the static linking is not something we should care about in this issue, but I do believe it is already being done regardless. I think this can all fit under point 2. We will include all required files (except params directly)

#2005 (comment)

@ognots ognots changed the title Binary release Binary release and Devnet Deploy Mar 5, 2019

@ognots ognots changed the title Binary release and Devnet Deploy Binary release and Devnet deployment Mar 5, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.