On 02/06/2015 09:14 PM, Marcos Garcia wrote:
It does look like that. However, the intent here is to allow
non-developer
members of a Telco provide the use cases they need to accomplish.
This way
the Telco WG can identify gaps and file a proper spec into each of the
OpenStack projects.
Indeed, what we're trying to do is help the non-developer members of
the group articulate their use cases and tease them out to a level
that is meaningful to someone who is not immersed in
telecommunications themselves. In this way we hope to in turn be
able to create meaningful specifications for the actual OpenStack
projects impacted.
It's possible that some of these will be truly cross-project and
therefore head to openstack-specs but initial indications seem to be
that most will either be specific to a project, or cross only a
couple of projects (e.g. nova and neutron) - I am sure someone will
come up with some more exceptions to this statement to prove me
wrong :).
Ok, I definitively out of telco business, and I indeed openstack
operator. My first question: what you want to do, what problems you
want to solve?
IMO most of the Telco's are asking Openstack developers to work in the
following big areas (the first 3 are basically Carrier Grade):
- Performance on the virtualization layer (NUMA, etc) - get
baremetal-like performance in big VM's
- QoS and capacity management - to get deterministic behavior, always
the same regardless of the load
- Reliability (via HA, duplicate systems, live-migration, etc) -
achieve 99'999% uptime,
- Management interfaces (OAM), compatible with their current OSS/BSS
systems (i.e. SNMP traps, usage metering for billing) - to don't
reinvent the wheel, they have other things to manage too (i.e. legacy)
Most of this sounds really interesting for any operators. May be except
of NUMA. Buy why telco want more performance? Few percent of loss for
manageability - most companies accept this.
HA is achievable, QoS may be, duplication is ok. But of deterministic
live migrations... Why telco want it? If system have own way to
rebalance load, there is a more simple way: to terminate one instance
and to buid new. Btw I really want to see deterministic way to fight
with 'No valid hosts found'.
I was on one 'NVF' session in Paris, and I've expected it to be about
SR-IOV and using VF (virtual functions) of network cards for guest
acceleration. But instead it was something I just didn't got at all
(sorry, Ericsson). So, what are you want to do? Not in terms of
'business solution', but on very low level. Run some specific
appliance? Add VoIP support to Neutron? Make something differ?
It's all about SLA's stablished by telco's customers: government,
military and healthcare systems. SLA's are crazy there. And as an IT
operators, you'll all understand those requirements, so it's really
not that different compared to Telco operators.
Just remember that ETSI NFV is more than all that: you probably saw
Ericsson speaking about high-level telco functions: MANO, VIM, EMS and
VNFs, etc... that's beyond the scope of you guys, and probably outside
the scope of all of the Openstack world.. that's why OPNFV exists.
I will be a bit skeptic. It will not work with current quality of the
development process ('devstack syndrome'). I just done digging in yet
another funny nova 'half-bug' around migration and what I see in the
code is... to agile for high SLA systems. May be they (telcos) can
really change this, and I really hope, but up to now... Thousands of
loosly coupled systems with own bugs and world vision. Just today I
found 'hanged' network interface (any operation with netsocket goes to
'D' and can not be terminated) due ixgbe/netconsole bug. 99.99% in those
conditions? I just do not believe.
(https://www.mail-archive.com/e1000-devel@lists.sourceforge.net/msg10178.html)
About Ericcson's presentation - yes, I was inspired by details of
previous Rackspace's presentation about depth of the <s>hell</s>
openvswitch, and suddenly all around starts to talk foreign language.
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
