Re: [onap-discuss] [onap-tsc] [modeling]Liaison from ONAP modeling subcommittee to ETSI NFV ISG

Hi Deng, In the previous TSC when there was a discussion about liaisons it was pointed out that some work was required as there is no liaison relationship established, I guess that hasn't happened. When it comes to the liaisons that say "please take consideration of my work" they don't mean mu

Re: [onap-discuss] [integration] INT-261: Add standard utilities to all dockers (vim, ping, nslookup)

Hi, I absolutely agree that those tools are a must for development and testing, but they should be included in Docker/VM images before the actual deployment. Thatisthe point of environments where there is no access to the internet - you provide only artifacts that are needed to get the system

[onap-discuss] Usecase subcommittee - agenda for 26/2/2018

Hi all, Here is agenda for the upcoming meeting: 1. Status of Beijing functional requirements development 2. Showcasing of Beijing requirements: discussion with Integration. 3. Discussion - how we make sure in the future (in Casablanca) that requirements are clear, closed an

Re: [onap-discuss] [integration] INT-261: Add standard utilities to all dockers (vim, ping, nslookup)

Piotr’s suggestion is the correct approach. Where possible, base containers should be used that are then used to build other more specific containers, with common tools as needed. Nothing should need to be installed at deployment time, only configured (via environment) through the process of con

Re: [onap-discuss] [integration] INT-261: Add standard utilities to all dockers (vim, ping, nslookup)

Just to mix up the pot a little. The tools being discussed are ones we would use for troubleshooting in production as well. Brian From: SULLIVAN, BRYAN L Sent: Friday, February 23, 2018 9:08 AM To: Bochenski, Piotr (Nokia - PL/Wroclaw) ; Yunxia Chen ; Kang Xi ; PLATANIA, MARCO ; FREEMAN, BRIA

[onap-discuss] Release management process is broken

Hello TSC, Release management team, I just found out our release process is somewhat broken. We should never be tagging snapshot commits as releases, and tags in projects relates to SNAPSHOT. Even more, they are multiple tags pointing to the same SNAPSHOT. I can see they are released artifacts in

Re: [onap-discuss] [integration] INT-261: Add standard utilities to all dockers (vim, ping, nslookup)

Hi, That is indeed a good starting point for a discussion. While I'd opt for having things like 'ping', 'nslookup', etc. in Docker images, I don't much see a real need for having editors, like 'vim'(configuration files shouldn't be used in containerized services and all logs should go to 'std

Re: [onap-discuss] [integration] INT-261: Add standard utilities to all dockers (vim, ping, nslookup)

Got it. Maybe we just keep as it is (option 1)? Running “apt-get install” is not a big issue in my humble opinion when we need it. But if Brian and Kang really need it, option 2: 1. We provide two flavors of containers base, one with tools while another one without. 2. We use the

[onap-discuss] staging nexus repo

Hello, May be I missed communication, but if could you share some advice. I noticed that from 2/8, the staging repo, does not contain the daily release build artifacts (https://nexus.onap.org/content/repositories/staging/

[onap-discuss] [OOM] nameserver issue

Hi Michael I'm using OOM Amsterdam branch and found that the nameserver in each container is configured to 10.43.0.10. This address is unreachable and therefore cause package installation failure in pod like heat-bootstrap- under onap-dcaegen2. I can manually change nameserver to 8.8.8.8 to