Open Stack

Yunhong, 

Just try to understand your use case:
    -- a VM can only work with cards from vendor V1
    -- a VM can work with cards from both vendor V1 and V2

      So stats in the two flavors will overlap in the PCI flavor solution.
I'm just trying to say that this is something that needs to be properly
addressed.


Just for the sake of discussion, another solution to meeting the above
requirement is able to say in the nova flavor's extra-spec
            
           encrypt_card = card from vendor V1 OR encrypt_card = card from
vendor V2


In other words, this can be solved in the nova flavor, rather than
introducing a new flavor.

Thanks,
Robert
               

On 1/17/14 7:03 PM, "yunhong jiang" <yunhong.jiang at linux.intel.com> wrote:

>On Fri, 2014-01-17 at 22:30 +0000, Robert Li (baoli) wrote:
>> Yunhong,
>> 
>> I'm hoping that these comments can be directly addressed:
>>       a practical deployment scenario that requires arbitrary
>> attributes.
>
>I'm just strongly against to support only one attributes (your PCI
>group) for scheduling and management, that's really TOO limited.
>
>A simple scenario is, I have 3 encryption card:
>	Card 1 (vendor_id is V1, device_id =0xa)
>	card 2(vendor_id is V1, device_id=0xb)
>	card 3(vendor_id is V2, device_id=0xb)
>
>	I have two images. One image only support Card 1 and another image
>support Card 1/3 (or any other combination of the 3 card type). I don't
>only one attributes will meet such requirement.
>
>As to arbitrary attributes or limited list of attributes, my opinion is,
>as there are so many type of PCI devices and so many potential of PCI
>devices usage, support arbitrary attributes will make our effort more
>flexible, if we can push the implementation into the tree.
>
>>       detailed design on the following (that also take into account
>> the
>> introduction of predefined attributes):
>>         * PCI stats report since the scheduler is stats based
>
>I don't think there are much difference with current implementation.
>
>>         * the scheduler in support of PCI flavors with arbitrary
>> attributes and potential overlapping.
>
>As Ian said, we need make sure the pci_stats and the PCI flavor have the
>same set of attributes, so I don't think there are much difference with
>current implementation.
>
>>       networking requirements to support multiple provider
>> nets/physical
>> nets
>
>Can't the extra info resolve this issue? Can you elaborate the issue?
>
>Thanks
>--jyh
>> 
>> I guess that the above will become clear as the discussion goes on.
>> And we
>> also need to define the deliveries
>>  
>> Thanks,
>> Robert 
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev