Open Stack

----- Original Message -----
> From: "Alan Kavanagh" <alan.kavanagh at ericsson.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>, "Steve
> 
> Hi Adrian et.al
> 
> Adrian thanks for taking a stab at this, I think the use case list is a
> little long but good to put on the map. One item I would point out is that
> its fairly difficult and perhaps misleading to map the blueprints list to
> the ETSI NFV use case, for example you can argue that based on configuration
> and deployment of say vCPE some may require VLAN Trunking, others will not.
> Similarly for SR-IOV support when you a Transport node that consumes the
> total CPU and NIC available on the host and would in some cases be
> provisioned on bare metal SR-IOV is not a required feature set. Also some of
> these would not require anything in addition to support apart from what we
> already have in Openstack, for example in the case of CDN do we needed
> additional feature sets, imho apart from the nice state aware scheduling and
> VM allocation based on specific attributes required (specific PCI device
> type, topology based placement, on board SSD, etc) and  IP end point for
> delivery, do we need anything else beyond this?
>
> Perhaps what might be more beneficial is to ensure we can deploy a given app
> in the current OS distro and identify the necessary configuration attributes
> we would need to expose, would that be a good way forward? Interested to
> hear from others on this front. A suggestion, is we start with use cases 2
> and 7 that are more well defined and simpler to address and this is where I
> believe Itai had a good statement of “not boiling the ocean”, lets start
> with some simple ones that are well defined and well known and don’t have
> too many intrinsic configurations.
> 
> /Alan


Yes, thanks all - it's great to see plenty of people putting forward their thoughts on this :). I agree that it is somewhat problematic to map the ETSI NFV use cases "as is" directly to the list of blueprints, finding an appropriate way to distil them into the hard requirements of the most minimal configurations of each is key. I definitely agree concentrating on doing this for a subset of them that are particularly well defined first is the best way to start off without spreading our efforts too thinly.

Thanks,

Steve