[onap-tsc] ONAP Demo Ideas Needed by Feb 13

[Brandon Wick]

Dear ONAP Community:

We have not yet received any ONAP-focused demos for the LFN Booth at ONS.
Last year, the multiple ONAP demos were some of the popular and
well-trafficked in the booth. If you have an idea for an ONAP demo, please
send an email with the requisite info detailed below or let us know if you
need more time. Thanks!

Best,

Brandon

-- Forwarded message -
From: Brandon Wick 
Date: Fri, Feb 1, 2019 at 5:20 PM
Subject: REMINDER: LFN Booth Demo Ideas for ONS Due Feb 13
To:



-- Forwarded message -
From: Brandon Wick 
Date: Wed, Jan 16, 2019 at 10:52 PM
Subject: Seeking LFN Booth Demo Ideas for ONS North America
To:

LFN Community:

Those in attendance at OSN North America in Los Angeles last March and ONS
Europe in Amsterdam last September will recall that we hosted an *LF
Networking Booth* that showcased 8-10 compelling, community-driven
demos from the LFN technical projects. See this blog post

for
a description of the ONS North America booth demos, and this blog post

for the ONS Europe demos.

We wanted to reach out now to each of the LFN project communities to let
you know that there will be space for 8-10 networking demos inside the LFN
booth again at ONS North America (San Jose, April 4-6) and we are seeking
demo ideas using the same process. Our goal is to show compelling uses of
LFN networking project technology to solve real world industry challenges.

Demos that show cross-project elements (e.g. between LFN projects and other
networking projects), that map to a specific industry use case, or are
endorsed by a service provider are preferred. That said, we have some room
for demos that highlight the good work and value-add from projects that
don't necessarily meet these criteria. At least one demo slot will be made
available for each LFN project (FD.io, ONAP, ODL, OPNFV, PNDA, SNAS,
Tungsten Fabric) that submits a quality idea.

Demos stations will again have storage space, a counter, backdrop, monitor,
power, and Wi-Fi internet provided. There is no cost to host a demo in the
LFN booth although additional power, internet, space, etc. may incur a
cost.

Here are the key dates to keep in mind:

   - Jan 16: Demo idea solicitation email sent to community lists
   - *Feb 13: Demo ideas submissions due*
   - Feb 27: Demos ideas reviewed, chosen, and notifications sent
   - April 4-6: Demos shown

To submit your demo idea for consideration, please collect and provide the
following information:

   - Demo title (10 words max)
   - Brief demo description (200 words max)
   - List of demo manager(s) with contact information
   - List of open source projects involved
   - List of companies involved
   - Any extra requirements or special considerations

Demo manager responsibilities include:

   - Creating the demo concept and actual demo to be shown
   - Responding promptly to requests for information
   - Meeting all demo preparation deadlines
   - Setting up and testing the demo pre-show and taking down post-show
   - Staffing the demo during ONS expo hours (along with other designated
   team members to help share the load)
   - Being willing to participate in media activities, e.g. photos, videos

ONS sponsor companies are of course welcome to host demos in their booths
on the show floor as well. Please check with your ONS sponsorship manager
to explore these opportunities.

*Submit your demo ideas by February 13 by sending an email
to bw...@linuxfoundation.org *. LFN staff
leadership (Heather, Phil, Arpit) will then review the submissions, get
back to submitters with questions, suggestions, and recommend a final demo
roster by Feb 27th. Send any questions you may have to
bw...@linuxfoundation.org.

We look forward to seeing your demo ideas.

Best,

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
bw...@linuxfoundation.org
+1.917.282.0960

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4615): https://lists.onap.org/g/onap-tsc/message/4615
Mute This Topic: https://lists.onap.org/mt/29747215/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[onap-tsc] Committer promotion requests for Integration

[Yang Xu]

Dear TSC,

Integration team has voted to promote Brian Freeman (5/5 votes) and Mariusz 
Wagner(4/5 votes) to Integration committers. Please see their promotion 
requests here:

https://wiki.onap.org/display/DW/Integration+Committer+Promotion+Requests+for+Brian+Freemam
https://wiki.onap.org/display/DW/Integration+Committer+Promotion+Requests+for+Mariusz+Wagner

Best regards,

-Yang Xu
Integration PTL



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4614): https://lists.onap.org/g/onap-tsc/message/4614
Mute This Topic: https://lists.onap.org/mt/29747106/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[onap-tsc] ONAP DockerHub migration for docker image releases

[Jessica Wagantall]

Dear ONAP team,

I would like to announce that we are working on a migration for docker
images from Nexus3 to DockerHub.
The main motivation to do so is to allow teams to move towards a model that
will easily allow them to manage their own docker image releases more
independently.

