Hi Chinmaya,
Yeah - the only thing typedef can not be marked as in-progress (Do you think it
is useful to add such a function?)
The other approach is if the community using those APIs thinks the SR-related
messages still need some quicker iteration, an option is to declare them as
“in-progress” (as in transition to the new peocess) - then the api change
process will not apply and you can make changes directly, and *then* remove the
in-progress status later on, when you are happy about them.
These are the two options - one is focused on keeping the existing setups
maximally compatible, the other on minimizing the overhead at the expense of
compatibility, where the compatibility is not needed.
If you know well who the users of the API are, you can decide what is the best
option.
--a
> On 26 Jun 2020, at 11:08, Chinmaya Aggarwal <chinmaya.agar...@hsc.com> wrote:
>
>
> Hi Andrew,
> We have gone through the api change process link. As per our understanding
> from the link, we have to create a new in-progress message for srv6_sid_list
> i.e
>
> typedef srv6_sid_list_v2
> {
> u8 num_sids;
> u32 weight;
> u32 sl_index;
> vl_api_ip6_address_t sids[16];
> option status="in_progress";
> };
>
> Pertaining to this change we have identified further changes that are
> required : -
>
> 1. A new message for sr_policy_add has to be created i.e.
>
> autoreply define sr_policy_add_v2
> {
> u32 client_index;
> u32 context;
> vl_api_ip6_address_t bsid_addr;
> u32 weight;
> bool is_encap;
> bool is_spray;
> u32 fib_table;
> vl_api_srv6_sid_list_v2_t sids;
> option status="in_progress";
> };
>
>
> 2. A new message for sr_policy_mod has to be created i.e.
>
> autoreply define sr_policy_mod_v2
> {
> u32 client_index;
> u32 context;
> vl_api_ip6_address_t bsid_addr;
> u32 sr_policy_index;
> u32 fib_table;
> vl_api_sr_policy_op_t operation;
> u32 sl_index;
> u32 weight;
> vl_api_srv6_sid_list_v2_t sids;
> option status="in_progress";
> };
>
> 3. A new message for sr_policies_details has to be created i.e.
>
> define sr_policies_details_v2
> {
> u32 context;
> vl_api_ip6_address_t bsid;
> bool is_spray;
> bool is_encap;
> u32 fib_table;
> u8 num_sid_lists;
> vl_api_srv6_sid_list_v2_t sid_lists[num_sid_lists];
> option status="in_progress";
> };
>
> Following changes are required to de done in sr_api.c :-
>
> 4. Since we have created new message sr_policy_add_v2, we need to create
> functions similar to vl_api_sr_policy_add_t_handler() and sr_policy_add() and
> modify them as per the new message.
>
> 5. Since we have created new message sr_policy_mod_v2, we need to create
> functions similar to vl_api_sr_policy_mod_t_handler () and sr_policy_mod ()
> and modify them as per the new message.
>
> 6. Since we have created new message sr_policies_details_v2, we need to
> create functions similar to vl_api_sr_policies_dump_t_handler () and
> send_sr_policies_details () and modify them as per the new message.
>
> 7. After we are done with changes 4, 5 and 6; we need to modify
> foreach_vpe_api_msg macro to register the appropriate handler functions.
>
> Is this what we are suppose to do or is there some other way to cater the new
> in-progress message?
>
>
> Thanks and Regards,
> Chinmaya Agarwal.
> From: Andrew 👽 Yourtchenko <ayour...@gmail.com>
> Sent: Thursday, June 25, 2020 10:56 PM
> To: Chinmaya Aggarwal <chinmaya.agar...@hsc.com>
> Cc: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] Fetching SR Policy data using VPP C API
>
> CAUTION:This email originated from an external organization
>
> Hi Chinmaya,
>
> This fix causes an incompatible change to three messages because they are all
> using the compound type being modified... it *also* uncovered an at least a
> year-long bug that would cause these changes slip under the radar - so thanks
> for helping catch it ! :-)
>
> You can rebase your patch for this change on top of any the versions in
> https://gerrit.fd.io/r/c/vpp/+/27677 and run “make checkstyle-api” to see
> what I am talking about....
>
> I am working with Ole on how to address the issue, meantime if you can take a
> look at https://wiki.fd.io/view/VPP/ApiChangeProcess and consider which
> action is the most appropriate for this scenario.
>
> Thanks !
>
> --a
>
>>> On 25 Jun 2020, at 11:39, Chinmaya Aggarwal <chinmaya.agar...@hsc.com>
>>> wrote:
>>>
>> Fix for this issue submitted for gerrit review (Change Id : 27668)
> DISCLAIMER: This electronic message and all of its contents, contains
> information which is privileged, confidential or otherwise protected from
> disclosure. The information contained in this electronic mail transmission is
> intended for use only by the individual or entity to which it is addressed.
> If you are not the intended recipient or may have received this electronic
> mail transmission in error, please notify the sender immediately and delete /
> destroy all copies of this electronic mail transmission without disclosing,
> copying, distributing, forwarding, printing or retaining any part of it.
> Hughes Systique accepts no responsibility for loss or damage arising from the
> use of the information transmitted by this email including damage from virus.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16825): https://lists.fd.io/g/vpp-dev/message/16825
Mute This Topic: https://lists.fd.io/mt/74894689/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
