Re: [onap-discuss] [msb] Kong 1.0 released

Srini > > > > > > *From:* onap-discuss@lists.onap.org [mailto:onap-discuss@lists.onap.org] *On > Behalf Of *Tal Liron > *Sent:* Monday, October 8, 2018 5:56 AM > *To:* onap-discuss > *Subject:* Re: [onap-discuss] [msb] Kong 1.0 released > > > > I have

Re: [onap-discuss] [msb] Kong 1.0 released

t; > On Tue, Oct 2, 2018 at 12:49 AM Tal Liron wrote: > >> Hi MSB folk, >> >> Kong <https://github.com/Kong/kong> 1.0 was just released. I see it as >> having some overlap with MSB, and it's used quite a lot in the enterprise.

[onap-discuss] [msb] Kong 1.0 released

Hi MSB folk, Kong 1.0 was just released. I see it as having some overlap with MSB, and it's used quite a lot in the enterprise. Perhaps it's worth looking into it as a supplement or replacement? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this

Re: [E] Re: [onap-discuss] [cia] Towards better container images in ONAP

On Sun, Aug 19, 2018 at 5:50 PM Michael Still wrote: > - Create a repo for "official ONAP base images", basing the contents off > what is currently used in OOM -- so for example if there are lots of users > of Ubuntu 16.04, then we just create a ubuntu-lts image in said repo. > Well, I don't

Re: [onap-discuss] [cia] Towards better container images in ONAP

On Fri, Aug 17, 2018 at 2:56 PM Frank Sandoval < frank.sando...@oamtechnologies.com> wrote: > I believe our intent is to define a build chain and rules or guidelines > that all projects use to build their reference images. As a general model > (hopefully not too simplistic), an RI is composed of

Re: [onap-discuss] [cia] Towards better container images in ONAP

On Thu, Aug 9, 2018 at 8:59 PM Keong Lim wrote: > Alpine Linux is prized for container images because it's a very minimal > OS, so the image size is tiny in comparison to other OS images and there is > no "bloat" with unused software packages. This may also help with getting > it passed by each

Re: [onap-discuss] [cia] Towards better container images in ONAP

Our next meeting is Wednesday August 15th at 6:00 pm MT. > > Cheers, > > Adolfo > > > On Aug 9, 2018 13:17, "Tal Liron" wrote: > > Hi everyone, > > My colleague Leif Madsen and I have done some research and I'd like to > present our conclusions as an o

[onap-discuss] [cia] Towards better container images in ONAP

Hi everyone, My colleague Leif Madsen and I have done some research and I'd like to present our conclusions as an opening to discussion. If there's interest in this, we are happy to also do a proof-of-concept to show how this would look in practice. *STATEMENT OF PROBLEM* We all know that ONAP

Re: [onap-discuss] [SO] separate mailing list

I agree strongly with Michael that it's a bad idea. If every project had its own mailing list it would make visibility and participation that much harder. But perhaps we can create a WeChat group for the project to help dev coordination. And I do think we should do something else, though -- have

Re: [onap-discuss] [MSB] [Istio] Try Out Managing ONAP Microservices with Istio Service Mesh

Great initial work and documentation! This shows just how easy it is to add Istio, and that it really is quite transparent from a usability perspective. It seems like you do not implement TLS quite yet, is that correct? Also, I don't see use of VirtualService quite yet. Installing Istio is

Re: [onap-discuss] [cia] Please review and comment on Container Images Best Practices

ando...@oamtechnologies.com > OAM Technologies, representing Arm > OOF committer > > > > On Jul 26, 2018, at 1:54 PM, Tal Liron wrote: > > Hi CIA, > > I just want to mention that Leif and I have made some nice progress > experimenting with buildah on our end. It might take

Re: [E] Re: [onap-discuss] [SO] Weekly Meeting Minutes 7-25-2018

to create any network service with any workflow possible and here is > one way of potentially achieving it in near term, considering present > architecture. > > BR, > Viswa > > <http://www.verizon.com> > > Viswanath Kumar Skand Priya > Senior Architect >

Re: [E] Re: [onap-discuss] [SO] Weekly Meeting Minutes 7-25-2018

w controller logic ( HEAT / any other >format ) should follow existing adapter logic in SO, thereby it is >extendable & scalable. This idea / PoC is actually providing a "friendly" >wrapper on top of BPMN. that's it. > > Hope this sets the stage for future dis

Re: [onap-discuss] [cia] Please review and comment on Container Images Best Practices

Hi CIA, I just want to mention that Leif and I have made some nice progress experimenting with buildah on our end. It might take us another week before we have something substantial to show. We are targeting SO containers for this first experiment. On Tue, Jul 24, 2018 at 5:26 PM Adolfo

Re: [onap-discuss] [SO] Weekly Meeting Minutes 7-25-2018

Hi Steve, At your request I wrote a detailed README describing the solution and the example: https://github.com/tliron/puccini-bpmn/ For convenience, I will reproduce it here: Features The imports directory has everything needed to generate BPMN from TOSCA. Specifically there is bpmn.yaml