We have several task in progress, and I would like to summarize them here:

   - LF is working on 2 new global-jjb templates for docker verify and
   docker merge.
   - The merge job will post Snapshot and Staging images directly into
   DockerHub.
   - Releases to DockerHub will be made on demand as PTLs wish.
   - For now, only PTLs will be given these permissions, but extended
   permissions to committers will be considered as we go.
   - The process to release will be done manually by PTLs similarly to how
   LF does it (docker pull image, docker tag using release tag #.#.#, docker
   push to DockerHub).
   - We will work with tech teams to move to the new docker templates in
   global-jjb and eventually remove local templates.
   - To avoid overhead, we will only be making DockerHub publications of
   Snapshots and Staging artifacts on new merge and not on a daily basis. (We
   want to minimize the resource usage and avoid re-pushing the same image if
   it has not changed).
   - We are going to work on making this transition smooth and switch to
   the new global-jjb jobs once it is confirmed by tech teams that the correct
   images are being posted in DockerHub. This means that some teams might have
   both jobs pushing to Nexus3 and DockerHub at the same time and will be able
   to disable Nexus3 pushes once they are comfortable.


As mentioned, LF has started working towards this model and we will let he
community know on every milestone.

As a first step for the community, particularly PTLs:
Can we please request all PTLs to register into DockerHub and update their
DockerHub ID in wiki.onap.org/display/DW/Resources+and+Repositories so that
LF can proceed and open the permissions please?

Thanks a ton!
Jess

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4613): https://lists.onap.org/g/onap-tsc/message/4613
Mute This Topic: https://lists.onap.org/mt/29745845/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-discuss] [onap-tsc] Ubuntu and Alpine discussion

[Tal Liron]

On Mon, Feb 11, 2019, 11:04 Brian  I dont think Disk space is really the main issue – its size of the image
> to download and boot and the memory consumption in the running image.
>
Well, again, if there's a single base then you are only downloading the
delta.

>  We arent running into issues with disk space in our environment but
> rather in memory consumption and to some extent the container init delays.
>
That *should* have nothing to do with the os. Even if the base image has
bloat, then of course that bloat won't load into memory unless you use it.

ONAP images have a lot of init problems, but I doubt this has to do with
packaging. I see a lot of services starting a lot of network chatter and
logging while they try to hit other services that have not come up yet.
This can be mitigated with Envoy/Istio, but ultimately is a design problem
of that particular service.


