SONiC Application Extension HLD

[stepanblyschak]

No description provided.

[mikelazar]

A few of comments/questions:

1. This approach assumes that extensions need to follow the SONiC convention (use supervisord to start processes, use a per container rsyslogd to log, use systemd unit files to start containers at system). There are useful situations/use cases where this is not true - for instance when SONiC switches are used as "compute nodes" for applications designed to work in a generic container environment. In that case, using supervisord and rsyslog is not necessarily the case - there can be one microservice / container and no rsyslog (such applications use docker log drivers to log, for instance). Furthermore, such applications are designed to benefit from the automatic restart options of docker (e.g. --restart=unless-stopped) rather than the heavier systemd unit files. In other words, this approach forces users of SONiC to design their applications to be very SONiC centric, rather than generic.
2. It will also be beneficial to allow the life cycle management (install and upgrade) of extension applications to be independent of SONiC. With the current approach, the assumption is that all extensions need to be reinstalled after SONiC is upgrade - or that they be included in the SONiC installation/upgrade.
3. Is there an assumption that application extensions are supposed to use the SONiC Redis DB ? Could they use a completely different DB ?

I can imagine that we can address (1) by simply installing any container image in SONiC, however, it will also be useful to be able to integrate its CLI or management API's with SONiC, without the need for the application to follow the SONiC approach for using supervisord, rsyslogd and systemd unit files. However, (2) is harder to address - AFAIK the docker local registry in /var/lib/docker is completely overwritten during an upgrade. It would help to find a means to address this.

[stepanblyschak]

@mikelazar

Hi, thank you for comments, here are my thoughts:

1. The design was developed mainly for SONiC Docker container in mind. That is true, however, looking forward we understand the need to users to run non-SONiC Dockers. So, we enable users to install Dockers which are not SONiC specific - section in HLD. Hower, we need to think about potential limitations of such approach. The Application Extension infrastructure does not put any requirement on the Docker image itself - like, running specifically supervisord, use rsyslogd, etc, unless a manifest is provided by the user during installation as shown in the HLD section. However, there are other features in SONiC wich may add some requirements to the Docker image - like kubernetes support does about container state recording. Regarding, '--restart' docker option - this is not a constraint for a docker image, this is how SONiC manages container today, regardless of what container it is. If SONiC changes in the future to use docker auto-restart instead of systemd auto-restart then the Application Extension will auto-generate the start script to append '--restart' to the docker run options. In general, the use of systemd is necessary here if we want to use management CLI for generic dockers in the same way as for other SONiC dockers - e.g "config feature" CLI. My point is that Docker image does not care about who and how will start/stop/restart it.

2. With the approach described in HLD SONiC-2-SONiC upgrade we will allow users to install arbitrary Docker images with "sonic-package-manager" and if user does the whole SONiC image upgrade then those user installed images will be installed automatically in the new image by "sonic_installer".

3. The application is required to use SONiC database only if there is a requirement to support SONiC configuration model though CONFIG DB. If this is not the case then the Docker may not use SONiC database at all.
   Although, there is another question - what if the Docker requires data persistency? Let's say a Docker spawns it's own database process and the data should persist in case of restarts, reboots, upgrades. In such case I would suggest to choose a persistent storage on SONiC like /host or /etc/sonic or /var/log (depending of what this data actually is) and specify a mount in the manifest. Also, you can put a logic that will dump this data to this mounted path by writing a one-line bash script in 'pre-shutdown-action' field in the manifest. This is how I see data persistency could be achieved.

[venkatmahalingam]

We may not need these mount volumes for 3rd party dockers as they may not depend on SONiC resources? can we make it an optional field (e.g SONiC dependent docker vs non-dependent docker) in the manifest file?

[stepanblyschak]

This is mentioned in https://github.com/Azure/SONiC/pull/682/files#diff-be6a02b89b88eb9dd23104151d3b06081dbc49c58c610f5f2aa5dfc5d1d4e13aR1298.

Normally, if you don't need these volume mounts you will not specify "depends": ["database"], or any other sonic container that has a dependency on database. In this case sonic-package-manager will know that these mounts are not needed.

Please, note, 3rd party dockers are not part of phase 1 implementation

[venkatmahalingam]

ok, thanks.

[bandaru-viswanath]

I think we should de-link the CLI autogeneration from this. If we think the sonic-utilities is part of the base-os, we should list here. Alternately, we can let other individual dockers to register their dependencies on sonic-utilities.

CLI is just one form of management, and even for CLI there are multiple models (linux-like, cisco-like etc). The base-os should not have any awareness of the CLI, or any UI.

So, I suggest we look at whether we need sonic-util as part of base-os, independent of a specific CLI model

[bandaru-viswanath]

Just to aid clarity - Within a SONIC release, the major and minor versions of the feature package must not change, i.e., any newer version of the feature package for that SONIC release, remains fully backward compatible.

[stepanblyschak]

Yes, only bug fixes are allowed as usually for release branches

[liat-grozovik]

@renukamanavalan I believe it is time to merge this PR as the code is almost done and merged. Any objection?