Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use jinja2 python package from pypi #4883

Draft
wants to merge 11 commits into
base: master
Choose a base branch
from

Conversation

pavel-shirshov
Copy link
Contributor

@pavel-shirshov pavel-shirshov commented Jul 1, 2020

- Why I did it
We need to keep only one version of jinja2 library in the build system. Otherwise some python packages uses old version of jinja2, some of them using new version of jinja2, which makes a mess.

- How I did it

  1. For jessie I left everything as it was. python-jinja2 is going to be installed by python-sphinx as dependency.
  2. I enabled using backports for debian stretch. The backports uses jinja==2.10.2 which is good enough for us.
  3. I removed installing new jinja2 for debian-buster. It has jinja==2.10.2 in the main repo which is good enough for us.

- How to verify it
Build an image and check that all tests were successful.

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

xumia and others added 9 commits June 29, 2020 15:01
* Add the test signing certificates for secure boot
* Remove unnecessary ca key file
* Regenerate the certificates to not expose the ca key
Add changes for syslog support for containers running in namespaces on multi ASIC platforms.
On Multi ASIC platforms

Rsyslog service is only running on the host. There is no rsyslog service running in each namespace.
On multi ASIC platforms the rsyslog service on the host will be listening on the docker0 ip address instead of loopback address.
The rsyslog.conf on the containers is modified to have omfwd target ip to be docker0 ipaddress instead of loopback ip

Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan <arlakshm@microsoft.com>
* src/sonic-platform-common 82bbeab...42781ff (1):
  > [SfpBase] Fix key name typo in docstring (sonic-net#99)

Signed-off-by: Volodymyr Boyko <volodymyrx.boiko@intel.com>
1.  Upgrade SAI headers to v1.6.3
2.  Fix traffic lost during FFB related to buffer config + optimize buffer config timing for FB
3.  Add ACL fields BTH, IP flags
4.  Add ACL infrastructure of different fields per ASIC type
…platform. (sonic-net#4779)

* Support for connecting to DB in namespace via IP:port ( using docker bridge network ) for applications in multi-asic platform.

* Added the default IP as 127.0.0.1 if the IPaddress derivation from interface fails.
Moved the localhost loopback IP binding logic into the supervisor.j2 file.
* sonic-sairedis submodule update
* Update BRCM SAI to 3.7.5.1
…et#4843)

Updated the NAT iptables patch for 4.19 buster

Depends on PR : sonic-net/sonic-linux-kernel#147

1 Known issue:

With both NAT patch files for 4.19 buster kernel, seeing 1 display issue in iptables like explained below

On Docker NAT, iptables supported version is 1.6.0 and on base OS it’s 1.8.2. So seeing an display issue of which fullcone option is not showing in version 1.8.2 iptables output and no issues in functionality.

Display issue – For example of comparsion:

NAT Docker:
root@sonic:/home/admin# docker exec -it nat bash
root@sonic:/# iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT all -- * * 0.0.0.0/0 0.0.0.0/0 to:1.1.1.1 fullcone

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 30 packets, 2749 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 30 packets, 2749 bytes)
pkts bytes target prot opt in out source destination
root@sonic:/#

Base OS:
root@sonic:/home/admin# iptables-legacy -t nat -nvL
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
1 36 DNAT all -- * * 0.0.0.0/0 0.0.0.0/0 to:1.1.1.1

Chain INPUT (policy ACCEPT 1 packets, 36 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 41 packets, 3572 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 41 packets, 3572 bytes)
pkts bytes target prot opt in out source destination
root@sonic:/home/admin#

To fix this issue, iptables need to update from 1.6.0 to 1.8.2 version and have to update the NAT docker from stretch to buster. Will raise a new PR with this.

Signed-off-by: Akhilesh Samineni akhilesh.samineni@broadcom.com

Signed-off-by: Akhilesh Samineni <akhilesh.samineni@broadcom.com>
@jleveque
Copy link
Contributor

jleveque commented Jul 1, 2020

I see this is labeled as a "Bug". Seems like an enhancement to me. :) Unless this actually fixes a bug, in which case please add more info to the description.

@pavel-shirshov
Copy link
Contributor Author

@jleveque I spent half of the day trying to choose jinja 2.11.2 over 2.8. Both of the installed because of this "not a bug" :) #4875
Honestly I think that we should either to use distribution packages everywhere and don't use pip at all, or use pip packages only. Otherwise it is very easy to get into situation of a requirement dependency hell.

@jleveque
Copy link
Contributor

jleveque commented Jul 1, 2020

@pavel-shirshov: I agree with your statement. I believe we would like to migrate to use pip/PyPi for all Python packages where ever possible. Thanks for updating the description to detail why this was an issue. I wasn't aware we were installing two different versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants