ad a) ab b) good, I will make it configurable via engine-config. ad c) ok, we probably should think about what should be in that table. I've proposed, that only failures should be recorded. Since there's currently no use for other values/NIC states, and NICs will be probably functional most of the time. This will minimize the need to write anything to db, and therefore name "EngineNicFailures". I also wanted to store information in format: "This NIC, was not up during check at 'yyyy.MM.dd HH:mm:ss '". Which gives more information than what you're talking about. But there's no need for this data, so yes currently it'd be possible to store NIC status along with last failure timestamp. So the table could look like: CREATE TABLE nics_health ( id UUID primary key, name VARCHAR(255), is_healthy BOOL, last_failure TIMESTAMP); this way, we have to update record during each health check, while in previously proposed [by me] approach only when there's failure, and 'purge' of obsolete data can occur only when there's fence request and/or on some time period. What you're proposing provides less information (which is fine, since we don't need them), it's simpler, but it generates some unnecessary load for db. It's not big deal, but it's not optimal/necessary, since state, when nic is not up is not probable(if I understand it correctly). Sorry, have no idea what DWH stands for. ad d) I have no problem extending this feature with providing data over rest, but others should probably agree with that. I don't think any client(external system) need this information, and I also don't think engine nic health is any clients business in first place. —— I will update feature page asap. M. ----- Original Message ----- From: "Yair Zaslavsky" <yzaslavs(a)redhat.com&gt; To: "Martin Mucha" <mmucha(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org, users(a)ovirt.org Sent: Friday, October 10, 2014 3:14:37 PM Subject: Re: [ovirt-users] New Feature: engine NIC health check ----- Original Message ----- I was curious on how you perform the health check, so I read the feature page - good to learn more Java :) Regarding open issues - a. Yes, IMHO the scanning interval should be configured via engine-config - do you see a reason why not to do that? Maybe we should set a minimal interval value and enforSce it? b. Same for the "no faiures since.." interval c. I dont like the name of the table you're suggesting. Please consider an alternative. Also you may want to consider having a view that returns you the "static infomration" of the nic + the "stats" part (dynamic part? maybe just nic_state ? ) Why would u like to purge old data and not just hold a record per nic and update per each interval? in this case, no purging is required. Maybe for DWH you will want some info on the history of the status of the nics... but I'm not sure if this is relevant for now. d. If you go with my view suggestion, you might consider displaying the "state" at REST-API Yair