Page History

...

1. The documentation available suggests that the configureWhiteList and registerHost api calls can be used for registering a server for attestation. These apis haven't been tried as part of poc. Need to confirm this. Should we keep the white list configuration and registration of a host out of the scope? Additionally, should management server check with the attestation server if a host is trusted or not and on getting a host not registered exception, register it? Or instead, keep the information on whether a host is registered or not in the db.
2. Proposal is to fill the host_details table with an additional attribute for an host on checking if it is trusted or not. Should this information be stored elsewhere, probably in a separate table?
3. For //cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups and //cwiki.apache.org/confluence/display/CLOUDSTACK/Dedicated+Resources+-+Private+pod%2C+cluster%2C+host+Functional+Spec Dedicated resources features changes are being made to address how an instance is deployed. It'll also affect this feature. For the current feature changes are needed in the host allocators to not to pick up an untrusted host if the service offering requires trusted host. How should a service offering be updated to include the information that a trusted host is required? Should it be done using name/value pairs, as has been suggested for Dedicated resource feature. However, name/value pairs will be the property of a planner (I could be wrong); and here we need to pass this information to the allocators.
4. Should the attestation server details be kept in a new table or can they be kept in the host table itself.