Skip to content
This repository has been archived by the owner on Mar 25, 2022. It is now read-only.

Run go-ipfs dev0.4.0 on pluto and castor #115

Merged
2 commits merged into from
Nov 14, 2015
Merged

Run go-ipfs dev0.4.0 on pluto and castor #115

2 commits merged into from
Nov 14, 2015

Conversation

ghost
Copy link

@ghost ghost commented Nov 14, 2015

Castor needs dev0.4.0 for NPM, and pluto will act as a rendezvous point for dev0.4.0 nodes.

ipfs/fs-repo-migrations#7 isn't merged yet, so both hosts don't have any of the pinnings. This includes the website, so I took pluto out of ipfs.io DNS.

Lars Gierth added 2 commits November 13, 2015 23:43
License: MIT
Signed-off-by: Lars Gierth <[email protected]>
License: MIT
Signed-off-by: Lars Gierth <[email protected]>
@ghost ghost added the solarnet label Nov 14, 2015
ghost pushed a commit that referenced this pull request Nov 14, 2015
Run go-ipfs dev0.4.0 on pluto and castor
@ghost ghost merged commit 8281612 into master Nov 14, 2015
@ghost ghost deleted the version-override branch November 14, 2015 01:40
@daviddias daviddias mentioned this pull request Nov 14, 2015
42 tasks
@ghost ghost mentioned this pull request Nov 16, 2015
53 tasks
@jbenet
Copy link
Member

jbenet commented Nov 16, 2015

we should think through how to do the upgrade.

  • I think we'll need to keep running pre 0.4.0 bootstrappers for a while (1 or 2 months?).
  • we should endeavor to make the https://ipfs.io gateway resolve stuff on both pre 0.4.0 and post 0.4.0.
  • We will need to have a way of warning users that 0.4.0 is out (maybe 0.3.10 could warn about this)
  • It would be very nice to have something like wall for the entire network to warn people about things. (discussed this a long time ago with @whyrusleeping) could be a feed of messages on ipfs itself, hosted at something like http://<bootstrap-node>:80/refs/wall (so private networks could use it too)

@cryptix
Copy link
Contributor

cryptix commented Nov 16, 2015

👍 for wall/message of the day

@ghost
Copy link
Author

ghost commented Dec 4, 2015

I think we'll need to keep running pre 0.4.0 bootstrappers for a while (1 or 2 months?).

agreed

we should endeavor to make the https://ipfs.io gateway resolve stuff on both pre 0.4.0 and post 0.4.0.

Got a good idea how to do this cleanly, without trapping edge cases? We could have nginx fall back to another backend when the primary backend responds with a certain status (e.g. 404) -- but I'm not sure this would work well with legitimate 404s, i.e. we'd have both the 0.3 and 0.4 backends trying to resolve for some time, and make already slow responses twice as slow. Does this make sense?

http://<bootstrap-node>:80/refs/wall

This already kinda works, cool, just need to add a wall link: http://venus.i.ipfs.io/refs/

@jbenet
Copy link
Member

jbenet commented Dec 4, 2015

Got a good idea how to do this cleanly, without trapping edge cases? We could have nginx fall back to another backend when the primary backend responds with a certain status (e.g. 404) -- but I'm not sure this would work well with legitimate 404s, i.e. we'd have both the 0.3 and 0.4 backends trying to resolve for some time, and make already slow responses twice as slow. Does this make sense?

yeah, makes sense. not sure either. :/

@ghost ghost mentioned this pull request Dec 10, 2015
This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants