subject:"Re\: \[onap\-discuss\] Some thoughts about ONAP Microservice Architecture for Casablanca and beyond\: Service Mesh, Centralized Authentication and unified API standards"

Re: [onap-discuss] Some thoughts about ONAP Microservice Architecture for Casablanca and beyond: Service Mesh, Centralized Authentication and unified API standards

2018-03-20 Thread Parviz Yegani

Thanks Huabing. Sure, you can present it next week.

Thank you
Parviz

---
PARVIZ YEGANI, PhD
Chief SDN/NFV Architect
CTO Office, Cloud Network Solutions

FutureWei Technologies, Inc.
2330 Central Express Way
Santa Clara, CA 95050, USA
Phone: +1 (408) 330-4668
Mobile : +1 (408) 759-1973
parviz.yeg...@huawei.com



From: zhao.huab...@zte.com.cn [mailto:zhao.huab...@zte.com.cn]
Sent: Tuesday, March 20, 2018 1:30 AM
To: Parviz Yegani 
Cc: Christopher Donley (Chris) ; 
onap-arch-tiger-t...@lists.onap.org; onap-discuss@lists.onap.org; 
manoj.k.n...@netcracker.com; alex@intel.com
Subject: Re:RE: Some thoughts about ONAP Microservice Architecture for 
Casablanca and beyond: Service Mesh, Centralized Authentication and unified API 
standards


Hi Parviz,

Is this scheduled for Monday? Sorry I missed it. Could we move it to the next 
call, is that this Friday?

Thanks,

Huabing
Original Mail
Sender: ParvizYegani >
To: zhaohuabing10201488;Christopher Donley(Chris) 
>
CC: 
onap-arch-tiger-t...@lists.onap.org 
>onap-discuss@lists.onap.org
 >Manoj K Nair 
>'Vul, Alex' 
>
Date: 2018/03/19 14:59
Subject: RE: Some thoughts about ONAP Microservice Architecture for Casablanca 
and beyond: Service Mesh, Centralized Authentication and unified API standards
Hi Huabing,

Thanks for launching the discussions on ONAP Microservices architecture. Right 
timing! This is a very important topic that we need to consider for the ONAP 
target  architecture (R3+)!

I added the following item to the agenda for today’s tiger team call:

-  ONAP Microservices Architecture for Casablanca and beyond

Please share your slides prior to the call. I hope Manoj, Alex, Manish and 
other folks who have been quite active in driving this work in ONAP can join 
the call as well.
Thank you
Parviz

---
PARVIZ YEGANI, PhD
Chief SDN/NFV Architect
CTO Office, Cloud Network Solutions

FutureWei Technologies, Inc.
2330 Central Express Way
Santa Clara, CA 95050, USA
Phone: +1 (408) 330-4668
Mobile : +1 (408) 759-1973
parviz.yeg...@huawei.com



From: zhao.huab...@zte.com.cn 
[mailto:zhao.huab...@zte.com.cn]
Sent: Wednesday, March 14, 2018 4:01 AM
To: Parviz Yegani >; 
Christopher Donley (Chris) 
>
Cc: 
onap-arch-tiger-t...@lists.onap.org;
 onap-discuss@lists.onap.org
Subject: Some thoughts about ONAP Microservice Architecture for Casablanca and 
beyond: Service Mesh, Centralized Authentication and unified API standards


Hi all,

I'd like to share some of my thoughts about ONAP Microservice Architecture for 
Casablanca and beyond



1. Service Mesh

Service Mesh is the next generation of Microservice approach, which can bring 
lots of benefits to ONAP and its users at both the development and operation 
sides. Such as

· the separation of business logic and Microservice 
infrastructure(communication, security, metrics etc)

· allowing free choice of development tech stack

· flexible route rules to enable traffic steering and canary release

· monitoring and tracing visibility

· fault injection for resiliency testing, etc

We should take service mesh into consideration. There are multiple choices on 
the table right now, given its tight relationship with kubernetes which is used 
for ONAP deployment, I suggest we give Istio a shot in Casablanca. MSB project 
is investigating  the possibility of integration of Istio and ONAP right now.



