ignore (workaround for lack of itest runability) #11987
Conversation
ribasushi
force-pushed
the
master
branch
6 times, most recently
from
795c1ce
to
1e10e2b
Compare
|
OK, but just be aware that the cost of running these tests is coming off a certain budget; it's good to be supporting the ecosystem, but bills will add up if this is going to be a regular thing. |
|
I am very aware. A friendly suggestion: instead of trying to make the ecosystem feel bad about your "limited" budget: fix your tests to be runnable by mere mortals. |
ribasushi
force-pushed
the
master
branch
7 times, most recently
from
c5ffb74
to
85ae603
Compare
* Test various multi-sector cases with niporep * UnmanagedMiner can now onboard multiple sectors for one miner and manage PoSt for all of them
… test (filecoin-project#12203) * fix the event bloom filter in eth tx receipts
While technically the entire "what are we building" should stay in build/... , not having the static-ish machinery split across 2 namespaces is an improvement
This is a large diff, yet should have exactly zero functional changes Ideally as a result of this some parts of the depchain will become lighter, with downstream reaping the same benefits as the team that initiated this split. P.S. work was done while forming better intuition of current dependency graph
storage/pipeline.NewPreCommitBatcher and storage/pipeline.New now have an additional error return to deal with errors arising from fetching the sealing config.
error return to deal with errors arising from fetching the sealing config.
There are no perf gains to be had here anyway
By a wide margin the top issue with large blockstores is the size of their index. Transparently switch the badger lookup key to the leading 128 bits of the hash, regardless of type/codec. In the proccess forbid AllKeysChan and rewrite ForEachKey. Also unconditionally enable HashOnRead (only safe way to do partial keys) This is safe (and has been tested) to run on an existing lotus install, with splitstore enabled and compacting properly. When converting an existing setup simply set the envvar LOTUS_CHAIN_BADGERSTORE_QUERY_LEGACY_KEYS to true. When sufficient amount of FullGC cycles have passed and all the keys in your blockstore are "new" - the envvar is no longer needed. Reasoning: The filecoin blockstore in April 2024 sits at about 26 billion blocks. The current scheme of /blocks/base32-enc-of-entire-mh puts a key at 66 bytes, for a total raw index of about 1.6TiB. Reduction of every key to mere 16 bytes reduces this to just 390GiB, potentially even fitting in memory.
Prefix every bin-key value with a single uint64 varint containing:
(3bit store-type) // 0 for as-is, 1 for basic zstd compression, remainder reserved
+
(one reserved bit) << 3 // always 0 for now
+
(3bit compressability) << 4 // 0 if store-type is 0, otherwise `c := (origLen-compLen) * 8 / origLen`
// (using integer math, `origLen > compLen > 0` holds for any non-0 store-type)
+
(IPLD block data size) << 7 // 0 if store-type is 0
Include a rudimentary, dictionary-less zstd compressor as the first
non-verbatim storage type 1
There is no value for a node to participate in relaying any of this (nor is there much positive value for the network as a whole...)
After this commit a node's entire libp2p Hello looks like: /chain/ipfs/bitswap /chain/ipfs/bitswap/1.0.0 /chain/ipfs/bitswap/1.1.0 /chain/ipfs/bitswap/1.2.0 /fil/chain/xchg/0.0.1 /fil/hello/1.0.0 /floodsub/1.0.0 /ipfs/id/1.0.0 /ipfs/id/push/1.0.0 /ipfs/ping/1.0.0 /meshsub/1.0.0 /meshsub/1.1.0
|
I am closing this PR as it doesn't seem like it is contributing to this code base. |
|
@jennijuju so... this is a weird action. I was told that the real fix for the title of this PR (inability to successfully run Therefore this leaves me 2 choices
That you are forcing me to do |
|
@ribasushi or there is another option that maybe you can help contribute to the code base, that you are use as an upstream, to improve how test can be run |
|
Or have you considered to not open draft PRs knowing that they are “fake PRs” with no intention to get them landed in the code base, but actually open those PR with a goal to land them(contribute to OSS public good)? |
@jennijuju I am sorry, but you really have no standing to lecture me on how "OSS public good" works, or what it even is. The reason I spend a considerable amount of time to maintain a side-repo in the 1st place is because your team is notoriously obstructionist when it comes to accepting non-trivial changes from experienced operators. Hence I open PRs for what reasonably has a chance to land, and deal on my own with stuff I gave up arguing about. Some of the changes I carry in my tree are literally from the year 2020. All the code is there, ready to go, when someone who recognizes OSS is a two-way street comes along to pick them up. ribasushi/ltsh@backports...maybe_for_upstreaming 
In the meantime - message received: if one needs to execute all the tests (regardless of reason) then "fake" PRs on as-neede basis it is. |
DO NOT MERGE
DO NOT LOOK
KEEP WALKING
☨ this PR is never meant to leave
draftstatus: it is merely temporary CI for https://github.com/ribasushi/ltsh#readme, as runningitestslocally is currently quite challenging