[Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your review

[Doron Fediuck]

----- Original Message -----
> From: "Ofri Masad" <omasad at redhat.com>
> To: "Wei D Chen" <wei.d.chen at intel.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, March 28, 2013 12:05:02 PM
> Subject: Re: [Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your
> review
> 
> Hi Dave,
> 
> I would like to raise again the question of the full cache flash for
> each stale cache entry found.
> This method can cause two unwanted situations:
>  1. Choosing untrusted host: lets say, for example that you have 1000
>  host in your pool. you look at the first host in the cache and find
>  that its attestation hat expired. you refresh the entire pool
>  (there are 1000 host, that must take some time). by the the time
>  the last host was refreshed in the pool, the first host may already
>  be expired again. but since you already checked it - you keep on
>  with your flow and select that host, even so it has expired and may
>  as well be untrusted.
> 
>  2. infinite loop: lets say we'll try to fix what I've described in
>  1. then, we need to check again if the host has expired before we
>  select it. if it is, the entire refresh process starts again. this
>  could potentially go on forever (unless I'm missing something, and
>  the expiration is much longer then the full re-cache process).
> 
> Instead of re-caching the full cache we can do as follows:
>  - hold the cache entries sorted by expiration (if the expiration
>  time is the same for all hosts, so a queue is enough).
>  - each time we need a new trusted host - select from the unexpired
>  hosts, refresh all expired hosts (in one query).
>  - if all hosts are expired - we can wait for the first host to be
>  defined trusted by the attestation server and select that host.
> 
> Ofri
>     
> 

Dave, adding another suggestion on top of Ofri's;

Generally speaking, a cluster of hosts defines many joint features
(such as CPU level), which means that in the same cluster we would
expect to be able to freely migrate a VM from one host to another.

Current trust-pools design is breaking this concept, as you introduce
a state where a VM cannot migrate from a 'safe' host into an 'unsafe'
host.

This leads me to the suggestion of having attestation as a cluster
policy rather than a VM-level property. It means that all hosts in
this cluster are constantly being monitored to be safe. If a host
is declared as unsafe in the Attestation server, it will become
non-operational in the engine. This will simplify the implementation
since you have everything ready for you once you have a 'safe' cluster
and no need to do any VM-level changes.

So in this way you keep current concepts while simplifying the
implementation with very little worries of performance issues.

Can you please share your thoughts on this suggestion?

> ----- Original Message -----
> > From: "Wei D Chen" <wei.d.chen at intel.com>
> > To: engine-devel at ovirt.org
> > Sent: Friday, March 22, 2013 11:34:55 AM
> > Subject: [Engine-devel] Open Attestation integration with oVirt
> > engine proposal has submitted patchset5 for your
> > review
> > 
> > Hi all,
> > 
> > Before submitting this patch set, we has updated our design page,
> > and
> > new feature about VM template has added to this patchset. In
> > patchset a lot of frontend changes has been imported.
> > Welcome to review our patchset and thanks advance for your
> > suggestion.
> > 
> > 
> > Detailed description: http://wiki.ovirt.org/Trusted_compute_pools
> > 
> > In this patch set, follow changes has been introduced:
> > 
> > 1. GUI changes to support for creating a trusted VM on a trusted
> > physical host.
> > 2. View/Edit VM changes to enable end user switch between three run
> > on options.
> > 3. Template relevant changes to support end user create a trusted
> > VM
> > template and create trusted VM based on this template afterwards.
> > 4. Bug fixing and code cleanup.
> > 5. wiki design page update.
> > 
> > 
> > 
> > Best Regards,
> > Dave Chen
> > 
> >