Hi Srini,
Yes, that's the idea and welcome onboard!
We are planning to give a demo to show the benefits of Istio can bring in to
ONAP such as visibility, routing rule and mutal tls, etc. There is no fixed day
yet, probably at the end of Beijing and the planning phase of Casablanca.
BR,
Huabing
原始邮件
发件人：Addepalli,SrinivasaR <[email protected]>
收件人：赵化冰10201488;[email protected] <[email protected]>
抄送人：[email protected] <[email protected]>
日 期 ：2018年03月14日 23:09
主 题 ：RE: [onap-discuss] Some thoughts about ONAPMicroserviceArchitecture for
Casablanca and beyond: Service Mesh,CentralizedAuthentication and unified API
standards
Hi Huabing,
I agree with you service mesh technologies are best as it takes away majority
of housekeeping work away from the ONAP service developers – Authenticating
peers, Authorization of peers requests, Secure communication (Mutual TLS),
visibility and more.
Great that you intend to show istio demo.
I guess istio.io CA for certificate enrollment will be used and ENVOY proxy for
Mutual TLS endpoint will be leveraged. In security project, we are also
thinking of enabling isito.io CA (some modifications are needed) to take
advantage of HSMs and also providing CA keys security rooted in HW.
When are you planning to show the demo?
Thanks
Srini
From: [email protected]
[mailto:[email protected]] On Behalf Of
[email protected]
Sent: Wednesday, March 14, 2018 1:26 AM
To: [email protected]
Cc: [email protected]
Subject: Re: [onap-discuss] Some thoughts about ONAP MicroserviceArchitecture
for Casablanca and beyond: Service Mesh,Centralized Authentication and unified
API standards
Hi Tal,
Good points.
1. You're right, Istio is still not production ready while service mesh
approach is very promising, We're trying to set up a demo with ONAP to
demonstrate its benefits.
2. I agree that most of the APIs we have now are not "REST", actually
sometimes it's difficult to make the HTTP APIs "100%" REST, but we still need a
standard for all the "HTTP" or "REST-like" APIs to make the APIs more friendly
for the ONAP developers and users. Just feel free to edit the wiki page, it's
an input for improvement:-).
BR,
Huabing
原始邮件
发件人：TalLiron <[email protected]>
收件人：[email protected] <[email protected]>
日 期 ：2018年03月14日 14:06
主 题 ：Re: [onap-discuss] Some thoughts about ONAP MicroserviceArchitecture for
Casablanca and beyond: Service Mesh,Centralized Authentication and unified API
standards
_______________________________________________
onap-discuss mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-discuss
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, <[email protected]> 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
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
[email protected]
https://lists.onap.org/mailman/listinfo/onap-discuss
_______________________________________________
onap-discuss mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-discuss
