[tahoe-lafs-trac-stream] [tahoe-lafs] #1830: Upload (sometimes?) ignores shares.happy in tahoe.cfg

[tahoe-lafs]

#1830: Upload (sometimes?) ignores shares.happy in tahoe.cfg
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  kmarkley86
  davidsarah             |     Status:  new
         Type:  defect   |  Milestone:  1.11.0
     Priority:           |    Version:  1.8.1
  critical               |   Keywords:  regression upload servers-of-
    Component:  code-    |  happiness
  encoding               |
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Old description:

> kmarkley86 at [ticket:1212#comment:41]:
> > I'm affected by the same fundamental problem [as #1212], but by a
> different path. The fix identified earlier was to immutable/repairer.py,
> but I'm getting an error from immutable/upload.py.
>
> > Scenario: I'm using 2-of-4 encoding with shares.happy=4 on tahoe 1.8.1.
> From the CLI I do a tahoe check --repair on a file with shares {0, 2, 3}
> already existing on the grid but share 1 not existing, and I get an
> !UploadUnhappinessError complaining that "we were asked to place shares
> on at least 7" servers. There are only 4 servers on my grid -- hence my
> choice of shares.happy=4.
>
> > I observed that in immutable/upload.py, !BaseUploadable has a statement
> "default_encoding_param_happy = 7". I tried the experiment of changing
> this value to 4 (the shares.happy value in my tahoe.cfg) and then the
> repair succeeds without error.
>
> > So there must be a path through this code where the
> default_encoding_param_happy value is actually used instead of being
> overridden by the value in tahoe.cfg. (I think it smells a little that
> this object has defaults at all, instead of requiring the parameters to
> be provided.)
>
> A subsequent patch on trunk added assertions to try to catch the problem:
>
> > In [changeset:196bd583b6c4959c]:
> > Add assertions to make sure that set_default_encoding_parameters is
> always called, rather than using hardcoded 3/7/10 defaults. Also update
> affected tests. Note that this by itself cannot fix the bug mentioned in
> ticket:1212#comment:41, but it might make it easier to reproduce. refs
> #1212
>
> kmarkley86: can you try again to reproduce the problem [] using trunk?

New description:

 kmarkley86 at [ticket:1212#comment:41]:
 > I'm affected by the same fundamental problem [as #1212], but by a
 different path. The fix identified earlier was to immutable/repairer.py,
 but I'm getting an error from immutable/upload.py.

 > Scenario: I'm using 2-of-4 encoding with shares.happy=4 on tahoe 1.8.1.
 From the CLI I do a tahoe check --repair on a file with shares {0, 2, 3}
 already existing on the grid but share 1 not existing, and I get an
 !UploadUnhappinessError complaining that "we were asked to place shares on
 at least 7" servers. There are only 4 servers on my grid -- hence my
 choice of shares.happy=4.

 > I observed that in immutable/upload.py, !BaseUploadable has a statement
 "default_encoding_param_happy = 7". I tried the experiment of changing
 this value to 4 (the shares.happy value in my tahoe.cfg) and then the
 repair succeeds without error.

 > So there must be a path through this code where the
 default_encoding_param_happy value is actually used instead of being
 overridden by the value in tahoe.cfg. (I think it smells a little that
 this object has defaults at all, instead of requiring the parameters to be
 provided.)

 A subsequent patch on trunk added assertions to try to catch the problem:

 > In [changeset:196bd583b6c4959c]:
 > Add assertions to make sure that set_default_encoding_parameters is
 always called, rather than using hardcoded 3/7/10 defaults. Also update
 affected tests. Note that this by itself cannot fix the bug mentioned in
 ticket:1212#comment:41, but it might make it easier to reproduce. refs
 #1212

 kmarkley86: can you try again to reproduce the problem [] using trunk?

--

Comment (by zooko):

 Could this be related to #1847?

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1830#comment:4>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage