Storage Servers version is 0 on Welcome page #1067

Closed
opened 2010-06-05 20:34:05 +00:00 by freestorm · 6 comments
freestorm commented 2010-06-05 20:34:05 +00:00
Owner

Storage Server version is 0 for all nodes on the Welcome Page.

Storage Server version is 0 for all nodes on the Welcome Page.
tahoe-lafs added the
unknown
major
defect
1.6.1
labels 2010-06-05 20:34:05 +00:00
tahoe-lafs added this to the undecided milestone 2010-06-05 20:34:05 +00:00
freestorm commented 2010-06-05 20:34:29 +00:00
Author
Owner

Attachment server_version_on_welcome_page.dpatch.txt (40075 bytes) added

**Attachment** server_version_on_welcome_page.dpatch.txt (40075 bytes) added
freestorm commented 2010-06-05 20:36:54 +00:00
Author
Owner

I've looked to write a running test , but as far as I Now, the Welcome page in running test dosen't have "fake" storage server to verify version.

Fred

I've looked to write a running test , but as far as I Now, the Welcome page in running test dosen't have "fake" storage server to verify version. Fred
zooko commented 2010-06-06 17:56:02 +00:00
Author
Owner

Let's see, to test this we need to exercise the code that the patch changes -- [render_service_row()]source:src/allmydata/web/root.py@4238#L256 -- and verify that it is emitting something other than 0 in the "version" slot in the ctx. Let's see, there are already pretty thorough tests of the web ui...

Hm, let's see [test_web.py test_welcome()]source:src/allmydata/test/test_web.py@4358#L390 might do it, if there is already at least one server connected in that test. Why not see if you can add a requirement that the resulting HTML contains the right pattern of version?

Let's see, to test this we need to exercise the code that the patch changes -- [render_service_row()]source:src/allmydata/web/root.py@4238#L256 -- and verify that it is emitting something other than `0` in the `"version"` slot in the `ctx`. Let's see, there are already pretty thorough tests of the web ui... Hm, let's see [test_web.py test_welcome()]source:src/allmydata/test/test_web.py@4358#L390 might do it, if there is already at least one server connected in that test. Why not see if you can add a requirement that the resulting HTML contains the right pattern of `version`?
freestorm commented 2010-06-13 21:59:41 +00:00
Author
Owner

Replying to zooko:

Let's see, to test this we need to exercise the code that the patch changes -- [render_service_row()]source:src/allmydata/web/root.py@4238#L256 -- and verify that it is emitting something other than 0 in the "version" slot in the ctx. Let's see, there are already pretty thorough tests of the web ui...

Hm, let's see [test_web.py test_welcome()]source:src/allmydata/test/test_web.py@4358#L390 might do it, if there is already at least one server connected in that test. Why not see if you can add a requirement that the resulting HTML contains the right pattern of version?

I can't check the server version with [test_web.py test_welcome()]source:src/allmydata/test/test_web.py@4358#L390, because the running test dosen't have a fake server node connected and the test fails.

You can view the test fail here

I copy the html code returned from the running test, you can view it here

Note: I've just changed the css link, so the page can correctly be viewed by humans

Replying to [zooko](/tahoe-lafs/trac-2024-07-25/issues/1067#issuecomment-119390): > Let's see, to test this we need to exercise the code that the patch changes -- [render_service_row()]source:src/allmydata/web/root.py@4238#L256 -- and verify that it is emitting something other than `0` in the `"version"` slot in the `ctx`. Let's see, there are already pretty thorough tests of the web ui... > > Hm, let's see [test_web.py test_welcome()]source:src/allmydata/test/test_web.py@4358#L390 might do it, if there is already at least one server connected in that test. Why not see if you can add a requirement that the resulting HTML contains the right pattern of `version`? I can't check the server version with [test_web.py test_welcome()]source:src/allmydata/test/test_web.py@4358#L390, because the running test dosen't have a *fake* server node connected and the test fails. You can view the test fail [here](http://pubgrid.tahoe-lafs.org/uri/URI%3ACHK%3Ar2opofwj46quvysgt67uymsbfy%3Amzd2fm2qfjwizhmai4ojjwujok5nnub3oq7a6e5klas3eautxzna%3A3%3A10%3A5241) I copy the html code returned from the running test, you can view it [here](http://pubgrid.tahoe-lafs.org/uri/URI%3ACHK%3Avviwuup37y4xnpmu63g7qxvxru%3Aqwjnwkgrg743elohsgz2sm4a5qq4nieopsuxqwii2kyostpgbrgq%3A3%3A10%3A4570) **Note:** I've just changed the css link, so the page can correctly be viewed by humans
terrell commented 2010-07-08 16:43:44 +00:00
Author
Owner

I confirm this patch works as advertised and solves the issue.

I confirm this patch works as advertised and solves the issue.
tahoe-lafs added
code-frontend-web
and removed
unknown
labels 2010-07-08 16:45:19 +00:00
tahoe-lafs modified the milestone from undecided to 1.7.1 2010-07-08 16:45:19 +00:00
zooko commented 2010-07-08 18:05:57 +00:00
Author
Owner

fixed in changeset:35ec8f6ac28a4b7b. thanks FreeStorm and terrell!

fixed in changeset:35ec8f6ac28a4b7b. thanks FreeStorm and terrell!
tahoe-lafs added the
fixed
label 2010-07-08 18:05:57 +00:00
zooko closed this issue 2010-07-08 18:05:57 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac-2024-07-25#1067
No description provided.