2. Centralized Authentication

ONAP is a huge system consisting of many services. Currently, different 
services such as AAI, SDC, Policy etc. have their own authentication process, 
which makes ONAP difficult to use and adds burden to the individual project to 
enforce the cross-project  authentication logic. We need to consider 
implementing some kind of centralized authentication, which means user login 
once and can access all the services. We also need to consider how to secure 
the access of 3-party systems by using API token or OAuth.



3. Unified API standard

Most of the projects produce RESTFul APIs for consuming, but in a 
none-consistent way. we need to define some unified standards/best practices on 
the REST API definition across the ONAP projects

Re: [onap-discuss] Some thoughts about ONAP Microservice Architecture for Casablanca and beyond: Service Mesh, Centralized Authentication and unified API standards

2018-03-19 Thread zhao.huabing

Hi Parviz,


Is this scheduled for Monday? Sorry I missed it. Could we move it to the next 
call, is that this Friday?


Thanks,


Huabing







Original Mail



Sender: ParvizYegani 
To: zhaohuabing10201488;Christopher Donley(Chris) 

CC: onap-arch-tiger-t...@lists.onap.org 
onap-discuss@lists.onap.org 
Manoj K Nair 'Vul, 
Alex' 
Date: 2018/03/19 14:59
Subject: RE: Some thoughts about ONAP Microservice Architecture for Casablanca 
and beyond: Service Mesh, Centralized Authentication and unified API standards 




Hi Huabing,


 


Thanks for launching the discussions on ONAP Microservices architecture. Right 
timing! This is a very important topic that we need to consider for the ONAP 
target  architecture (R3+)!


 


I added the following item to the agenda for today’s tiger team call:


-  ONAP Microservices Architecture for Casablanca and beyond

Please share your slides prior to the call. I hope Manoj, Alex, Manish and 
other folks who have been quite active in driving this work in ONAP can join 
the call as well.


Thank you


Parviz


 


---


PARVIZ YEGANI, PhD 
Chief SDN/NFV Architect


CTO Office, Cloud Network Solutions


 


FutureWei Technologies, Inc.


2330 Central Express Way


Santa Clara, CA 95050, USA


Phone: +1 (408) 330-4668


Mobile : +1 (408) 759-1973


parviz.yeg...@huawei.com 


 


 


 


From: zhao.huab...@zte.com.cn [mailto:zhao.huab...@zte.com.cn] 
 Sent: Wednesday, March 14, 2018 4:01 AM
 To: Parviz Yegani ; Christopher Donley (Chris) 

 Cc: onap-arch-tiger-t...@lists.onap.org; onap-discuss@lists.onap.org
 Subject: Some thoughts about ONAP Microservice Architecture for Casablanca and 
beyond: Service Mesh, Centralized Authentication and unified API standards 


 

Hi all,

I'd like to share some of my thoughts about ONAP Microservice Architecture for 
Casablanca and beyond

 

1. Service Mesh

Service Mesh is the next generation of Microservice approach, which can bring 
lots of benefits to ONAP and its users at both the development and operation 
sides. Such as 


· the separation of business logic and Microservice 
infrastructure(communication, security, metrics etc)


· allowing free choice of development tech stack


· flexible route rules to enable traffic steering and canary release


· monitoring and tracing visibility


· fault injection for resiliency testing, etc

We should take service mesh into consideration. There are multiple choices on 
the table right now, given its tight relationship with kubernetes which is used 
for ONAP deployment, I suggest we give Istio a shot in Casablanca. MSB project 
is investigating  the possibility of integration of Istio and ONAP right now. 

 

2. Centralized Authentication

ONAP is a huge system consisting of many services. Currently, different 
services such as AAI, SDC, Policy etc. have their own authentication process, 
which makes ONAP difficult to use and adds burden to the individual project to 
enforce the cross-project  authentication logic. We need to consider 
implementing some kind of centralized authentication, which means user login 
once and can access all the services. We also need to consider how to secure 
the access of 3-party systems by using API token or OAuth.

 

