Open Stack

More than happy to help out, I think we are on a good path by focusing on the current BP's we have. I will not make it to IRC meeting today, but will comment afterwords.
I think Adrian also pointed out one other point just to put on the table so we set the tone and scope accordingly, that is some of these BP's while being NFV related and not NFV essential but also benefit the generic cases too imho. 
For example the port-mirroring is in some cases a feature "some NFV services" would utilise" (lots of strange stuff in the wild :-) ) this and others would never need this.

Alan

-----Original Message-----
From: Steve Gordon [mailto:sgordon at redhat.com] 
Sent: June-11-14 6:54 AM
To: Alan Kavanagh
Cc: OpenStack Development Mailing List (not for usage questions); ITAI MENDELSOHN (ITAI); Chris Wright; Stephen Wong; Nicolas Lemieux
Subject: Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context

----- 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