Hide Forgot
Description of problem: 1. start an instance via webui, in the case I used vsphere 2. notice the instance's uptime 3. restart the instance Expected results: The uptime of the instance is reset Actual results: The uptime continues to add to the original uptime [root@qeblade31 yum.repos.d]# rpm -qa | grep aeolus aeolus-conductor-daemons-0.9.0-1.el6.noarch rubygem-aeolus-cli-0.4.0-1.el6.noarch rubygem-aeolus-image-0.4.0-1.el6.noarch aeolus-all-0.9.0-1.el6.noarch aeolus-configure-2.6.0-1.el6.noarch aeolus-conductor-0.9.0-1.el6.noarch aeolus-conductor-doc-0.9.0-1.el6.noarch [root@qeblade31 yum.repos.d]# rpm -qa | grepd deltacloud -bash: grepd: command not found [root@qeblade31 yum.repos.d]# rpm -qa | grep deltacloud deltacloud-core-ec2-0.5.0-0.rc1.el6.noarch deltacloud-core-vsphere-0.5.0-0.rc1.el6.noarch deltacloud-core-0.5.0-0.rc1.el6.noarch rubygem-deltacloud-client-0.4.0-3.el6.noarch deltacloud-core-rhevm-0.5.0-0.rc1.el6.noarch
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