3. Unified API standard

Most of the projects produce RESTFul APIs for consuming, but in a 
none-consistent way. we need to define some unified standards/best practices on 
the REST API definition across the ONAP projects such as versioning, url, error 
code.  There is a draft in the  wiki page: 
https://wiki.onap.org/display/DW/RESTful+API+Design+Specification

BR,

Huabing___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Some thoughts about ONAP Microservice Architecture for Casablanca and beyond: Service Mesh, Centralized Authentication and unified API standards

2018-03-19 Thread zhao.huabing

Sure, I'll send out the slides later today before our call.











Original Mail



Sender: ParvizYegani 
To: zhaohuabing10201488;Christopher Donley(Chris) 

CC: onap-arch-tiger-t...@lists.onap.org 
onap-discuss@lists.onap.org 
Manoj K Nair 'Vul, 
Alex' 
Date: 2018/03/19 14:59
Subject: RE: Some thoughts about ONAP Microservice Architecture for Casablanca 
and beyond: Service Mesh, Centralized Authentication and unified API standards 




Hi Huabing,


 


Thanks for launching the discussions on ONAP Microservices architecture. Right 
timing! This is a very important topic that we need to consider for the ONAP 
target  architecture (R3+)!


 


I added the following item to the agenda for today’s tiger team call:


-  ONAP Microservices Architecture for Casablanca and beyond

Please share your slides prior to the call. I hope Manoj, Alex, Manish and 
other folks who have been quite active in driving this work in ONAP can join 
the call as well.


Thank you


Parviz


 


---


PARVIZ YEGANI, PhD 
Chief SDN/NFV Architect


CTO Office, Cloud Network Solutions


 


FutureWei Technologies, Inc.


2330 Central Express Way


Santa Clara, CA 95050, USA


Phone: +1 (408) 330-4668


Mobile : +1 (408) 759-1973


parviz.yeg...@huawei.com 


 


 


 


From: zhao.huab...@zte.com.cn [mailto:zhao.huab...@zte.com.cn] 
 Sent: Wednesday, March 14, 2018 4:01 AM
 To: Parviz Yegani ; Christopher Donley (Chris) 

 Cc: onap-arch-tiger-t...@lists.onap.org; onap-discuss@lists.onap.org
 Subject: Some thoughts about ONAP Microservice Architecture for Casablanca and 
beyond: Service Mesh, Centralized Authentication and unified API standards 


 

Hi all,

I'd like to share some of my thoughts about ONAP Microservice Architecture for 
Casablanca and beyond

 

1. Service Mesh

Service Mesh is the next generation of Microservice approach, which can bring 
lots of benefits to ONAP and its users at both the development and operation 
sides. Such as 


· the separation of business logic and Microservice 
infrastructure(communication, security, metrics etc)


· allowing free choice of development tech stack


· flexible route rules to enable traffic steering and canary release


· monitoring and tracing visibility


· fault injection for resiliency testing, etc

We should take service mesh into consideration. There are multiple choices on 
the table right now, given its tight relationship with kubernetes which is used 
for ONAP deployment, I suggest we give Istio a shot in Casablanca. MSB project 
is investigating  the possibility of integration of Istio and ONAP right now. 

 

2. Centralized Authentication

ONAP is a huge system consisting of many services. Currently, different 
services such as AAI, SDC, Policy etc. have their own authentication process, 
which makes ONAP difficult to use and adds burden to the individual project to 
enforce the cross-project  authentication logic. We need to consider 
implementing some kind of centralized authentication, which means user login 
once and can access all the services. We also need to consider how to secure 
the access of 3-party systems by using API token or OAuth.

 

3. Unified API standard

Most of the projects produce RESTFul APIs for consuming, but in a 
none-consistent way. we need to define some unified standards/best practices on 
the REST API definition across the ONAP projects such as versioning, url, error 
code.  There is a draft in the  wiki page: 
https://wiki.onap.org/display/DW/RESTful+API+Design+Specification

BR,

Huabing___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Some thoughts about ONAP Microservice Architecture for Casablanca and beyond: Service Mesh, Centralized Authentication and unified API standards

