Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFR] wrongly updated method during wrapanapi 3.0 conversion #351

Merged
merged 1 commit into from
Jan 4, 2019

Conversation

izapolsk
Copy link
Contributor

Some sprout tasks fail during vm hardware configuration update because get_vm_hardware methods return memory in bytes instead of MB

@@ -368,7 +368,7 @@ def mark_as_template(self, template_name=None, cluster=None, delete=True, delete
def get_hardware_configuration(self):
self.refresh()
return {
'ram': self.raw.memory,
'ram': self.raw.memory / 1024 / 1024,
Copy link
Collaborator

Choose a reason for hiding this comment

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

This was intentionally removed, I believe any calculations done on the memory value reported by rhevm should be done by the caller. If we decide to manipulate the values here, it needs to be very obviously documented - otherwise I believe callers will expect the units (assumed and not stated in our return) that are reported by rhevm's API.

Copy link
Contributor Author

@izapolsk izapolsk Jan 4, 2019

Choose a reason for hiding this comment

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

@mshriver, I don't mind but value should be the same for all providers. All providers except rhevm return value in MB.
This unexpected change broke one of sprout task chains.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Seems we're scratching at a fundamental wrapanapi question then, one which we need to apply uniformly across the modules:

Should wrapanapi manipulate scalar values that have a unit, such that all returns are in the same unit (Mhz/Ghz, MB/GB, etc)?

If we have some agreement among the maintainers that in fact it should report consistent scalar units across providers, than we need to be consistent across all the wrapanapi methods (do the same for storage, memory, network methods)

Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm going to approve PR with this change as the impact to integration_tests looks small. I would like to hear from @psav, @bsquizz, @mkoura, @miha-plesko, and others on this topic.

Ultimately I agree with you Ievgen, wrapanapi should standardize the scalar units reported by the various providers, but we need thorough documentation of the intended unit conversions.

@@ -223,7 +223,7 @@ def enable_virtual_services(self):

def get_hardware_configuration(self):
self.refresh(read_from_hyperv=True)
data = {'mem': self.raw['CPUCount'], 'cpu': self.raw['Memory']}
data = {'mem': self.raw['Memory'], 'cpu': self.raw['CPUCount']}
Copy link
Collaborator

Choose a reason for hiding this comment

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

hardcore oops.

@izapolsk izapolsk added the bug label Jan 4, 2019
@mshriver mshriver merged commit f20d2ea into RedHatQE:master Jan 4, 2019
@miha-plesko
Copy link
Contributor

miha-plesko commented Jan 7, 2019

MIQ source code (in ruby) uses numbers bundled with units; for example time = 5.seconds or time = 1.hour, see here.

I kind of like it because it's nicely readable and you can use whatever unit you find appropriate and it gets converted correctly. Perhaps we could opt-in for something similar here? Googling gives me this library https://pypi.org/project/numericalunits, but I haven't actually tried it yet. Wdyt, should we go that direction?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants