On 20 Dec (17:44:31), George Kadianakis wrote:
David Goulet dgoulet@ev0ke.net writes:
On 06 Dec (10:09:57), teor wrote:
On 6 Dec. 2016, at 09:56, David Goulet dgoulet@ev0ke.net wrote:
<snip>
Here's a suggested strategy:
- at load time, validate the HS options as if v2 is the default, and validate them as if v3 is the default, and fail if either validation fails.
- then, act on the HS options as if v2 is the default, and also act as if v3 is the default, and fail if either action fails. (We need to do this because we don't discover some option issues until runtime, such as whether the directory can be created.)
- then, when each consensus is downloaded, publish whichever descriptor is the default in the consensus (if the HS config does not specify a specific version).
This is a reasonable way to proceed considering we use a consensus param to know which version of default HS to create. I see this as more of an engineering problem that can be solved.
Which what I would like us to decide on if we think that consensus param controlling the default version is a good idea or not. If we think yes, we can pull it off, if not everything is simpler :).
So just to be clear, I'm behind you on the concern of making sure we validate the options on launch instead of failing at consensus download. There are ways we can address that like you outlined above.
Hello,
I agree that this is more of an engineering problem that can be solved. I also like the agility that the consensus parameter gives us.
That said when we get close to implementing this feature, IMO we should estimate how long it will take us to implement this consensus parameter logic, and evaluate whether it's worth doing. This feature might be an evening of work, but it could also be two annoying weeks of testing and debugging crazy networking and consensus fetching edge cases, so we should make sure we don't sign up for too much craziness.
The alternative would be that we don't do the consensus parameter, and instead we just change the version parameter in alpha/stable releases when we feel it's ready. This will be a slower and more gradual deployment which is not necessarily a terrible thing when we are talking about huge features like prop224.
Agree. In a matter of few hours, we'll know if this is too much engineering with lots of corner case untested or actually doable easily.
The fallback to use the parameter is a good idea to avoid going overboard if we realize it is kind of crazy.
Cheers! David