2018-03-19 Thread Parviz Yegani

Hi Huabing,

Thanks for launching the discussions on ONAP Microservices architecture. Right 
timing! This is a very important topic that we need to consider for the ONAP 
target architecture (R3+)!

I added the following item to the agenda for today’s tiger team call:

-  ONAP Microservices Architecture for Casablanca and beyond

Please share your slides prior to the call. I hope Manoj, Alex, Manish and 
other folks who have been quite active in driving this work in ONAP can join 
the call as well.
Thank you
Parviz

---
PARVIZ YEGANI, PhD
Chief SDN/NFV Architect
CTO Office, Cloud Network Solutions

FutureWei Technologies, Inc.
2330 Central Express Way
Santa Clara, CA 95050, USA
Phone: +1 (408) 330-4668
Mobile : +1 (408) 759-1973
parviz.yeg...@huawei.com



From: zhao.huab...@zte.com.cn [mailto:zhao.huab...@zte.com.cn]
Sent: Wednesday, March 14, 2018 4:01 AM
To: Parviz Yegani ; Christopher Donley (Chris) 

Cc: onap-arch-tiger-t...@lists.onap.org; onap-discuss@lists.onap.org
Subject: Some thoughts about ONAP Microservice Architecture for Casablanca and 
beyond: Service Mesh, Centralized Authentication and unified API standards


Hi all,

I'd like to share some of my thoughts about ONAP Microservice Architecture for 
Casablanca and beyond



1. Service Mesh

Service Mesh is the next generation of Microservice approach, which can bring 
lots of benefits to ONAP and its users at both the development and operation 
sides. Such as

· the separation of business logic and Microservice 
infrastructure(communication, security, metrics etc)

· allowing free choice of development tech stack

· flexible route rules to enable traffic steering and canary release

· monitoring and tracing visibility

· fault injection for resiliency testing, etc

We should take service mesh into consideration. There are multiple choices on 
the table right now, given its tight relationship with kubernetes which is used 
for ONAP deployment, I suggest we give Istio a shot in Casablanca. MSB project 
is investigating the possibility of integration of Istio and ONAP right now.



2. Centralized Authentication

ONAP is a huge system consisting of many services. Currently, different 
services such as AAI, SDC, Policy etc. have their own authentication process, 
which makes ONAP difficult to use and adds burden to the individual project to 
enforce the cross-project authentication logic. We need to consider 
implementing some kind of centralized authentication, which means user login 
once and can access all the services. We also need to consider how to secure 
the access of 3-party systems by using API token or OAuth.



3. Unified API standard

Most of the projects produce RESTFul APIs for consuming, but in a 
none-consistent way. we need to define some unified standards/best practices on 
the REST API definition across the ONAP projects such as versioning, url, error 
code.  There is a draft in the wiki page: 
https://wiki.onap.org/display/DW/RESTful+API+Design+Specification

BR,

Huabing
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Some thoughts about ONAP Microservice Architecture for Casablanca and beyond: Service Mesh, Centralized Authentication and unified API standards

2018-03-14 Thread Tal Liron

Hi Huabing,

1.

We have some good experience with Itsio and would love to be part of the
conversation. It's one of the things we're looking at, too, in terms of
improving ONAP's currently basic containerization. We are starting by
looking at OOM but hope to find best practices that could work for all
projects. I think it's better to convince with a PoC rather than theory in
this case, because Itsio is indeed quite new, sometimes hard to explain,
but its benefits are clear when you see them in use.

3.

In terms of our "RESTful" APIs -- this has been a pet peeve of mine for a
long time, but I wish we would stop calling all our APIs RESTful, when in
fact they are rarely RESTful in our project. They are simply "HTTP" (or
"web") APIs. "CRUD" does not map very well onto REST. That said, I applaud
your proposal and it has many good points. But I would like to make a few
comments:

I would add this emphasis: readers should pay attention to the use of POST
for "create". I've seen many frameworks recommend PUT for "create", which
is definitely wrong (not exactly: more on that below). POST is the only
non-idempotent HTTP verb, and as such will guarantee atomicity: the
resource will not be created twice, even being a proxy.

