Open Stack

> -----Original Message-----
> From: Jay Pipes [mailto:jaypipes at gmail.com]
> Sent: Tuesday, December 12, 2017 3:02 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [etsinfv][gap-04][blazar]: Clarification
> on the scope of the capacity query
> 
> On 12/11/2017 12:41 PM, Csatari, Gergely (Nokia - HU/Budapest) wrote:
> > Hi Jay,
> >
> > Okay. Thanks for the clarification. Makes sense.
> >
> > Random-thinking:
> > Maybe the best would be to have a privilege level what covers the
> needs of MANO/NFVO, but still not full admin privileges. Do you think
> is this possible?
> 
> I think that the differences between the super-privileged user needs
> that a MANO system has and an administrative user are pretty small. The
> MANO system needs to be able to query and dynamically adjust resource
> inventories, move and grow/shrink workloads as needed and essentially
> act like the underlying hardware is wholly owned and operated by
> itself.
> 
> Really, the only privilege that the MANO system user *doesn't* need is
> the ability to create new users/projects in Keystone. Everything else
> is something that the MANO system user needs to be able to do. This is
> why I've called NFV (and particularly MANO/NFVO) a "purpose-built telco
> application" in the past. And I don't say that as some sort of put-down
> of NFV. I'm just pointing out the reality of things, that's all.
[Mooney, Sean K] not all mano system require admin privileges. ONAP/OpenO/Ecomp do,
As far as I am aware OSM does not strictly require admin privilege in all cases.
e.g. it is intended to be able query the a vim or an iaas system such as OpenStack
for preexisting flavors, and images and use them if they exist instead of always
needing to have the permissions to create them. If the cloud it is managing does
not have the features it requires and it does not have admin credentials to create them
it will be unable to fulfill the requested vnf instantiation. Similarly on the networking
side not all VNF will require provider network as such vlan network to function. Since the
networking-sfc api is non privilege  a wan optimizer or dpi engine can still be injected into
a neutron tenant network without admin rights. As such in principal a mano system can be a
standard unprivileged tenant, however ONAP/OpenO and ecomp do not support that use case
in their architecture. 
> 
> The ramification of this reality is that people deploying NFV using
> cloud infrastructure software like OpenStack really need to fully
> isolate the infrastructure environments that are used for VNFs (the
> things managed by the MANO/NFVO) from the infrastructure environments
> that are used for more "traditional" virtual private server or IT
> applications.
> 
> Best,
> -jay
> 
> _______________________________________________________________________
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev