Ben,
take a look at my question to Miguel and his comment & question for you.

thanks

---------- Forwarded message ----------
From: Miguel Angel Ajo Pelayo <majop...@redhat.com>
Date: Sun, Mar 11, 2018 at 11:23 AM
Subject: Re: [ovs-discuss] Including bfd status for tunnel endpoints on
ovs-vsctl show
To: Eran Kuris <eku...@redhat.com>


No, I agree it would be great to have something like that. But it's not
straight forward because the code is dumping tables and dictionaries from
the database as they are. And the code is not specific to ovs-vsctl. It's
abstracted for all the command line utilities in one place. Very nice to
maintain, but of course it's a trade off on flexibility.

@ben do you have any idea about how to include the host names on tunnel
endpoints (not necessarily on the bfd_status, of course)

On Sun, Mar 11, 2018, 7:56 AM Eran Kuris <eku...@redhat.com> wrote:

> Hi Miguel,
>
> Is it possible to add node name next to node IP address?
> look the example:
> $ sudo utilities/ovs-vsctl show
> a4cf68a7-07e9-4ed4-a317-016cb610c821
>     Bridge br-int
>         fail_mode: secure
>         Port "ovn-7e8b8a-0"
>             Interface "ovn-7e8b8a-0"
>                 type: geneve
>                 options: {csum="true", key=flow, remote_ip="172.16.0.5" -*
> controller-0*}
>
>         Port "ovn-0c37dd-0"
>             Interface "ovn-0c37dd-0"
>                 type: geneve
>                 options: {csum="true", key=flow, remote_ip="172.16.0.7"-
> * controller-1*}
>
>
>
>
>
>
>
> ERAN KURIS
>
> NEUTRON senior Quality ENGINEER
>
> Red Hat Israel <https://www.redhat.com/>
>
> Yerushalayim Rd 34, Ra'anana
>
> eku...@redhat.com
> <https://red.ht/sig>
>
> On Fri, Mar 9, 2018 at 7:43 PM, Miguel Angel Ajo Pelayo <
> majop...@redhat.com> wrote:
>
>> Ok, I have modified it to just show bfd_status, for rexample, in a 3
>> controller + 1 compute
>> environment, with a router and a vm on the compute:
>>
>> [heat-admin@overcloud-controller-2 ovs]$ sudo utilities/ovs-vsctl show
>> a4cf68a7-07e9-4ed4-a317-016cb610c821
>>     Bridge br-int
>>         fail_mode: secure
>>         Port "ovn-7e8b8a-0"
>>             Interface "ovn-7e8b8a-0"
>>                 type: geneve
>>                 options: {csum="true", key=flow, remote_ip="172.16.0.5"}
>>                 bfd_status: {diagnostic="No Diagnostic", flap_count="1",
>> forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
>> state=up}
>>         Port "ovn-0c37dd-0"
>>             Interface "ovn-0c37dd-0"
>>                 type: geneve
>>                 options: {csum="true", key=flow, remote_ip="172.16.0.7"}
>>                 bfd_status: {diagnostic="No Diagnostic", flap_count="1",
>> forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
>> state=up}
>>         Port br-int
>>             Interface br-int
>>                 type: internal
>>         Port "patch-br-int-to-provnet-b47ffac1-1704-4e97-85ef-
>> f4fb478e18c4"
>>             Interface "patch-br-int-to-provnet-b47ffac1-1704-4e97-85ef-
>> f4fb478e18c4"
>>                 type: patch
>>                 options: {peer="patch-provnet-b47ffac1-
>> 1704-4e97-85ef-f4fb478e18c4-to-br-int"}
>>         Port "ovn-9f2335-0"
>>             Interface "ovn-9f2335-0"
>>                 type: geneve
>>                 options: {csum="true", key=flow, remote_ip="172.16.0.11"}
>>                 bfd_status: {diagnostic="No Diagnostic", flap_count="1",
>> forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
>> state=up}
>>     Bridge br-ex
>>         fail_mode: standalone
>>         Port br-ex
>>             Interface br-ex
>>             ...
>>
>>
>> if I admin disable that single router with " neutron router-update
>> router1 --admin-state-up false"
>> (the bfd should be disabled all around because it's not necessary, and
>> ovs-vswitchd takes care
>> of clearing up bfd_status):
>>
>> [heat-admin@overcloud-controller-2 ovs]$ sudo utilities/ovs-vsctl show
>> a4cf68a7-07e9-4ed4-a317-016cb610c821
>>     Bridge br-int
>>         fail_mode: secure
>>         Port "ovn-7e8b8a-0"
>>             Interface "ovn-7e8b8a-0"
>>                 type: geneve
>>                 options: {csum="true", key=flow, remote_ip="172.16.0.5"}
>>         Port "ovn-0c37dd-0"
>>             Interface "ovn-0c37dd-0"
>>                 type: geneve
>>                 options: {csum="true", key=flow, remote_ip="172.16.0.7"}
>>         Port br-int
>>             Interface br-int
>>                 type: internal
>>         Port "patch-br-int-to-provnet-b47ffac1-1704-4e97-85ef-
>> f4fb478e18c4"
>>             Interface "patch-br-int-to-provnet-b47ffac1-1704-4e97-85ef-
>> f4fb478e18c4"
>>                 type: patch
>>                 options: {peer="patch-provnet-b47ffac1-
>> 1704-4e97-85ef-f4fb478e18c4-to-br-int"}
>>         Port "ovn-9f2335-0"
>>             Interface "ovn-9f2335-0"
>>                 type: geneve
>>                 options: {csum="true", key=flow, remote_ip="172.16.0.11"}
>>     Bridge br-ex
>>         fail_mode: standalone
>>         ...
>>
>>
>>
>>
>> On Fri, Mar 9, 2018 at 9:32 AM Miguel Angel Ajo Pelayo <
>> majop...@redhat.com> wrote:
>>
>>> Thank you Ben, I'll finish it, test it properly and submit the patch.
>>>
>>> I don't know if it makes any sense to add a filter where the dictionary
>>> has only a key "enabled" and it's "false",
>>> or it's really not worth it. I'll check out how it looks with a real
>>> deployment and get back here with the results.
>>>
>>> On Thu, Mar 8, 2018 at 7:12 PM Ben Pfaff <b...@ovn.org> wrote:
>>>
>>>> On Thu, Mar 08, 2018 at 04:43:50PM +0000, Miguel Angel Ajo Pelayo wrote:
>>>> > Ok, looking at the code, it seems like we may only need to do this?
>>>> >
>>>> > diff --git a/utilities/ovs-vsctl.c b/utilities/ovs-vsctl.c
>>>> > index 21fa18d..2ac60bf 100644
>>>> > --- a/utilities/ovs-vsctl.c
>>>> > +++ b/utilities/ovs-vsctl.c
>>>> > @@ -1018,7 +1018,9 @@ static struct cmd_show_table cmd_show_tables[]
>>>> = {
>>>> >       &ovsrec_interface_col_name,
>>>> >       {&ovsrec_interface_col_type,
>>>> >        &ovsrec_interface_col_options,
>>>> > -      &ovsrec_interface_col_error},
>>>> > +      &ovsrec_interface_col_error,
>>>> > +      &ovsrec_interface_col_bfd,
>>>> > +      &ovsrec_interface_col_bfd_status},
>>>> >       {NULL, NULL, NULL}
>>>> >      },
>>>>
>>>> Yes, you also need to increase the size of columns[] in cmd_show_table:
>>>>
>>>> diff --git a/lib/db-ctl-base.h b/lib/db-ctl-base.h
>>>> index eb444270535b..5d8532a7bde2 100644
>>>> --- a/lib/db-ctl-base.h
>>>> +++ b/lib/db-ctl-base.h
>>>> @@ -197,7 +197,7 @@ struct weak_ref_table {
>>>>  struct cmd_show_table {
>>>>      const struct ovsdb_idl_table_class *table;
>>>>      const struct ovsdb_idl_column *name_column;
>>>> -    const struct ovsdb_idl_column *columns[3]; /* Seems like a good
>>>> number. */
>>>> +    const struct ovsdb_idl_column *columns[5]; /* Seems like a good
>>>> number. */
>>>>      const struct weak_ref_table wref_table;
>>>>  };
>>>>
>>>> > But that would render something like:
>>>> >
>>>> >
>>>> > [heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
>>>> > 5f35518a-ab34-49a4-a227-e487e251b7e3
>>>> >     Manager "ptcp:6640:127.0.0.1"
>>>> >         is_connected: true
>>>> >     Bridge br-int
>>>> >         fail_mode: secure
>>>> >         Port "ovn-14d60a-0"
>>>> >             Interface "ovn-14d60a-0"
>>>> >                 type: geneve
>>>> >                 options: {csum="true", key=flow,
>>>> remote_ip="172.16.0.12"}
>>>> >                 bfd: {enable="true"}
>>>> >                 bfd_status: {diagnostic="No Diagnostic",
>>>> flap_count="1",
>>>> > forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
>>>> > state=up}
>>>> >
>>>> >
>>>> > I'm partly guessing here based on what I see around lib/db-ctl-base.c
>>>> and
>>>> > doing a little bit of debugging.
>>>> >
>>>> > @Ben is there any way of filtering out those columns when
>>>> > bfd:enabled="false" or not set ?
>>>>
>>>> It appears that that's already what happens, at least for the "not set"
>>>> case.  I doubt there are many controllers that explicitly set enable to
>>>> false.
>>>>
>>>
>
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Reply via email to