> *From:* onap-tsc@lists.onap.org  *On Behalf Of *Tal
> Liron
> *Sent:* Monday, February 11, 2019 11:56 AM
> *To:* onap-discuss ; DESBUREAUX Sylvain
> TGI/OLN 
> *Cc:* Chaker Al Hakim ;
> srinivasa.r.addepa...@intel.com; onap-tsc@lists.onap.org
> *Subject:* Re: [onap-discuss] [onap-tsc] Ubuntu and Alpine discussion
>
>
>
> This conversation has gotten a little bit confusing. Let me try to
> organize and separate the core issues:
>
>1. Disk space. If we want to reduce the ridiculous storage
>requirements for ONAP's container images, the solution is not to choose a
>tiny Linux distribution. Rather, the solution is to choose a single (or
>small set of) base image(s) for all ONAP container images. Because images
>are stored as deltas from the derived base image, then the size of that
>base image is quite negligible.
>2. Choice of base distribution. ONAP provides reference images, but in
>the end production operations will very likely build their own after
>auditing selections of packages and even the source code. The ONAP project
>can make a best effort to pre-audit the selection, but in the end cannot
>provide neither a guarantee nor a warranty. That comes from the operating
>system vendor and other software vendors of packages like MariaDB, MongoDB,
>JDK, etc. The ONAP project should make it possible (and better yet: easy)
>for users to make that choice. I understand this as one of the goals of our
>CIA project. I think there's also some misunderstanding of the
>supportability of packages within the containers. Here's an example: if
>your host operating system is RHEL, but your container image is based on
>Alpine, then Red Hat cannot support any security vulnerabilities in those
>Alpine libraries. This includes OpenSSL as well as glib, systemd, etc. In
>the end, whatever ONAP chooses as base image is arbitrary as long as we
>allow users to make their own choice.
>3. Technical dependencies on specific distributions. Does a certain
>ONAP image build against a specific version of a library included in a
>specific version of a specific distribution? This should be considered a
>bug, because it exactly disallows the freedom of users to choose a base
>distribution. Not only that, but it's a guarantee for maintenance
>nightmares in the future. What happens if the next version of that specific
>distribution changes the library? Who will make sure to refactor and allow
>for an upgrade of the base? And if you can't upgrade the base, the image
>will be stuck with an older and possibly broken/insecure library. There are
>many open source project plagued with this problem, e.g. stuck on Ubuntu
>14.04. We need to make sure that we minimize these dependencies. There's
>also the option of building that specific dependency library from source
>for that ONAP image, but again we limit the ability for users to get
>support from a vendor.
>
> There are some complications regarding point #3 that should be discussed.
> For example, many Linux distributions have switched to systemd in recent
> years, and that causes a major change in how they run (e.g. that's one main
> reason projects stuck on Ubuntu 14.04 have difficulty moving forward). If
> systemd is considered a standard for ONAP, then that limits the number of
> possible choices for base image. Likewise SELinux. We need to examine ONAP
> as a whole and make a list of these basic technical requirements from a
> base distribution.
>
>
>
> On Mon, Feb 11, 2019 at 10:08 AM Sylvain Desbureaux <
> sylvain.desbure...@orange.com> wrote:
>
> Hello Chaker,
>
>
>
> Today,
>
> The docker building image process of ONAP is at the very least messy
> (Morgan did a presentation at TSC meeting last Thursday on this point
> https://wiki.onap.org/pages/viewpage.action?pageId=6593670=/6593670/54722733/onap_tests.pdf
> 

Re: [E] Re: [onap-discuss] [onap-tsc] Ubuntu and Alpine discussion

[Adolfo Perez-Duran]

Thanks Manoop,

I will add an item to our agenda to make the team aware of this.

Adolfo


On Mon, Feb 11, 2019, 12:11 Manoop Talasila 
wrote:

> Hello ONAP CIA,
>
>
>
> The “docker-slim” method seems to be another optimization mechanism which
> supposedly reduces image size with no changes on ONAP dockerFiles. Please
> verify, if we can consider this method in addition to other optimization
> mechanisms in the overall proposed efforts for Dublin by CIA here
> .
> Thanks.
>
>
>
> https://github.com/docker-slim/docker-slim (Apache 2 licensed)
>
>
>
> Some basics on what and how docker-slim works -
>
> *Don't change anything in your Docker container image and minify it by up
> to 30x making it secure too!*
>
>
>
> *docker-slim will optimize and secure your containers by understanding
> your application and what it needs using various analysis techniques. It
> will throw away what you don't need reducing the attack surface for your
> container. What if you need some of those extra things to debug your
> container? You can use dedicated debugging side-car containers for that
> (more details below).*
>
>
>
> *docker-slim has been used with Node.js, Python, Ruby, Java, Golang, Rust,
> Elixir and PHP (some app types) running on Ubuntu, Debian and Alpine Linux*
>
>
>
> *Minification Examples*
>
> *Node.js application images:*
>
> *from ubuntu:14.04 - 432MB => 14MB (minified by 30.85X)*
>
> *from debian:jessie - 406MB => 25.1MB (minified by 16.21X)*
>
> *from node:alpine - 66.7MB => 34.7MB (minified by 1.92X)*
>
>
>
> *Python application images:*
>
> *from ubuntu:14.04 - 438MB => 16.8MB (minified by 25.99X)*
>
> *from python:2.7-alpine - 84.3MB => 23.1MB (minified by 3.65X)*
>
> *from python:2.7.15 - 916MB => 27.5MB (minified by 33.29X)*
>
>
>
> *JAVA application images:*
>
> *from ubuntu:14.04 - 743.6 MB => 100.3 MB*
>
>
> --
>
>
>
> Manoop
>
>
>
> *From: * on behalf of "Viswanath Kumar Skand
> Priya via Lists.Onap.Org"  verizon@lists.onap.org>
> *Reply-To: *"onap-disc...@lists.onap.org" , "
> viswanath.kumarskandpr...@verizon.com" <
> viswanath.kumarskandpr...@verizon.com>
> *Date: *Monday, February 11, 2019 at 12:55 PM
> *To: *"onap-tsc@lists.onap.org" , onap-discuss <
> onap-disc...@lists.onap.org>, DESBUREAUX Sylvain TGI/OLN <
> sylvain.desbure...@orange.com>
> *Cc: *Chaker Al Hakim , "
> srinivasa.r.addepa...@intel.com" 
> *Subject: *Re: [E] Re: [onap-discuss] [onap-tsc] Ubuntu and Alpine
> discussion
>
>
>
> Looks like I have arrived late to the party, but still want to add my 2
> cents.
>
>
>
> I agree with Tal 100% . If the assumption is that, the docker images
> available in ONAP nexus repo will be directly used in production, that
> that’s a total invalid assumption. As Tal pointed out, the choice of
> distribution matters.  The goal here should be making ONAP Build success
> without any intrinsic dependencies / assumptions about OS distribution &
> specific builds of DBs & other deps.
>
>
>
> I feel all the previous discussions on this thread is geared towards
> simplifying community builds & speeding the download time for bringing up
> ONAP for a lab / poc / demo. This would only make ONAP stay in reference
> implementation level .
>
>
>
> IMHO, we as a community should focus on making ONAP Build from scratch
> with minimum set of deps. If CIA is already working on that direction,
> please disregard my 2 cents.
>
>
>
> Thank you!
>
>
>
> BR,
>
> Viswa
>
>
>
>
>
> *From: * on behalf of Tal Liron <
> tli...@redhat.com>
> *Reply-To: *"onap-tsc@lists.onap.org" 
> *Date: *Monday, February 11, 2019 at 10:56 AM
> *To: *onap-discuss , DESBUREAUX Sylvain
> TGI/OLN 
> *Cc: *Chaker Al Hakim , "
> srinivasa.r.addepa...@intel.com" , "
> onap-tsc@lists.onap.org" 
> *Subject: *[E] Re: [onap-discuss] [onap-tsc] Ubuntu and Alpine discussion
>
>
>
> This conversation has gotten a little bit confusing. Let me try to
> organize and separate the core issues:
>
>1. Disk space. If we want to reduce the ridiculous storage
>requirements for ONAP's container images, the solution is not to choose a
>tiny Linux distribution. Rather, the solution is to choose a single (or
>small set of) base image(s) for all ONAP container images. Because images
>are stored as deltas from the derived base image, then the size of that
>base image is quite negligible.
>2. Choice of base distribution. ONAP provides reference images, but in
>the end production operations will very likely build their own after
>auditing selections of packages and even the source code. The ONAP project
>can make a best effort to pre-audit the selection, but in the end cannot
>provide neither a guarantee nor a warranty. That comes from the operating
>system 

Re: [onap-tsc] Footprint optimization - Testing Strategy #Dublin

[Catherine LEFEVRE]

Dear TSC (or proxy),

Please read "the Integration Team should certify any optimization improvement 
(if any) that will be available at RC0 (or earlier)" as
"The Integration Team will use any of these containers that include these 
optimization improvements (if any) and that are available at RC0 (or earlier) 
for their Integration testing"

Best regards
Catherine

From: Lefevre, Catherine
Sent: Monday, February 11, 2019 7:13 PM
To: 'onap-rele...@lists.onap.org' ; 
'onap-tsc@lists.onap.org' 
Subject: Footprint optimization - Testing Strategy #Dublin

Dear TSC (or proxy),

As you know the Footprint optimization including Container optimization, 
Component/memory optimization, Global optimization (e.g. shared DB) is a 
non-functional requirement that we have marked as "Dublin Release - TSC Must 
Have".
The Footprint optimization is currently under M1 Conditional because the Dublin 
Testing Strategy is not yet clarified.
Our aim goal is to reduce the size of our containers.

In order to get the benefits from the Footprint Optimization work, the 
Integration Team should certify any optimization improvement (if any) that will 
be available at RC0 (or earlier).
We do not anticipate any additional Jenkins job - the expectations is that the 
PTL will improve the current build of the container including any optimization 
improvement i.e. size/memory etc.

I hope this e-mail clarifies the way how to move forward with our ONAP Dev. 
Project Teams and our ONAP Integration Team.

Best regards
Catherine

Catherine Lefèvre
AVP Software Development & Engineering

AT Labs - Network Cloud & Infrastructure
D2 Platform & Systems Development
ECOMP/RUBY/SPP-NEAM-Appl. Servers/SIA
ONAP TSC Chair


Phone: +32 81 84 09 08
Mobile: +32 475 77 36 73
catherine.lefe...@intl.att.com

TEXTING and DRIVING... It Can Wait

AT
BUROGEST OFFICE PARK SA
Avenue des Dessus-de-Lives, 2
5101 Loyers (Namur)
Belgium



NOTE: This email (or its attachments) contains information belonging to the 
sender, which may be confidential. proprietary and/or legally privileged. The 
information is intended only for the use of the individual(s) or entity(ies) 
named above. If you are not the intended recipient, you are hereby notified 
that any disclosure, distribution or taking of any action in reliance on the 
content of this is strictly forbidden. If you have received this e-mail in 
error please immediately notify the sender identified above


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4606): https://lists.onap.org/g/onap-tsc/message/4606
Mute This Topic: https://lists.onap.org/mt/29737916/21656
Mute #dublin: https://lists.onap.org/mk?hashtag=dublin=2743226
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[onap-tsc] Footprint optimization - Testing Strategy #Dublin

