Use jinja2 python package from pypi #4883
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* 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 <[email protected]>
* src/sonic-platform-common 82bbeab...42781ff (1): > [SfpBase] Fix key name typo in docstring (sonic-net#99) Signed-off-by: Volodymyr Boyko <[email protected]>
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 [email protected] Signed-off-by: Akhilesh Samineni <[email protected]>
lguohan
reviewed
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. |
|
@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 |
|
@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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
- 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
- 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)