Re: [onap-discuss] [SO] Weekly Meeting Minutes 7-25-2018

Hi Seshu, I'm getting numerous private requests for a recording of the meeting. Did you end up recording? On Wed, Jul 25, 2018 at 11:01 AM Tal Liron wrote: > Thank you all for participating in my TOSCA/BPMN demonstration. > > We can continue brainstorming ideas here on the mailing li

Re: [onap-discuss] [SO] Weekly Meeting Minutes 7-25-2018

Thank you all for participating in my TOSCA/BPMN demonstration. We can continue brainstorming ideas here on the mailing list rather than waiting for next week's meeting. In general it's a good idea to use email more for discussion, as it encourages more visibility and participation. On Wed, Jul

Re: [onap-discuss] Dedicated docker build VM

Hi Gary, I just want to point out the new CIA project, where some of us are working to greatly speed up and simplify the container build process. Early tests are very promising. It could still benefit from a dedicated VM, but the whole process would be easier, more scalable, and more configurable.

Re: [onap-discuss] [coe] Today's meeting

On Thu, Jul 19, 2018 at 12:45 PM Victor Morales wrote: > Hey Tal, > > > > This was more a status meeting, I’m going to publish the minutes that I > took later. As you know, we have created the KRD project to offer a > reference deployment of the minimal requirements required for the k8s > plugin

Re: [onap-discuss] [coe] Today's meeting

Hi Victor, sorry I missed this important meeting today. Actually members of my team are some of the key developers of Multus and would love to be involved. I will be sure to join the meeting next week. On Tue, Jul 17, 2018 at 12:34 PM Victor Morales wrote: > Hey there, > > > > Just a reminder

[onap-discuss] ARIA TOSCA has been retired

AriaTosca's Project Management Committee (PMC) has voted unanimously to retire it as an incubation project under the Apache Software Foundation, after six months with no development and all committers having moved on. The source code is still available under the Apache 2.0 license for those who

Re: 答复: [onap-discuss] [SO] is YAML v1.2 supported ?

ment flavor design with only one service template, tosca > v1.1 should be fine. > > > > Regards > > shitao > > > > *发件人**:* onap-discuss@lists.onap.org [mailto:onap-discuss@lists.onap.org] *代表 > *Nguyenphu, Thinh (Nokia - US/Irving) > *发送时间:* 2018年6月26日 19:05 &g

Re: 答复: [onap-discuss] [SO] is YAML v1.2 supported ?

> From TOSCA template consumer perspective, not only SDC/SO should > support that, but also all the consumer of TOSCA template, such as VFC, > etc. we really need to figure out the affected projects. > > > > BR > > Victor > > > > *发件人**:* onap-discuss@lists.ona

Re: [onap-discuss] [SO] is YAML v1.2 supported ?

I think you mean TOSCA 1.2. (YAML 1.2 is supported by most TOSCA parsers.) If you do mean TOSCA 1.2, then it is on the roadmap for Puccini which will soon be tested as a candidate for parsing TOSCA in SO. (It currently supports TOSCA 1.1.) What are the particular TOSCA 1.2 features that you

Re: [onap-discuss] Building blocks for multicloud k8s plugin, RE: [coe] Team meeting Agenda

Hi everyone, I've been following the conversation silently for a while, but it might be time to jump in -- I am working on a training tutorial for Go, for my own team, and would be happy to pass it on to anyone involved in ONAP. It's meant for veterans like you who just need some pointers for

Re: [onap-discuss] [E] TOSCA on Kubernetes: Puccini

Thank you, Kumar, for taking a look and for the good questions. I'll respond with big wall-of-text answers. :) > >- As you had rightly mentioned in your AriaTosca message in >mailinglist, ONAP has already got handful of parsers, including very own >aria and it is not fully integrated

[onap-discuss] TOSCA on Kubernetes: Puccini

Hi folks, I'm happy to finally reveal a project I've been working on for a few months: https://github.com/tliron/puccini The gist of Puccini: 1) Very fast and full-featured stateless TOSCA compiler 2) Targets Kubernetes directly (more targets to come) 3) Finally introduces an "intermediary

Re: [onap-discuss] Some thoughts about ONAPMicroserviceArchitecture for Casablanca and beyond: Service Mesh, CentralizedAuthentication and unified API standards

Or perhaps just "Service Mesh" (SM) project. ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Some thoughts about ONAPMicroserviceArchitecture for Casablanca and beyond: Service Mesh, CentralizedAuthentication and unified API standards

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

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

Sounds good! I will edit it and try to be succinct. On Wed, Mar 14, 2018 at 3:26 AM, wrote: > 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

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

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

[onap-discuss] Re-introduction from Red Hat

Hello ONAP community, I've been assigned to be Red Hat's engineering point of contact for ONAP. I work as a principal engineer in our NFV Partner Engineering team, together with Pasi Vaananen and Frank Zdarsky. Under the broader goal of our commitment to ONAP's success, we are focused on