Fred, I can see the plugin-like behavior of the approach you have taken. However, there are a few components of it that could be improved in order to avoid adding extra complexity to the scheduler and to nova.
IMO, the parts that add complexity are the additional integrity caching service, the presence of an attestation http client in nova source, and the modifications that place "trust-level" at the same level of compute/volume/network components. To me, it isn't a plugin unless it can be shipped separately. (I agree with (other) Mark's comments that this code doesn't necessarily have to ship separately, but that is beside the point of its proper layout.) Here is some concrete advice I can offer on how to make this work: * I think the only real changes to existing nova source is that you should modify the DistributedScheduler::_get_filter_classes to support classes that are imported from anywhere. * I think you should require the HTTP attestation server to handle the trust state caching. If this is impossible for political reasons, then I think it is your responsibility to write a separate caching adapter for it that lives outside of Nova. If it is possible, maybe you can also rewrite the filter to handle the case where a compute node has been rebooted since its trust level was last verified. (It should exclude it from the current results if trust is required, but post a verification request to the attestation server so that results are likely to be fresh for the next scheduling task.) * As a best practice, you should avoid depending on or inheriting from existing nova core filters when writing your filter. Thus, the existing json_filter should not need any modifications. I think we should minimize the tension between the TC plugin and Nova source. * Can the attestation http client be replaced with a custom usage of a standard python http client? If not, presumably other python projects will need an attestation client so you should write one separately from Nova and put it in PyPI. If the advice above is not clear, maybe we can try to refine it together offline so that we can avoid spamming the list. Thanks for your patience with this process. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
