----- Original Message ----- > From: "Ofri Masad" <[email protected]> > To: "Wei D Chen" <[email protected]> > Cc: [email protected] > 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" <[email protected]> > > To: [email protected] > > 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 > > > > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
