Skip to content

Conversation

nonsense
Copy link
Member

@nonsense nonsense commented Oct 27, 2021

This PR is integrating the new storagemarket.Provider into the boost service.

It also:

  1. Exports provider as we need to define it in the uber.Fx dependency injection app
  2. Remove reference to lotusNode, which is pointing to storageadapter.ProviderNodeAdapter, and use directly fullnodeApi, which is the Lotus Fullnode API.
  3. Bumps up Go to 1.17
  4. Fixes CircleCI config.yaml

TODO in follow up PRs:

  • copy over storageadapter.ProviderNodeAdapter from Lotus to Boost and uncomment all commented parts of storagemarket.Provider - we want this in order to unite all markets logic under the boost service roof.

@nonsense nonsense mentioned this pull request Oct 27, 2021
@nonsense nonsense force-pushed the nonsense/integrate-storage-provider branch 2 times, most recently from 4d96c6e to 6f745a9 Compare October 27, 2021 10:37
@nonsense nonsense force-pushed the nonsense/integrate-storage-provider branch from 6f745a9 to 8773bf3 Compare October 27, 2021 10:39
@nonsense nonsense marked this pull request as ready for review October 27, 2021 10:46
@nonsense nonsense force-pushed the nonsense/integrate-storage-provider branch from 254f442 to af8fb77 Compare October 27, 2021 13:08
@nonsense
Copy link
Member Author

nonsense commented Oct 27, 2021

@aarshkshah1992 @dirkmc scope here is exploding, because we can't just add a provider that references underlying interfaces that are not defined, such as: dbApi and adapter and dealPublisher and many others. This is why some of the code stays commented out, as we can't even compile before adding these underlying dependencies - even if we could, triggering these code paths would explode as they are not instantiated.

As next steps, I suggest:

  1. Merge this PR, because points 1-4 from PR description are improvement over what we have on main right now.
  2. Continue working on main with respect to refactoring the provider and all related dependencies - this involves:

a) removing adapter, and possibly other dependencies
b) properly instantiating all of the dependencies of the provider (such as dbApi)
c) move forward with a dummy deal end-to-end flow where boost is integrated with lotus and lotus-miner (sealing node) (via a itest or via a cmdline invocation)

WDYT?

@aarshkshah1992
Copy link
Collaborator

@nonsense I agree. Just one ask:

Since we wanna keep boost lightweight, we don't wanna be porting a bunch of interfaces from Lotus to Boost. I don't see the harm in keeping them in Lotus as they are today.

@nonsense
Copy link
Member Author

Since we wanna keep boost lightweight, we don't wanna be porting a bunch of interfaces from Lotus to Boost. I don't see the harm in keeping them in Lotus as they are today.

Which interfaces and structs are you referring to specifically? Everything that I have ported is markets related as far as I can tell, and the process boundary is at the fullnode API.

@nonsense nonsense changed the title integrate storagemarket.Provider into boost 2/ integrate storagemarket.Provider into boost Oct 28, 2021
@nonsense nonsense merged commit 3423c6e into feat/interfaces-types Oct 28, 2021
nonsense added a commit that referenced this pull request Oct 28, 2021
* interfaces and types

* feat/deal-execution (#12)

* remove dead code

* remove fund reservation

* 2/ integrate storagemarket.Provider into boost (#14)

* integrate storagemarket.Provider into boost

* add SectorBlocks; add DealPublisher; add OnDealSectorCommitted; add ProviderNodeAdapter

* boost: add api client for cli interaction (#15)

Co-authored-by: Anton Evangelatov <anton.evangelatov@gmail.com>
@nonsense nonsense deleted the nonsense/integrate-storage-provider branch October 28, 2021 12:54
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.

3 participants