| Message ID | 20211014164130.606220-1-amorenoz@redhat.com |
|---|---|
| Headers | show |
| Series | Facilitate external use of ovn-detrace | expand |
On 10/14/21 6:41 PM, Adrian Moreno wrote: > ovn-detrace is a very useful tool for debugging OVN issues. > > It's core logic (mapping openflow cookies / ports with OVN objects) can > be used for a variety of troubleshooting tools. Therefore, it would be > desirable to make use of such logic from an external python program. > > This could be done by creating a python library (similarly to what ovs > provides) that is built and pushed to PyPi for other projects to > consume. > > However, being the only python script that lives in OVN, this might be a > bit of an overkill, so what this series proposes is an intermediate step > that does not require that much extra maintenance and still alleviates > the main obstacles one finds when trying to use ovn-detrace as a python > module which are: > - python expects module names to end in .py and use underscores instead > of hyphens > - internally, ovn-detrace prints directy to stdout, the output of the > ovn-detrace information should be configurable > - the version information is not easily available > > With this series, ovn-detrace is renamed to ovn_detrace.py and a > symlink with the old name is created for backwards compatibility. As a > result, a use can point her PYTHONPATH to ovn's installation path, > run "import ovn_detrace", and make use of ovn-detrace's logic with, say, > individual openflow cookies instead of ofproto/trace outputs. > > I know it's not the cleanest way to do it. I'd love to hear your opinion > on the matter. > > Reviewing notes: > - The first patch is a small fix I spotted when playing around with > ovn-detrace > - I have not tested the debian package thoroughly > Hi Adrian, I briefly tried the RFC series out and I don't see any functional changes, so that works for me. I quickly glanced at the patches too and they also look OK to me. Looking forward to the v1. Regards, Dumitru
On 10/18/21 14:51, Dumitru Ceara wrote: > On 10/14/21 6:41 PM, Adrian Moreno wrote: >> ovn-detrace is a very useful tool for debugging OVN issues. >> >> It's core logic (mapping openflow cookies / ports with OVN objects) can >> be used for a variety of troubleshooting tools. Therefore, it would be >> desirable to make use of such logic from an external python program. >> >> This could be done by creating a python library (similarly to what ovs >> provides) that is built and pushed to PyPi for other projects to >> consume. >> >> However, being the only python script that lives in OVN, this might be a >> bit of an overkill, so what this series proposes is an intermediate step >> that does not require that much extra maintenance and still alleviates >> the main obstacles one finds when trying to use ovn-detrace as a python >> module which are: >> - python expects module names to end in .py and use underscores instead >> of hyphens >> - internally, ovn-detrace prints directy to stdout, the output of the >> ovn-detrace information should be configurable >> - the version information is not easily available >> >> With this series, ovn-detrace is renamed to ovn_detrace.py and a >> symlink with the old name is created for backwards compatibility. As a >> result, a use can point her PYTHONPATH to ovn's installation path, >> run "import ovn_detrace", and make use of ovn-detrace's logic with, say, >> individual openflow cookies instead of ofproto/trace outputs. >> >> I know it's not the cleanest way to do it. I'd love to hear your opinion >> on the matter. >> >> Reviewing notes: >> - The first patch is a small fix I spotted when playing around with >> ovn-detrace >> - I have not tested the debian package thoroughly >> > > Hi Adrian, > > I briefly tried the RFC series out and I don't see any functional > changes, so that works for me. > > I quickly glanced at the patches too and they also look OK to me. > > Looking forward to the v1. > > Regards, > Dumitru > Thanks Dumitru, If the general approach seems OK, I'll send v1. Timothy, do you foresee any issues on the packaging side? Thanks
On Mon, 18 Oct 2021 18:18:07 +0200 Adrian Moreno <amorenoz@redhat.com> wrote: > > > On 10/18/21 14:51, Dumitru Ceara wrote: > > On 10/14/21 6:41 PM, Adrian Moreno wrote: > >> ovn-detrace is a very useful tool for debugging OVN issues. > >> > >> It's core logic (mapping openflow cookies / ports with OVN objects) can > >> be used for a variety of troubleshooting tools. Therefore, it would be > >> desirable to make use of such logic from an external python program. > >> > >> This could be done by creating a python library (similarly to what ovs > >> provides) that is built and pushed to PyPi for other projects to > >> consume. > >> > >> However, being the only python script that lives in OVN, this might be a > >> bit of an overkill, so what this series proposes is an intermediate step > >> that does not require that much extra maintenance and still alleviates > >> the main obstacles one finds when trying to use ovn-detrace as a python > >> module which are: > >> - python expects module names to end in .py and use underscores instead > >> of hyphens > >> - internally, ovn-detrace prints directy to stdout, the output of the > >> ovn-detrace information should be configurable > >> - the version information is not easily available > >> > >> With this series, ovn-detrace is renamed to ovn_detrace.py and a > >> symlink with the old name is created for backwards compatibility. As a > >> result, a use can point her PYTHONPATH to ovn's installation path, > >> run "import ovn_detrace", and make use of ovn-detrace's logic with, say, > >> individual openflow cookies instead of ofproto/trace outputs. > >> > >> I know it's not the cleanest way to do it. I'd love to hear your opinion > >> on the matter. > >> > >> Reviewing notes: > >> - The first patch is a small fix I spotted when playing around with > >> ovn-detrace > >> - I have not tested the debian package thoroughly > >> > > > > Hi Adrian, > > > > I briefly tried the RFC series out and I don't see any functional > > changes, so that works for me. > > > > I quickly glanced at the patches too and they also look OK to me. > > > > Looking forward to the v1. > > > > Regards, > > Dumitru > > > > Thanks Dumitru, > > If the general approach seems OK, I'll send v1. > > Timothy, do you foresee any issues on the packaging side? Hi, I sent you a couple of comments inline, but for packaging point of view I don't see any problem. Just copy the modifications you did in ovn-fedora.spec.in (symlink + adding the .py in %files) in our downstream spec file. > Thanks
On 10/18/21 18:50, Timothy Redaelli wrote: > On Mon, 18 Oct 2021 18:18:07 +0200 > Adrian Moreno <amorenoz@redhat.com> wrote: > >> >> >> On 10/18/21 14:51, Dumitru Ceara wrote: >>> On 10/14/21 6:41 PM, Adrian Moreno wrote: >>>> ovn-detrace is a very useful tool for debugging OVN issues. >>>> >>>> It's core logic (mapping openflow cookies / ports with OVN objects) can >>>> be used for a variety of troubleshooting tools. Therefore, it would be >>>> desirable to make use of such logic from an external python program. >>>> >>>> This could be done by creating a python library (similarly to what ovs >>>> provides) that is built and pushed to PyPi for other projects to >>>> consume. >>>> >>>> However, being the only python script that lives in OVN, this might be a >>>> bit of an overkill, so what this series proposes is an intermediate step >>>> that does not require that much extra maintenance and still alleviates >>>> the main obstacles one finds when trying to use ovn-detrace as a python >>>> module which are: >>>> - python expects module names to end in .py and use underscores instead >>>> of hyphens >>>> - internally, ovn-detrace prints directy to stdout, the output of the >>>> ovn-detrace information should be configurable >>>> - the version information is not easily available >>>> >>>> With this series, ovn-detrace is renamed to ovn_detrace.py and a >>>> symlink with the old name is created for backwards compatibility. As a >>>> result, a use can point her PYTHONPATH to ovn's installation path, >>>> run "import ovn_detrace", and make use of ovn-detrace's logic with, say, >>>> individual openflow cookies instead of ofproto/trace outputs. >>>> >>>> I know it's not the cleanest way to do it. I'd love to hear your opinion >>>> on the matter. >>>> >>>> Reviewing notes: >>>> - The first patch is a small fix I spotted when playing around with >>>> ovn-detrace >>>> - I have not tested the debian package thoroughly >>>> >>> >>> Hi Adrian, >>> >>> I briefly tried the RFC series out and I don't see any functional >>> changes, so that works for me. >>> >>> I quickly glanced at the patches too and they also look OK to me. >>> >>> Looking forward to the v1. >>> >>> Regards, >>> Dumitru >>> >> >> Thanks Dumitru, >> >> If the general approach seems OK, I'll send v1. >> >> Timothy, do you foresee any issues on the packaging side? > > Hi, > I sent you a couple of comments inline, but for packaging point of view > I don't see any problem. Just copy the modifications you did in > ovn-fedora.spec.in (symlink + adding the .py in %files) in our > downstream spec file. > Thanks Timothy. Do you know who can provide comments on the debian side?
ovn-detrace is a very useful tool for debugging OVN issues. It's core logic (mapping openflow cookies / ports with OVN objects) can be used for a variety of troubleshooting tools. Therefore, it would be desirable to make use of such logic from an external python program. This could be done by creating a python library (similarly to what ovs provides) that is built and pushed to PyPi for other projects to consume. However, being the only python script that lives in OVN, this might be a bit of an overkill, so what this series proposes is an intermediate step that does not require that much extra maintenance and still alleviates the main obstacles one finds when trying to use ovn-detrace as a python module which are: - python expects module names to end in .py and use underscores instead of hyphens - internally, ovn-detrace prints directy to stdout, the output of the ovn-detrace information should be configurable - the version information is not easily available With this series, ovn-detrace is renamed to ovn_detrace.py and a symlink with the old name is created for backwards compatibility. As a result, a use can point her PYTHONPATH to ovn's installation path, run "import ovn_detrace", and make use of ovn-detrace's logic with, say, individual openflow cookies instead of ofproto/trace outputs. I know it's not the cleanest way to do it. I'd love to hear your opinion on the matter. Reviewing notes: - The first patch is a small fix I spotted when playing around with ovn-detrace - I have not tested the debian package thoroughly Adrian Moreno (5): manpages.mk: fix dependencies path ovn-detrace: use configurable printer object ovn-detrace: rename ovn-detrace to ovn_detrace.py ovn-detrace: expose version as global variable ovn_detrace.py: add helper to create CookieHandlers Makefile.am | 2 +- build-aux/sodepends.py | 45 +++- debian/ovn-common.install | 2 +- debian/ovn-common.postinst | 1 + debian/ovn-common.postrm | 1 + manpages.mk | 12 +- rhel/ovn-fedora.spec.in | 9 + utilities/automake.mk | 14 +- .../{ovn-detrace.in => ovn_detrace.py.in} | 196 ++++++++++-------- 9 files changed, 180 insertions(+), 102 deletions(-) rename utilities/{ovn-detrace.in => ovn_detrace.py.in} (75%)