[etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query

Csatari, Gergely (Nokia - HU/Budapest)

Hi,

 

During the Forum session about the ETSI NFV Gaps I received a request to clarify the scope of the capacity query mentioned in [GAP-04] with ETSI NFV.

The advice is that it should be possible to get the capacity of an OpenStack tenant, an user and a resource provider. This is because the NFVO might use different tenants and even different users to manage the resources in the OpenStack instances.

 

Any comments are welcome, also if you need more clarification on the gaps listed in [1] do not hesitate to contact me.

 

Br,

Gerg0

 

[1]: https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained

 


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query

Masahito MUROI
Hi Gerg0,

I added some comments for GAP-04. It looks like NFVO works as an tenant
user and an operator. IMHO, NFVO could calculate the capacity of the cloud.

best regards,
Masahito


On 2017/12/06 22:10, Csatari, Gergely (Nokia - HU/Budapest) wrote:

> Hi,
>
> During the Forum session about the ETSI NFV Gaps I received a request to
> clarify the scope of the capacity query mentioned in [GAP-04] with ETSI NFV.
>
> The advice is that it should be possible to get the capacity of an
> OpenStack tenant, an user and a resource provider. This is because the
> NFVO might use different tenants and even different users to manage the
> resources in the OpenStack instances.
>
> Any comments are welcome, also if you need more clarification on the
> gaps listed in [1] do not hesitate to contact me.
>
> Br,
>
> Gerg0
>
> [1]:
> https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>




__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query

Csatari, Gergely (Nokia - HU/Budapest)
Hi Masahito,

Thanks for the answer.
Some clarification questions. You mention that the NFVO works as both an user and an admin for the cloud. Is this becouse the resource usage per user info is more for cloud operators while the resource usage per tenant / per resource provider is more for cloud users?

The solution you described is valid for the capacity per tenant case if I understand right. Is this correct?

Thanks,
Gerg0

-----Original Message-----
From: Masahito MUROI [mailto:[hidden email]]
Sent: Friday, December 8, 2017 9:44 AM
To: [hidden email]
Subject: Re: [openstack-dev] [etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query

Hi Gerg0,

I added some comments for GAP-04. It looks like NFVO works as an tenant user and an operator. IMHO, NFVO could calculate the capacity of the cloud.

best regards,
Masahito


On 2017/12/06 22:10, Csatari, Gergely (Nokia - HU/Budapest) wrote:

> Hi,
>
> During the Forum session about the ETSI NFV Gaps I received a request
> to clarify the scope of the capacity query mentioned in [GAP-04] with ETSI NFV.
>
> The advice is that it should be possible to get the capacity of an
> OpenStack tenant, an user and a resource provider. This is because the
> NFVO might use different tenants and even different users to manage
> the resources in the OpenStack instances.
>
> Any comments are welcome, also if you need more clarification on the
> gaps listed in [1] do not hesitate to contact me.
>
> Br,
>
> Gerg0
>
> [1]:
> https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-expla
> ined
>
>
>
> ______________________________________________________________________
> ____ OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>




__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query

Jay Pipes
On 12/11/2017 07:24 AM, Csatari, Gergely (Nokia - HU/Budapest) wrote:
> Hi Masahito,
>
> Thanks for the answer.
> Some clarification questions. You mention that the NFVO works as both an user and an admin for the cloud. Is this becouse the resource usage per user info is more for cloud operators while the resource usage per tenant / per resource provider is more for cloud users?
>
> The solution you described is valid for the capacity per tenant case if I understand right. Is this correct?

I think he is more referring to the fact that the MANO/NFVO service user
must have administrative privileges in order to, for example, spawn new
instances in multiple projects/tenants and communicate with the control
plane to do things like adjust quotas, etc.

Best,
-jay

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query

Csatari, Gergely (Nokia - HU/Budapest)
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?

Br,
Gerg0

-----Original Message-----
From: Jay Pipes [mailto:[hidden email]]
Sent: Monday, December 11, 2017 4:41 PM
To: [hidden email]
Subject: Re: [openstack-dev] [etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query

On 12/11/2017 07:24 AM, Csatari, Gergely (Nokia - HU/Budapest) wrote:
> Hi Masahito,
>
> Thanks for the answer.
> Some clarification questions. You mention that the NFVO works as both an user and an admin for the cloud. Is this becouse the resource usage per user info is more for cloud operators while the resource usage per tenant / per resource provider is more for cloud users?
>
> The solution you described is valid for the capacity per tenant case if I understand right. Is this correct?

I think he is more referring to the fact that the MANO/NFVO service user must have administrative privileges in order to, for example, spawn new instances in multiple projects/tenants and communicate with the control plane to do things like adjust quotas, etc.

Best,
-jay

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query

Masahito MUROI
Hi Gerg0 and Jay,

Thanks for the replay. I just mentioned the privilege for MANO/NFVO and
what they can do with the privilege as Jay said.

IMO, MANO/NFVO needs the admin privileges for some operations, e.g.
creating a new tenant/project for a new VNFM or migrating a VM for
failure recovery.

best regards,
Masahito


On 2017/12/12 2:41, 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?
>
> Br,
> Gerg0
>
> -----Original Message-----
> From: Jay Pipes [mailto:[hidden email]]
> Sent: Monday, December 11, 2017 4:41 PM
> To: [hidden email]
> Subject: Re: [openstack-dev] [etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query
>
> On 12/11/2017 07:24 AM, Csatari, Gergely (Nokia - HU/Budapest) wrote:
>> Hi Masahito,
>>
>> Thanks for the answer.
>> Some clarification questions. You mention that the NFVO works as both an user and an admin for the cloud. Is this becouse the resource usage per user info is more for cloud operators while the resource usage per tenant / per resource provider is more for cloud users?
>>
>> The solution you described is valid for the capacity per tenant case if I understand right. Is this correct?
>
> I think he is more referring to the fact that the MANO/NFVO service user must have administrative privileges in order to, for example, spawn new instances in multiple projects/tenants and communicate with the control plane to do things like adjust quotas, etc.
>
> Best,
> -jay
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query

Jay Pipes
In reply to this post by Csatari, Gergely (Nokia - HU/Budapest)
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.

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: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query

Mooney, Sean K


> -----Original Message-----
> From: Jay Pipes [mailto:[hidden email]]
> Sent: Tuesday, December 12, 2017 3:02 PM
> To: [hidden email]
> 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-
> [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev