| Summary: | aeolus conductor uptime is not reset when user "restarts" instance via webui | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] CloudForms Cloud Engine | Reporter: | wes hayutin <whayutin> | ||||
| Component: | aeolus-conductor | Assignee: | Imre Farkas <ifarkas> | ||||
| Status: | CLOSED ERRATA | QA Contact: | wes hayutin <whayutin> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 1.0.0 | CC: | akarol, athomas, deltacloud-maint, jguiditt, slinaber, ssachdev, sseago | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| URL: | http://server/conductor/deployments/1?details_tab=instances | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-05-15 21:33:35 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
wes hayutin
2012-01-09 21:34:52 UTC
So the real question here is whether 'uptime' is intended to mean 'how long since last boot', or 'what is the accumulated uptime of this instance'? I was under the impression that we were really measuring the latter -- the reason being that back when we were thinking about stateful instances a couple years ago, that's how we were starting to define the model. I can see both as useful metrics, though -- but I don't know if we are explicitly modeling the 'how long since last boot' metric. Until we added reboot (and only had stateless/non-restartable instances), the issue wasn't important. It's marginally more so now, and once we add restartable stateful instances (i.e. I can stop it now, and I can start the same instance again tomorrow) it will be significantly more important. yeah, this sounds like a measurement of 'total instance usage time' rather than 'uptime'. Uptime is total continuous time running, imo For 1.0, we should continue to report the metric that we currently show, but should label it as "total usage time", in order to remove the ambiguity. adding to ce-sprint removing ce-sprint-next tracker Patch has been posted: https://fedorahosted.org/pipermail/aeolus-devel/2012-January/008145.html This issue has been fixed. Please verify the commit ffc52615aefbeca3dc3f945fe1c800ad5aa32459 ffc5261 in aeolus-conductor-0.8.0-12 Created attachment 558631 [details]
total_usage_time
Uptime replaced by "total usage time" Verified in rpm -qa|grep aeolus aeolus-conductor-doc-0.8.0-16.el6.noarch aeolus-configure-2.5.0-11.el6.noarch aeolus-conductor-daemons-0.8.0-16.el6.noarch rubygem-aeolus-image-0.3.0-6.el6.noarch aeolus-all-0.8.0-16.el6.noarch aeolus-conductor-0.8.0-16.el6.noarch rubygem-aeolus-cli-0.3.0-7.el6.noarch Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2012-0583.html |