openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #06088
Re: trusted computing and nova
> Behalf Of Mark Washenberger
> 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.
>
Nova currently assuming all the capabilities are directly provided & updated "fully" through RabbitQ by components as Compute, Network and Volume, which won't be sufficient. Injecting new attribute into any of the 3 cap. Outside the above 3 components isn't persistent. For example, trust_state, of trusted computing, which to be created through channel other than RabbitQ needs to be inserted into A "4th" cap, which supports individual attribute update; otherwise it is to be trashed by compute nodes if it got lump into Compute cap. Any thought of providing such 4th cap.?
Filter provides sufficient "Select nodes with attribute(s) of" which enforce the positive qualifier; it depends users to specify "NOT" qualifier to not getting instances to run on non-qualified nodes. Any way to enforce "negative" qualifier is no "positive" qualifier specified?
Thanks,
-Fred
References