[Catherine LEFEVRE]

Dear TSC (or proxy),

As you know the Footprint optimization including Container optimization, 
Component/memory optimization, Global optimization (e.g. shared DB) is a 
non-functional requirement that we have marked as "Dublin Release - TSC Must 
Have".
The Footprint optimization is currently under M1 Conditional because the Dublin 
Testing Strategy is not yet clarified.
Our aim goal is to reduce the size of our containers.

In order to get the benefits from the Footprint Optimization work, the 
Integration Team should certify any optimization improvement (if any) that will 
be available at RC0 (or earlier).
We do not anticipate any additional Jenkins job - the expectations is that the 
PTL will improve the current build of the container including any optimization 
improvement i.e. size/memory etc.

I hope this e-mail clarifies the way how to move forward with our ONAP Dev. 
Project Teams and our ONAP Integration Team.

Best regards
Catherine

Catherine Lefèvre
AVP Software Development & Engineering

AT Labs - Network Cloud & Infrastructure
D2 Platform & Systems Development
ECOMP/RUBY/SPP-NEAM-Appl. Servers/SIA
ONAP TSC Chair


Phone: +32 81 84 09 08
Mobile: +32 475 77 36 73
catherine.lefe...@intl.att.com

TEXTING and DRIVING... It Can Wait

