Standardizing all ONAP management on Kubernetes + Helm + Istio (with its included Prometheus) would go a long way towards taming the beast. :)
By the way, I wonder if "MicroServices Bus" is still a good name for the project at this point. I suggest "MicroServices Mesh" (MSM) if we are indeed going to move in this direction. On Thu, Mar 15, 2018 at 3:19 AM, <[email protected]> wrote: > 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:onap-discuss-bounces@ > lists.onap.org] *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
