Skip to content
This repository has been archived by the owner on Oct 31, 2023. It is now read-only.

Usage factor persistence #4802

Merged
merged 11 commits into from
Oct 22, 2019
Merged

Usage factor persistence #4802

merged 11 commits into from
Oct 22, 2019

Conversation

shadeofblue
Copy link
Contributor

closes GR-178

@shadeofblue shadeofblue self-assigned this Oct 17, 2019
@mbenke
Copy link
Contributor

mbenke commented Oct 17, 2019

It might be worthwhile to add some tests along the lines of TestLocalRank

usage_factor = pw.FloatField(default=1.0)

class Meta:
db_table = "usagefactor"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it need a separate model/table? Isn't it better to just add a field in LocalRank?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm unsure but maybe I know too little about the marketplace in general -> how does a usage factor relate to LocalRank? is a usage factor always accompanied by a local rank record? does one implicitly assume the other or can they exist independently? are the properties in the LocalRank used for the same purpose as the usage factor?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mbenke ^ ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LocalRank is used basically for the same purpose as usage factors, i.e. provider choice.

golem/model.py Show resolved Hide resolved
SCHEMA_VERSION = 40

try:
import playhouse.postgres_ext as pw_pext
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this import required? How is it used here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it was added automatically by peewee_migrate...

@mbenke
Copy link
Contributor

mbenke commented Oct 18, 2019

Also, TestRequestorMarketStrategy seems to need to inherit DatabaseFixture now

Copy link
Contributor

@kubkon kubkon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely not an expert on this, but here's a couple of nitpicks.

Comment on lines 17 to 18
created_date = pw.UTCDateTimeField(default=dt.datetime.now)
modified_date = pw.UTCDateTimeField(default=dt.datetime.now)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume that we somehow use these for tracking usage factors in time? If not, are they not somewhat redundant?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these are inherited from BaseModel so, as standard feature of all golem models, so to say...

model.UsageFactor.provider_node_id == provider_id).first()

r = delta * usage_factor.usage_factor
logger.info("RWMS: adjust R for provider %s: %.3f -> %.3f",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Silly question but what's "RWMS"? Weighted RMS perhaps?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kubkon no idea, as you may see, this logging line was just copied from the other place

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it's more of RequestorWasmMarketStrategy than whatever else though, @kubkon

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, RWMS stands for RequestorWasmMarketStrategy. We use this abbreviation in log messages to make them shorter, but perhaps this abbreviation renders them less readable.

import datetime as dt
import peewee as pw

SCHEMA_VERSION = 40
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: the schema versions were shifted in #4807. I see you merged with develop, there's now a unit test which detects schema version collisions. Also, I'm adding a migration in #4811 - the race is on.
race

Copy link
Contributor Author

@shadeofblue shadeofblue Oct 21, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zakaprov yeah, I noticed ... I find our migration system horribly broken in that regard... migration numbering (as opposed to their contents) should NOT be something you have to take into account when resolving merge conflicts... :/

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SCHEMA_VERSION can be dropped altogether. Filenames decide the order that migrations are performed in.

If you believe that numbering is horribly broken please propose an alternative solution.

Copy link
Contributor Author

@shadeofblue shadeofblue Oct 21, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mfranciszkiewicz numbering itself is not the issue ... conflict resolution of those numbered migrations is the issue... it's okay for the numbering to determine the order but the existence of two migrations that share the same number should not be an issue. and as long as those migrations don't modify the same model, they should be able to co-exist...

good example could be Django's south (later just renamed to "django migrations") which handles such cases gracefully... though, of course, it being a django-specific module, it cannot/should not be used in a project like ours ...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zakaprov lost it ;)

@shadeofblue
Copy link
Contributor Author

It might be worthwhile to add some tests along the lines of TestLocalRank

@mbenke some tests added ...

- the need to explicitly .save() peewee factory instances
+ tests for WASM marketplace
@shadeofblue shadeofblue force-pushed the usage-factor-persistence branch from bfaf357 to d4ead7f Compare October 22, 2019 08:23
@codecov
Copy link

codecov bot commented Oct 22, 2019

Codecov Report

Merging #4802 into develop will decrease coverage by 0.08%.
The diff coverage is 87.09%.

@@             Coverage Diff             @@
##           develop    #4802      +/-   ##
===========================================
- Coverage    89.42%   89.33%   -0.09%     
===========================================
  Files          226      216      -10     
  Lines        20540    20126     -414     
===========================================
- Hits         18367    17980     -387     
+ Misses        2173     2146      -27

@shadeofblue shadeofblue merged commit 93f22e9 into develop Oct 22, 2019
@shadeofblue shadeofblue deleted the usage-factor-persistence branch October 22, 2019 14:39
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.

5 participants