AT
BUROGEST OFFICE PARK SA
Avenue des Dessus-de-Lives, 2
5101 Loyers (Namur)
Belgium



NOTE: This email (or its attachments) contains information belonging to the 
sender, which may be confidential. proprietary and/or legally privileged. The 
information is intended only for the use of the individual(s) or entity(ies) 
named above. If you are not the intended recipient, you are hereby notified 
that any disclosure, distribution or taking of any action in reliance on the 
content of this is strictly forbidden. If you have received this e-mail in 
error please immediately notify the sender identified above


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4605): https://lists.onap.org/g/onap-tsc/message/4605
Mute This Topic: https://lists.onap.org/mt/29737916/21656
Mute #dublin: https://lists.onap.org/mk?hashtag=dublin=2743226
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [E] Re: [onap-discuss] [onap-tsc] Ubuntu and Alpine discussion

[Viswanath Kumar Skand Priya via Lists.Onap.Org]

Looks like I have arrived late to the party, but still want to add my 2 cents.

I agree with Tal 100% . If the assumption is that, the docker images available 
in ONAP nexus repo will be directly used in production, that that’s a total 
invalid assumption. As Tal pointed out, the choice of distribution matters.  
The goal here should be making ONAP Build success without any intrinsic 
dependencies / assumptions about OS distribution & specific builds of DBs & 
other deps.

I feel all the previous discussions on this thread is geared towards 
simplifying community builds & speeding the download time for bringing up ONAP 
for a lab / poc / demo. This would only make ONAP stay in reference 
implementation level .

IMHO, we as a community should focus on making ONAP Build from scratch with 
minimum set of deps. If CIA is already working on that direction, please 
disregard my 2 cents.

Thank you!

BR,
Viswa


From:  on behalf of Tal Liron 
Reply-To: "onap-tsc@lists.onap.org" 
Date: Monday, February 11, 2019 at 10:56 AM
To: onap-discuss , DESBUREAUX Sylvain TGI/OLN 

Cc: Chaker Al Hakim , 
"srinivasa.r.addepa...@intel.com" , 
"onap-tsc@lists.onap.org" 
Subject: [E] Re: [onap-discuss] [onap-tsc] Ubuntu and Alpine discussion

This conversation has gotten a little bit confusing. Let me try to organize and 
separate the core issues:

  1.  Disk space. If we want to reduce the ridiculous storage requirements for 
ONAP's container images, the solution is not to choose a tiny Linux 
distribution. Rather, the solution is to choose a single (or small set of) base 
image(s) for all ONAP container images. Because images are stored as deltas 
from the derived base image, then the size of that base image is quite 
negligible.
  2.  Choice of base distribution. ONAP provides reference images, but in the 
end production operations will very likely build their own after auditing 
selections of packages and even the source code. The ONAP project can make a 
best effort to pre-audit the selection, but in the end cannot provide neither a 
guarantee nor a warranty. That comes from the operating system vendor and other 
software vendors of packages like MariaDB, MongoDB, JDK, etc. The ONAP project 
should make it possible (and better yet: easy) for users to make that choice. I 
understand this as one of the goals of our CIA project. I think there's also 
some misunderstanding of the supportability of packages within the containers. 
Here's an example: if your host operating system is RHEL, but your container 
image is based on Alpine, then Red Hat cannot support any security 
vulnerabilities in those Alpine libraries. This includes OpenSSL as well as 
glib, systemd, etc. In the end, whatever ONAP chooses as base image is 
arbitrary as long as we allow users to make their own choice.
  3.  Technical dependencies on specific distributions. Does a certain ONAP 
image build against a specific version of a library included in a specific 
version of a specific distribution? This should be considered a bug, because it 
exactly disallows the freedom of users to choose a base distribution. Not only 
that, but it's a guarantee for maintenance nightmares in the future. What 
happens if the next version of that specific distribution changes the library? 
Who will make sure to refactor and allow for an upgrade of the base? And if you 
can't upgrade the base, the image will be stuck with an older and possibly 
broken/insecure library. There are many open source project plagued with this 
problem, e.g. stuck on Ubuntu 14.04. We need to make sure that we minimize 
these dependencies. There's also the option of building that specific 
dependency library from source for that ONAP image, but again we limit the 
ability for users to get support from a vendor.
There are some complications regarding point #3 that should be discussed. For 
example, many Linux distributions have switched to systemd in recent years, and 
that causes a major change in how they run (e.g. that's one main reason 
projects stuck on Ubuntu 14.04 have difficulty moving forward). If systemd is 
considered a standard for ONAP, then that limits the number of possible choices 
for base image. Likewise SELinux. We need to examine ONAP as a whole and make a 
list of these basic technical requirements from a base distribution.

