Open Stack

>3. OpenStack itself should ( its own Compute Node/L3/Routing,  Controller
)  have (5 nine capable) reliability.

Can you elaborate on this a little more? Reliability is pretty deployment
specific (e.g. database chosen, number of cluster members, etc). I'm sure
nobody would disagree that OpenStack should be reliable, but without
specific issues to address it doesn't really give us a clear target.

Thanks,
Kevin Benton


On Wed, May 21, 2014 at 11:24 PM, A, Keshava <keshava.a at hp.com> wrote:

> Hi
>
> In my opinion the first and foremost requirement for NFV ( which is from
> carrier class ) is 99.99999 ( 5 nines ) reliability.
> If we want OpenStack architecture to scale to Carrier class below are
> basic thing we need to address.
>
> 1. There should be a framework from open-stack to support 5 nine level
> reliability  to Service/Tennant-VM . ? ( Example for Carrier Class NAT
> Service/ SIP Service/HLR/VLR service/BRAS service)
>
> 2. They also should be capable of 'In-service up gradation" (ISSU) without
> service disruption.
>
> 3. OpenStack itself should ( its own Compute Node/L3/Routing,  Controller
> )  have (5 nine capable) reliability.
>
> If we can provide such of infrastructure to NFV then we think of adding
> rest of requirement .
>
> Let me know others/NFv people opinion for the same.
>
>
>
> Thanks & regards,
> Keshava.A
>
> -----Original Message-----
> From: Kyle Mestery [mailto:mestery at noironetworks.com]
> Sent: Monday, May 19, 2014 11:49 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
>
> On Mon, May 19, 2014 at 1:44 PM, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:
> > I think the Service VM discussion resolved itself in a way that
> > reduces the problem to a form of NFV - there are standing issues using
> > VMs for services, orchestration is probably not a responsibility that
> > lies in Neutron, and as such the importance is in identifying the
> > problems with the plumbing features of Neutron that cause
> > implementation difficulties.  The end result will be that VMs
> > implementing tenant services and implementing NFV should be much the
> > same, with the addition of offering a multitenant interface to Openstack
> users on the tenant service VM case.
> >
> > Geoff Arnold is dealing with the collating of information from people
> > that have made the attempt to implement service VMs.  The problem
> > areas should fall out of his effort.  I also suspect that the key
> > points of NFV that cause problems (for instance, dealing with VLANs
> > and trunking) will actually appear quite high up the service VM list as
> well.
> > --
> There is a weekly meeting for the Service VM project [1], I hope some
> representatives from the NFB sub-project can make it to this meeting and
> participate there.
>
> Thanks,
> Kyle
>
> [1] https://wiki.openstack.org/wiki/Meetings/ServiceVM
>
> > Ian.
> >
> >
> >
> > On 18 May 2014 20:01, Steve Gordon <sgordon at redhat.com> wrote:
> >>
> >> ----- Original Message -----
> >> > From: "Sumit Naiksatam" <sumitnaiksatam at gmail.com>
> >> >
> >> > Thanks for initiating this conversation. Unfortunately I was not
> >> > able to participate during the summit on account of overlapping
> sessions.
> >> > As has been identified in the wiki and etherpad, there seem to be
> >> > obvious/potential touch points with the advanced services'
> >> > discussion we are having in Neutron [1]. Our sub team, and I, will
> >> > track and participate in this NFV discussion. Needless to say, we
> >> > are definitely very keen to understand and accommodate the NFV
> requirements.
> >> >
> >> > Thanks,
> >> > ~Sumit.
> >> > [1] https://wiki.openstack.org/wiki/Neutron/AdvancedServices
> >>
> >> Yes, there are definitely touch points across a number of different
> >> existing projects and sub teams. The consensus seemed to be that
> >> while a lot of people in the community have been working in
> >> independent groups on advancing the support for NFV use cases in
> >> OpenStack we haven't necessarily been coordinating our efforts
> >> effectively. Hopefully having a cross-project sub team will allow us to
> do this.
> >>
> >> In the BoF sessions we started adding relevant *existing* blueprints
> >> on the wiki page, we probably need to come up with a more robust way
> >> to track these from launchpad :). Further proposals will no doubt
> >> need to be built out from use cases as we discuss them further:
> >>
> >>     https://wiki.openstack.org/wiki/Meetings/NFV
> >>
> >> Feel free to add any blueprints from the Advanced Services efforts
> >> that were missed!
> >>
> >> Thanks,
> >>
> >> Steve
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140521/9fa6eb4d/attachment-0001.html>