Do we need anything more than a way to inject a third-party filter into schedulers?
I'm assuming that we need to schedule based on whether or not the attestation server verifies the host. And I understand that this situation introduces some peculiar and novel requirements on the scheduler. But I don't think it makes sense to deduce from that that we should write an attestation client into nova and create a new scheduler and manager service. Instead, we should robustify (is that even a word? :-) the plug-ability of the scheduler with these requirements in mind. I really appreciate the work that has gone into making this transparent and generic with the standalone http-based attestation server. I just don't think it goes quite as far as it needs to. "Yang, Fred" <fred.y...@intel.com> said: > > >> -----Original Message----- >> From: openstack-bounces+fred.yang=intel....@lists.launchpad.net >> [mailto:openstack-bounces+fred.yang=intel....@lists.launchpad.net] On >> Behalf Of Vishvananda Ishaya >> Sent: Friday, December 09, 2011 11:33 AM >> To: Michael Pittaro >> Cc: OpenStack Mailing List; Mark Washenberger >> Subject: Re: [Openstack] trusted computing and nova >> >> I suggested a couple alternative solutions for implementations in one >> of the reviews. Hoping to hear back from fred yang/intel on whether >> one of those solutions will work. Copied suggestions here in case >> anyone else is following along. >> >> Brian Waldon and I were discussing the possibility of a couple >> different approach for trusted computing which wouldn't require adding >> a separate component and scheduler. >> >> 1. add an admin api to add and remove hosts from an availabilty zone. >> Then the component that is verifying trust could periodically check the >> hosts and remove them from the trusted zone if they fail. The scheduler >> could just use regular availability-zone scheduling to send the hosts >> to the trusted zone. > Service providers can have mixed computing nodes of trusted or non-trusted > nodes > dispatched pending on subscribers' demands. The intent is to make "trust" to > be > transparent to providers' zone setup >> >> 2. rather than verify trust during schedule, provide an external >> service that is exposed to users where they could verify trust. They >> could basically request the trust state of an instance. The service >> would speak to nova through an admin api to discover which host the >> instance is running on and verify the trustedness of the host, and >> return "trusted" to the user if the node passes. > If understand correctly, this approach is to address after fact that Nova > scheduler have selected-and-run instance. This approach can directly > impact/break > subscriber's needs/data already since instance has been started and would > need > subscribers intervention. This is why we need to perform scanning through > scheduler > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
