mbox series

[ovs-dev,RFC,0/5] Facilitate external use of ovn-detrace

Message ID 20211014164130.606220-1-amorenoz@redhat.com
Headers show
Series Facilitate external use of ovn-detrace | expand

Message

Adrián Moreno Oct. 14, 2021, 4:41 p.m. UTC
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%)

Comments

Dumitru Ceara Oct. 18, 2021, 12:51 p.m. UTC | #1
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
Adrián Moreno Oct. 18, 2021, 4:18 p.m. UTC | #2
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
Timothy Redaelli Oct. 18, 2021, 4:50 p.m. UTC | #3
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
Adrián Moreno Oct. 19, 2021, 5:54 a.m. UTC | #4
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?