On 08/18/2011 08:57 PM, Matt Wagner wrote:
Hi Jozef,
On Wed, Aug 17, 2011 at 07:33:47PM +0200, Jozef Zigmund wrote:
> Hi Conductor developers,
>
> I'm working on task from Redmine
> (
https://www.aeolusproject.org/redmine/issues/1965). I'm sending some
> suggestion how to make reporting of uptime until we won't use Matahari project
> for this purpose.
Are we assuming that all instances are stateless for this, or do we want
to support the eventuality of restartable instances? If instances can
only run once, tracking instance uptime seems like it would be easy --
(instance.end_time || Time.now) - instance.start_time, or whatever the
actual attributes are called.
If we do want to support instances that can be run more than once, I
think it's easy enough to store accumulated runtime when the instance
stops running... But I wonder if that's really just a denormalization of
an actual event log of instance starts and stops that we should keep.
For the record, the code that we have in works for stateful instances
already. Based on the events received from Condor, it tracks how long
the instance has been in each state.
The focus of this really is on Deployments. We actually do show an
uptime for deployments in the UI, but it's broken (it's a timer that
keeps going on but never stops -- even when all instances are stopped).
So we need to define what an uptime means in the context of a
Deployment, hence this task.
In any case, I think the real challenge, as you describe below, is
deployment runtime.
> What we want:
> * The total amount of time that at least one instance in a deployable was
> running
> * The amount of time that all instances were running, and the deployable was
> therefore complete
Do we also want the "instance hours" runtime? That is, if I have four
instances running for an hour, I've used 4 hours of time? (I sort of
think the answer is 'No', at least for now, because that information
isn't terribly meaningful on its own, and because it would really
complicate things.)
We can get this already just by counting the uptime of all the instances
belonging to a deployment. The question is whether we want to surface
that in the UI.
I think we will want to do that eventually, for the cost tracking.
Probably not any time soon, though. A question for Ken, most likely.
> Suggestion:
> Now we store information about various types of time for instance (like
> time_last_running) and also accumulative times for it in DB.
> We could add new events for deployment what will indicate a state:
> * 1st_running - when 1st of all instance will run
> * all_running - when all instances of deployment will run
Yes, I think this makes sense. The only thing is that the name
'1st_running' might be misleading -- we don't actually care about the
first instance itself. The place where this becomes confusing is in
reverse, when a deployment is being stopped -- 'all_running' ends when
any of the instances stop, and '1st_running' ends when the *last*
instance stops. Do you think something like 'any_running' and
'all_running' might be clearer here?
I agree, any_running communicates the message better.
> This events will be created in the instance_observer.rb. After then we could
> count required times with help of these events. Also we will fix case when one
> of instances fail, then we should stop counting 'The amount of time that all
> instances were running'.
>
> Please if someone will have other idea how to do it in other way, reply to
> this e-mail.
Overall, I think this sounds like a good plan.
-- Matt
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel
--
No trees were killed to send this message, but a large number of
electrons were terribly inconvenienced.