Development meeting held @ 3PM UTC in grincoin#dev channel on Keybase. Meeting lasted ~ 60 min.
Notes are truncated, and conversations sorted based on topic and not always chronological. Quotes are edited for brevity and clarity, and not always exact.
Community attendance:
- antiochp
- bladedoyle
- cekickafa
- defistaker
- jaspervdm
- joltz
- lehnberg
- phyro
- quentinlesceller
- tromp
(apologies if I missed someone - submit a PR or contact @lehnberg to add)
-
antiochp: Not much to update, 5.0.0-beta.2 has been out for a week and a bit. HF on testnet happening very shortly, all eyes are on that I think. Thanks to @bladedoyle we found an issue with full archive nodes during startup (issue has been there since 4.1.1) - fix is in #3513. That will be included in the next beta release (assuming we have one before rc).
There is a bump to the tokio/hyper version for stability also ready to go - so that will be included in next beta also.
Other than that - I think beta.2 has been running smoothly - moment of truth in the next 60 mins or so.
The proposed agenda was reviewed and with "wallet command naming" and "api listening on 0.0.0.0" added as points.
- joltz: Nothing new there afaik. the one exchange looking for extra support has received it I think.
- antiochp: Awesome, do we know if that extra support has put them in a position to support slatepacks?
- jaspervdm: I think at least one exchange is still affected by mimblewimble/grin-wallet#509
- joltz: Right, we did need to resolve that one.
- jaspervdm: I've been working on the fix again, we could release a 5.0.1 for it.
- antiochp: Yeah we need to decide if the fix is too invasive to risk pushing out as part of 5.0.0 (and if it can wait for 5.0.1). Or said another way - how confident are we that the fix won't risk introducing bigger problems.
- jaspervdm: I realized we can fix the bug without moving to reqwest, so i could split the PR up so the actual bugfix (using a global tokio runtime) is separate from moving from our custom hyper code to reqwest.
- antiochp: Ahh I saw your post on wallet-dev about that. Lets leave this as "in progress" for now and discuss outside meeting.
- jaspervdm: Yep
-
antiochp: Anything to update there?
- joltz: Don't think so- @mcmmike has been working to improve monitoring.
- 🚀: antiochp
- joltz: Don't think so- @mcmmike has been working to improve monitoring.
-
defistaker: I am working with @mcmmike on reorg status, iti is almost finished, will test this week.
- 👍: lehnberg, joltz, defistaker, defistaker
- antiochp: @defistaker 🚀
- antiochp: I see RC is scheduled for next week - so probably we can cut a beta.3 in the interim. Maybe today or tomorrow if everything is in place? (contingent on HF on testnet)
- jaspervdm: Yes sounds good
- quentinlesceller: Yep sounds good too
-
antiochp: Maybe we don't go too much into the weeds on this, given hf4 etc.? Do we have this tracked or documented somewhere?
-
tromp: There is only the forum thread.
- quentinlesceller: Completely missed that thread ^^.
-
antiochp: Ah ok - maybe we postpone discussing this until another time?
- tromp: Ok.
-
antiochp: We're unlikely to change naming prior to hf4.
- tromp: I thought this was the best time to establish consistent names.
-
lehnberg: Would have been great to have painted that shed in summer or so...:/
- antiochp: Plenty of time for shed painting in '21.
- lehnberg: Don't get me wrong, I'd love to improve naming as well. Just don't want to do it in the middle of a beta process and risking introducing regressions.
-
antiochp: Are we of the opinion this should be tackled for hf4?
- quentinlesceller: I think so yes depending on the complexity.
-
quentinlesceller: Yep as mentioned above. @bladedoyle can you explain. Sorry I have to do an emergency fix on grinmint testnet before hf4 ^^.
- bladedoyle: Default behavior of a docker container is to create an attach to a virtual interface on docker bridge (subnet). Because a docker container can run only 1 process, by restricting listen address to localhost its impossible to connect 2 containers together on wallet port. On api for getting conbase (and other) from wallet.
- antiochp: > because a docker container can run only 1 process
Is not necessarily true though (not saying its desireable or recommended).
- bladedoyle: That is true. You can hack in more processes but it does not work well. There is only one stdout. There is only 1 "init" process (12).
-
antiochp: That said - I don't see any reason we should not support listening on
0.0.0.0via config (if you know what you are doing).- bladedoyle: If you want to support containerized infra, we need to make that a config item. If you do not care aboutr containerized infra then no change is needed.
-
antiochp: Default to
127.0.0.1but allow this to be overridden via config.- 👍: joltz
-
antiochp: And I don't think this is hugely complex - just needs to be tested thoroughly.
- bladedoyle: Thats how it was before, so no testing would be needed.
-
antiochp: Is the "coinbase api" the only instance where we need this?
- bladedoyle: No. I would think everything in that api sould remain available - except the http one.
- antiochp: Ok so basically as it was before. Is there an issue tracking this?
- bladedoyle: No point in creating an issue unless you agree its a problem.
- antiochp: No I think we are in agreement.
-
jaspervdm: Hm not sure about enabling all endpoints, it would mean http payouts are not really removed. Exchanges could still use http as the only method, since users will have an option to listen on 0.0.0.0 as before.
- bladedoyle: The issue I think is that the code relies on the http endopint for tor - shouldn't those be connected internally rather than through a network port?
- antiochp: Ah ok - so there is some overlap there in terms of 2 conflicting issues?
- bladedoyle: The api listener should be left alone, and the http endpoint removed from it.
-
antiochp: Can we open an issue for this so we can discuss there?
-
jaspervdm: That would mean introducing a new kind of foreign api. But yeah lets open an issue and discuss there.
None.
Meeting adjourned.