Add support for a helia container #5
Conversation
| Name: "kubo-host", | ||
| Usage: "port to reach the Kubo Gateway", | ||
| EnvVars: []string{"TIROS_RUN_KUBO_HOST"}, | ||
| Name: "ipfs-host", |
There was a problem hiding this comment.
| Name: "ipfs-host", | |
| Name: "helia-host", |
There was a problem hiding this comment.
not sure if this is per instance or the global name
There was a problem hiding this comment.
This is per instance and would point to either Kubo or Helia. That's why I renamed it. However, I can't find any usage of that config flag anyway :D
dennis-tra
force-pushed
the
helia-support
branch
from
2bb9b29
to
1fadd88
Compare
|
@dennis-tra are you waiting on anything from @ipfs/helia-dev to get this merged? Is there anything we can do to help this along? |
| @@ -2,7 +2,7 @@ version: "3.9" | |||
| name: tiros | |||
| services: | |||
| ipfs: | |||
| image: ipfs/kubo:v0.19.0 | |||
There was a problem hiding this comment.
Does this mean our measurement hasn't been using the latest Kubo? Will it use the latest Kubo and Helia going forward?
There was a problem hiding this comment.
The idea was to indeed run the latest version of kubo and the most common one based on our measurements. In the past, this has been 0.18 and 0.19. While you're correct that we weren't running the very latest version of Kubo, his docker compose file doesn't represent our deployment. The current deployment configuration is here and with the new helia version the config looks like this
There was a problem hiding this comment.
Thanks for the info. I can't click through to the link. Can you please give me access?
|
@SgtPooki the helia image didn't fully work for me yet. That's why I haven't deployed it. I'm in touch with Nishant about it and as soon as the websites and all resources are loaded properly I'll deploy it 👍 |
dennis-tra
force-pushed
the
helia-support
branch
from
1fadd88
to
2472b5c
Compare
dennis-tra
force-pushed
the
helia-support
branch
from
2472b5c
to
6b396f5
Compare
|
Removed all Kubo references and made it generic on the IPFS implementation. The new database migrations also allow to track which IPFS implementation was under test as there was the hidden (or not so hidden) assumption that it's Kubo. |
|
As discussed with @whizzzkid I'll deploy the current version of the Helia image while he works on the remaining bits. This allows us gain early experience in running Helia alongside Kubo in our measurement infra. |
| func (t *tiros) InitRun(c *cli.Context) (*models.Run, error) { | ||
| version, sha, err := t.kubo.Version() | ||
| version, sha, err := t.ipfs.Version() | ||
| if err != nil { | ||
| return nil, fmt.Errorf("kubo api offline: %w", err) | ||
| return nil, fmt.Errorf("ipfs api offline: %w", err) | ||
| } | ||
|
|
||
| dbRun, err := t.dbClient.InsertRun(c, fmt.Sprintf("%s-%s", version, sha)) | ||
| ipfsImpl := c.String("ipfs-implementation") | ||
| dbRun, err := t.dbClient.InsertRun(c, ipfsImpl, fmt.Sprintf("%s-%s", version, sha)) |
There was a problem hiding this comment.
FYI @dennis-tra this is failing for me locally saying ERRO[0000] error: init run: ipfs api offline: version: command not found. Is this trying to call 'ipfs' binary locally to return version?
There was a problem hiding this comment.
It's not using the local Kubo binary. It's using the HTTP API exposed by Kubo. In this case, the must be an endpoint that implements this specification: https://docs.ipfs.tech/reference/kubo/rpc/#api-v0-version
I thought this was already done by @whizzzkid?
Relates to: probe-lab/network-measurements#58