However, using PUT for "update" is imprecise. Especially your comment that
if the resource does not exist then PUT would return an error. Here is the
description of PUT from the HTTP spec:

"The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. If the Request-URI refers to an already existing
resource, the enclosed entity SHOULD be considered as a modified version of
the one residing on the origin server. If the Request-URI does not point to
an existing resource, and that URI is capable of being defined as a new
resource by the requesting user agent, the origin server can create the
resource with that URI. If a new resource is created, the origin server
MUST inform the user agent via the 201 (Created) response."

So, as you see, PUT is also a kind of "create". But because PUT is
idempotent, you definitely don't want to support PUT on "/pets/dogs". But
PUT on "/pets/dogs/bailey" should work. (Even if the request is sent
several times, it would create/update the same resource, so idempotency is
honored).

What does it mean that there are two ways to "create" the resource?
Actually, they are different. When you POST to "/pets/dogs" you do not yet
know the ID of the dog. The ID would be created for you (once and only
once) and returned in the response. However, in some cases you know in
advance the ID of the object, in which case you should PUT to
"/pets/dogs/ID". Then, you would know if it was created by checking the
status code: 200 for modified or 201 for created. (Though note that it's
not a good idea to functionally rely on this distinction: because PUT is
idempotent, there is a chance that more than one client would get the 201
response in the case of caching proxies.)

As for APIs that are not CRUD-like, it's important for the designer to
think twice before using POST, because POST is the least scalable verb (it
can never be cached). Ask yourself: what would happen if the API got called
more than once with exactly the same request content? If the answer is "bad
things", then definitely use POST. (All classic RPC-like "function calls"
on web APIs should basically use POST.) For all other cases, use PUT or GET
as appropriate.

Finally, for your section on HTTP status codes, I would add this emphasis:
make sure never to return 2XX series success codes in case of an error.
I've seen APIs return 200 with an error code inside the JSON response. This
makes exception handling on the client side inconsistent and can lead to
bugs.

If we want to do this right, I would go even further and make sure to 1)
return client caching headers (maxAge, etag, etc.) with every response
where appropriate, and 2) try to use HTTP clients that support client-side
caching. (A good caching proxy would do it for you, too.)

If we work with HTTP instead of against it we will improve the scalability
and reliability of the project because all the compliant
proxies/gateways/loadbalancers/caches along the way will do the right thing
for us.

On Tue, Mar 13, 2018 at 11:00 PM,  wrote:

> Hi all,
>
> I'd like to share some of my thoughts about ONAP Microservice Architecture
> for Casablanca and beyond
>
>
> 1. Service Mesh
>
> Service Mesh is the next generation of Microservice approach, which can
> bring lots of benefits to ONAP and its users at both the development and
> operation sides. Such as
>
>-
>
>the separation of business logic and Microservice
>infrastructure(communication, security, metrics etc)
>-
>
>allowing free choice of development tech stack
>-
>
>flexible route rules to enable traffic steering and canary release
>-
>
>monitoring and tracing visibility
>-
>
>fault injection for resiliency testing, etc
>
>

Re: [onap-discuss] Some thoughts about ONAP Microservice Architecture for Casablanca and beyond: Service Mesh, Centralized Authentication and unified API standards

Re: [onap-discuss] Some thoughts about ONAP Microservice Architecture for Casablanca and beyond: Service Mesh, Centralized Authentication and unified API standards

Re: [onap-discuss] Some thoughts about ONAP Microservice Architecture for Casablanca and beyond: Service Mesh, Centralized Authentication and unified API standards

Re: [onap-discuss] Some thoughts about ONAP Microservice Architecture for Casablanca and beyond: Service Mesh, Centralized Authentication and unified API standards

Re: [onap-discuss] Some thoughts about ONAP Microservice Architecture for Casablanca and beyond: Service Mesh, Centralized Authentication and unified API standards

5 matches

Site Navigation

Mail list logo

Footer information