On Mon, Feb 11, 2019 at 10:08 AM Sylvain Desbureaux 
mailto:sylvain.desbure...@orange.com>> wrote:
Hello Chaker,

Today,
The docker building image process of ONAP is at the very least messy (Morgan 
did a presentation at TSC meeting last Thursday on this point 

Re: [onap-discuss] [onap-tsc] Ubuntu and Alpine discussion

[Brian]

I dont think Disk space is really the main issue – its size of the image to 
download and boot and the memory consumption in the running image.

We arent running into issues with disk space in our environment but rather in 
memory consumption and to some extent the container init delays.

Brian




From: onap-tsc@lists.onap.org  On Behalf Of Tal Liron
Sent: Monday, February 11, 2019 11:56 AM
To: onap-discuss ; DESBUREAUX Sylvain TGI/OLN 

Cc: Chaker Al Hakim ; 
srinivasa.r.addepa...@intel.com; onap-tsc@lists.onap.org
Subject: Re: [onap-discuss] [onap-tsc] Ubuntu and Alpine discussion

This conversation has gotten a little bit confusing. Let me try to organize and 
separate the core issues:

  1.  Disk space. If we want to reduce the ridiculous storage requirements for 
ONAP's container images, the solution is not to choose a tiny Linux 
distribution. Rather, the solution is to choose a single (or small set of) base 
image(s) for all ONAP container images. Because images are stored as deltas 
from the derived base image, then the size of that base image is quite 
negligible.
  2.  Choice of base distribution. ONAP provides reference images, but in the 
end production operations will very likely build their own after auditing 
selections of packages and even the source code. The ONAP project can make a 
best effort to pre-audit the selection, but in the end cannot provide neither a 
guarantee nor a warranty. That comes from the operating system vendor and other 
software vendors of packages like MariaDB, MongoDB, JDK, etc. The ONAP project 
should make it possible (and better yet: easy) for users to make that choice. I 
understand this as one of the goals of our CIA project. I think there's also 
some misunderstanding of the supportability of packages within the containers. 
Here's an example: if your host operating system is RHEL, but your container 
image is based on Alpine, then Red Hat cannot support any security 
vulnerabilities in those Alpine libraries. This includes OpenSSL as well as 
glib, systemd, etc. In the end, whatever ONAP chooses as base image is 
arbitrary as long as we allow users to make their own choice.
  3.  Technical dependencies on specific distributions. Does a certain ONAP 
image build against a specific version of a library included in a specific 
version of a specific distribution? This should be considered a bug, because it 
exactly disallows the freedom of users to choose a base distribution. Not only 
that, but it's a guarantee for maintenance nightmares in the future. What 
happens if the next version of that specific distribution changes the library? 
Who will make sure to refactor and allow for an upgrade of the base? And if you 
can't upgrade the base, the image will be stuck with an older and possibly 
broken/insecure library. There are many open source project plagued with this 
problem, e.g. stuck on Ubuntu 14.04. We need to make sure that we minimize 
these dependencies. There's also the option of building that specific 
dependency library from source for that ONAP image, but again we limit the 
ability for users to get support from a vendor.
There are some complications regarding point #3 that should be discussed. For 
example, many Linux distributions have switched to systemd in recent years, and 
that causes a major change in how they run (e.g. that's one main reason 
projects stuck on Ubuntu 14.04 have difficulty moving forward). If systemd is 
considered a standard for ONAP, then that limits the number of possible choices 
for base image. Likewise SELinux. We need to examine ONAP as a whole and make a 
list of these basic technical requirements from a base distribution.

On Mon, Feb 11, 2019 at 10:08 AM Sylvain Desbureaux 
mailto:sylvain.desbure...@orange.com>> wrote:
Hello Chaker,

Today,
The docker building image process of ONAP is at the very least messy (Morgan 
did a presentation at TSC meeting last Thursday on this point 
https://wiki.onap.org/pages/viewpage.action?pageId=6593670=/6593670/54722733/onap_tests.pdf)
 as we do not know what we test and even if it’s tested.

So the base image of an ONAP component doesn’t seems to be the most critical 
part on improving ONAP.
I would prefer to :

  *   Make reliable, consistent tests on any review that come
  *   Know what is tested
  *   Strengthen security by moving from root to another user in the docker 
images
  *   Slimify ONAP so the tests are faster

When we’ll arrive at that, I’ll be happy to see if we can make a consensus on 
base image.

Today, all I want to do is make small images per components. If a component is 
small on ubuntu/centOs/Debian/openSUSE, fine I won’t touch it.
If it’s not, I’ll make a review 

Re: [onap-discuss] [onap-tsc] Ubuntu and Alpine discussion

[Tal Liron]

This conversation has gotten a little bit confusing. Let me try to organize
and separate the core issues:

   1. Disk space. If we want to reduce the ridiculous storage requirements
   for ONAP's container images, the solution is not to choose a tiny Linux
   distribution. Rather, the solution is to choose a single (or small set of)
   base image(s) for all ONAP container images. Because images are stored as
   deltas from the derived base image, then the size of that base image is
   quite negligible.
   2. Choice of base distribution. ONAP provides reference images, but in
   the end production operations will very likely build their own after
   auditing selections of packages and even the source code. The ONAP project
   can make a best effort to pre-audit the selection, but in the end cannot
   provide neither a guarantee nor a warranty. That comes from the operating
   system vendor and other software vendors of packages like MariaDB, MongoDB,
   JDK, etc. The ONAP project should make it possible (and better yet: easy)
   for users to make that choice. I understand this as one of the goals of our
   CIA project. I think there's also some misunderstanding of the
   supportability of packages within the containers. Here's an example: if
   your host operating system is RHEL, but your container image is based on
   Alpine, then Red Hat cannot support any security vulnerabilities in those
   Alpine libraries. This includes OpenSSL as well as glib, systemd, etc. In
   the end, whatever ONAP chooses as base image is arbitrary as long as we
   allow users to make their own choice.
   3. Technical dependencies on specific distributions. Does a certain ONAP
   image build against a specific version of a library included in a specific
   version of a specific distribution? This should be considered a bug,
   because it exactly disallows the freedom of users to choose a base
   distribution. Not only that, but it's a guarantee for maintenance
   nightmares in the future. What happens if the next version of that specific
   distribution changes the library? Who will make sure to refactor and allow
   for an upgrade of the base? And if you can't upgrade the base, the image
   will be stuck with an older and possibly broken/insecure library. There are
   many open source project plagued with this problem, e.g. stuck on Ubuntu
   14.04. We need to make sure that we minimize these dependencies. There's
   also the option of building that specific dependency library from source
   for that ONAP image, but again we limit the ability for users to get
   support from a vendor.

There are some complications regarding point #3 that should be discussed.
For example, many Linux distributions have switched to systemd in recent
years, and that causes a major change in how they run (e.g. that's one main
reason projects stuck on Ubuntu 14.04 have difficulty moving forward). If
systemd is considered a standard for ONAP, then that limits the number of
possible choices for base image. Likewise SELinux. We need to examine ONAP
as a whole and make a list of these basic technical requirements from a
base distribution.

On Mon, Feb 11, 2019 at 10:08 AM Sylvain Desbureaux <
sylvain.desbure...@orange.com> wrote:

> Hello Chaker,
>
>
>
> Today,
>
> The docker building image process of ONAP is at the very least messy
> (Morgan did a presentation at TSC meeting last Thursday on this point
> https://wiki.onap.org/pages/viewpage.action?pageId=6593670=/6593670/54722733/onap_tests.pdf)
> as we do not know what we test and even if it’s tested.
>
>
>
> So the base image of an ONAP component doesn’t seems to be the most
> critical part on improving ONAP.
>
> I would prefer to :
>
>- Make reliable, consistent tests on any review that come
>- Know what is tested
>- Strengthen security by moving from root to another user in the
>docker images
>- Slimify ONAP so the tests are faster
>
>
>
> When we’ll arrive at that, I’ll be happy to see if we can make a consensus
> on base image.
>
>
>
> Today, all I want to do is make small images per components. If a
> component is small on ubuntu/centOs/Debian/openSUSE, fine I won’t touch it.
>
> If it’s not, I’ll make a review request with the image that I think is the
> most suitable, and most of the time it’ll be Alpine.
>
> Considered the spread of images today, I think that the choice of image is
> up to the requester and the “+2” person from the project.
>
>
>
> Regards,
>
>
>
> ---
>
> Sylvain Desbureaux
>
>
>
> *De : *Chaker Al Hakim 
> *Date : *lundi 11 février 2019 à 16:04
> *À : *DESBUREAUX Sylvain TGI/OLN , "
> srinivasa.r.addepa...@intel.com" , "
> onap-disc...@lists.onap.org" , "
> onap-tsc@lists.onap.org" 
> *Objet : *RE: [onap-discuss] [onap-tsc] Ubuntu and Alpine discussion
>
>
>
> Hello Sylvain,
>
>
>
> I appreciate your detailed reply..
>
>
>
> I am not sure if you were on the call when this topic was discussed. My
> point was not whether I favor one Linux distribution over 

Re: [onap-discuss] [onap-tsc] Ubuntu and Alpine discussion

[Chaker Al Hakim]

Hello Sylvain,

I appreciate your detailed reply..

I am not sure if you were on the call when this topic was discussed. My point 
was not whether I favor one Linux distribution over other Linux distributions,. 
It was related to whether a specific distribution is commercially supported. As 
I mentioned in my previous email, f the goal of the Footprint Optimization 
project is to support all of the ONAP components, including all of their 
dependencies, packages, re-certification efforts, etc… on Alpine Linux then 
let’s make that very clear, ask for another TSC approval and document it in the 
ONAP wiki so that we are all on board

Regards,
Chaker

From: sylvain.desbure...@orange.com [mailto:sylvain.desbure...@orange.com]
Sent: Monday, February 11, 2019 8:29 AM
To: Chaker Al Hakim ; 
srinivasa.r.addepa...@intel.com; onap-disc...@lists.onap.org; 
onap-tsc@lists.onap.org
Subject: Re: [onap-discuss] [onap-tsc] Ubuntu and Alpine discussion

Hello Chaker and Srini,

First of all, I want to thank you to propose yourself to rebuild ONAP docker 
images in order to shrink their sizes. We’re only 2 guys doing that today 
(Frank Sandoval and myself) so multiplying by two the workforce is great news.

SDNC and AAI have been done, Frank is working on DMaaP and I’m starting Portal 
as of today. So you can pick any image from 
https://wiki.onap.org/display/DW/CIA+Dublin+Release+Planning (Robot or SO for 
example). We want also to make a second pass on already done images to shrink 
more so you can also review and propose enhancements to the ones already done.

Welcome on board!

For the base image, you can use Alpine or Ubuntu at your preference.


As there are opinions against Alpine, I would like to share my views:

  *   Alpine is “vendor neutral”. If we decide to mandate ubuntu for example, I 
imagine that Canonical competitors could disagree and push their own images
  *   There have been some concerns (see  Ramki email for example) about using 
musl library and not glibc. Musl libc (https://www.musl-libc.org/) is now the 
default library for OpenWRT and is also used as replacement of uclibc (and 
glibc) in embedded Real time Linux images. So, we wouldn’t be the only one 
using it.
  *   Another building block of Alpine is busybox (https://www.busybox.net/) 
which is used in a lot of embedded devices (such as Modem router) so again 
we’re not the only ones (there are billions of device using it).
  *   On the security side, clair scanner (https://github.com/coreos/clair/) is 
a vulnerability tool from CoreOS (now part of RedHat) designerd for container 
security audit. You can embed it in your CI. Here’s an example of container 
scan (python script on top of Alpine) and you can see there are no known 
vulnerabilities : 
https://gitlab.com/Orange-OpenSource/lfn/ci_cd/chained-ci-mqtt-trigger/security/dashboard

At the very least, this discussion shows a need for simplifying docker build 
process in order to tend to have a “simple” way to move from base image XXX to 
base image YYY.

Now, to know what’s the state of OOM as of today (master deployment of ONAP 
using docker-staging file from integration team, counting 284 containers):
ONAP images using :

  *   Debian/Ubuntu: 98
  *   Alpine: 61
  *   CentOS/rpm or yum based distro: 21
  *   Busybox: 3 (actually a lot more as many jobs are using busybox)
  *   Unknown: 1

Please be aware that mileage may vary (+/- 10 range I think) (it’s a 
“bruteforce” script and there may be / are images counted more than once but 
it’s what’s on my deployment today) and I counted “only” images from 
“nexus3.onap.org”.

So there’s no clear dominant base image and so claiming for “ubuntu only” or 
“alpine only” is inappropriate.
---
Sylvain Desbureaux

De : Chaker Al Hakim 
mailto:chaker.al.ha...@huawei.com>>
Date : vendredi 8 février 2019 à 15:34
À : "onap-disc...@lists.onap.org" 
mailto:onap-disc...@lists.onap.org>>, DESBUREAUX 
Sylvain TGI/OLN 
mailto:sylvain.desbure...@orange.com>>, 
"srinivasa.r.addepa...@intel.com" 
mailto:srinivasa.r.addepa...@intel.com>>, 
"onap-tsc@lists.onap.org" 
mailto:onap-tsc@lists.onap.org>>
Objet : RE: [onap-discuss] [onap-tsc] Ubuntu and Alpine discussion

Hi Team,

I was also on the TSC call and was engaged in the discussion as well. I agree 
with  Srini’s position that we should support ONAP on both  Ubuntu as well as 
Alpine Linux. Looking just at the disk image footprint as one driver to support 
only Alpine Linux may not be the best way to go; In addition, deploying ONAP on 
a base Linux that is not commercially supported may not be the best approach 
moving forward.

If the end goal of the Footprint Optimization is to ultimately support ONAP 
only on  Alpine Linux then this discussion becomes much broader then just 
footprint optimization and should be presented and discussed as such  at the 
ArchCom and at the the TSC level to make sure