Re: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated
----- Original Message -----
From: "Oved Ourfalli" <ovedo(a)redhat.com>
To: "Itamar Heim" <iheim(a)redhat.com>, "Wei D Chen"
<wei.d.chen(a)intel.com>
Cc: engine-devel(a)ovirt.org
Sent: Sunday, April 21, 2013 8:41:50 AM
Subject: Re: [Engine-devel] Design wiki page for trusted compute pools integration with
oVirt has been updated
----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Wei D Chen" <wei.d.chen(a)intel.com>
> Cc: "Oved Ourfalli" <ovedo(a)redhat.com>,
"engine-devel(a)ovirt.org"
> <engine-devel(a)ovirt.org>
> Sent: Saturday, April 20, 2013 5:49:47 PM
> Subject: Re: [Engine-devel] Design wiki page for trusted compute pools
> integration with oVirt has been updated
>
> On 04/19/2013 12:21 PM, Chen, Wei D wrote:
> > Hi All,
> >
> > Our second approach for trusted compute pools integration with oVirt
> > seems
> > more simple and sensible than previous VM level approach. Welcome any
> > comments on our latest design. Thanks in advance.
> >
> > Link is here, http://www.ovirt.org/Trusted_compute_pools
> >
> >
>
> a few nits:
> 1. last updated date isn't updated...
> 2. from reading it top to bottom, hard to understand the 2nd approach is
> the one to be used and not the first (vm level).
> 3. cluster dialog - the 'trusted' should be a checkbox, not radio
> button, and should only be enabled if virt service was chosen.
>
I'd also consider putting this property in a different side tab. Perhaps
"Cluster policy" side tab would fit? (dividing it into two sections
"scheduling policy" and "additional properties" or something
similar.
What do you think about that?
> thanks,
> Itamar
Hi,
One more thing we need to think about for the second approach - aggregated query. On
engine start we need to determine the trust state of all the hosts. sending a separate
query for each host will overload the attestation host and the network. an initial
aggregated query needs to be send when the engine starts.
Same thing can happen after management network fail and so on.
Maybe we can run a quartz job every x minutes, checking if a large part of the hosts in
the cluster (like 30%) are untrusted - in that case run the aggregated query.
Ofri
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel