Name collision due to "Default" prefix

5 views
Skip to first unread message

Yuta Higuchi

unread,
Aug 11, 2017, 12:34:59 AM8/11/17
to ONOS Dynamic Configuration Brigade
Hi Gaurav,

I've encountered a .yang file which containd statements which looks like below:

               container default-context-prefix {
                  ...
               }
               list context-prefix {
                  ...
               }

Compiler generated, 
  DefaultContextPrefix.java
for the first container statement.

and next as it tried to process second list, 
compiler again tries to generate 
  DefaultContextPrefix.java 
presumably with different content and fail due to name clash.

Looking at JavaFileGenerator in certain cases, 
compiler prefixes "Default" to the file name, which seems to be the root cause.
So I'm thinking about changing prefix which gets added to something like "YrtDefault" 
so that it will be more unlikely generated name will collide.

In this case it will break API compatibility, so we will need to bump version again.

What do you think?
Do you think there is other way to work around it?

Thanks,
Yuta




Gaurav agrawal

unread,
Aug 11, 2017, 1:24:47 AM8/11/17
to Yuta Higuchi, ONOS Dynamic Configuration Brigade

Hi Yuta,

 

Have you found this in some of existing models available in ONOS? Or somewhere in other standard YANG?

 

Since YANG identifier and JAVA identifier follows different naming conventions, there could be more situations which can result in name collision (for example: two containers with name “test-cont” and “test.cont”), so we might have to look for a holistic solution without breaking backward compatibility, also we need to see if we can completely avoid it or can just reduce the probability.

 

So far the plan was to document conversion rules in wiki for user information and usage and in the rare scenarios when there is a conflict manually modify YANG. But yes if see such scenarios are many as per standard YANG we might have to look for early resolution.

 

Thanks and Regards,

Gaurav

--
You received this message because you are subscribed to the Google Groups "Dynamic configuration" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brigade-dyncon...@onosproject.org.
To post to this group, send email to brigade-...@onosproject.org.
Visit this group at https://groups.google.com/a/onosproject.org/group/brigade-dynconfig/.
To view this discussion on the web visit https://groups.google.com/a/onosproject.org/d/msgid/brigade-dynconfig/CAEJoDtO3D5U6Bf3y6%3DLrdoZXAKCw9cgHCPCOvA_HGFY_of%2B6bg%40mail.gmail.com.
For more options, visit https://groups.google.com/a/onosproject.org/d/optout.

Yuta Higuchi

unread,
Aug 11, 2017, 1:39:00 AM8/11/17
to Gaurav agrawal, ONOS Dynamic Configuration Brigade
Hi Gaurav,

No, this was observed by our folks testing ONOS using yang obtained from some actual device,
so it's not from existing models in the repo.

May be one way to maintain backward compatibility and workaround this problem
could be by making that prefix a configurable compiler parameter.
So that person registering YANG can pass it as part of yang_model( ... ) parameter, etc.

What do you think?

I'm assuming that "Default" getting added by compiler only has impact on POJO object, 
and will never appear in XML/JSON representation.
Is my understanding correct?

Thanks,
Yuta



To unsubscribe from this group and stop receiving emails from it, send an email to brigade-dynconfig+unsubscribe@onosproject.org.
To post to this group, send email to brigade-dynconfig@onosproject.org.

--
You received this message because you are subscribed to the Google Groups "Dynamic configuration" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brigade-dynconfig+unsubscribe@onosproject.org.
To post to this group, send email to brigade-dynconfig@onosproject.org.

Visit this group at https://groups.google.com/a/onosproject.org/group/brigade-dynconfig/.
To view this discussion on the web visit https://groups.google.com/a/onosproject.org/d/msgid/brigade-dynconfig/2F2059F256F9B24F82EAC5EE47F446C6E898DD12%40dggemi501-mbx.china.huawei.com.

Gaurav agrawal

unread,
Aug 11, 2017, 2:00:06 AM8/11/17
to Yuta Higuchi, ONOS Dynamic Configuration Brigade

Hi Yuta,

 

Please see in-line reply.

 

From: Yuta Higuchi [mailto:y-hi...@opennetworking.org]
Sent: 2017年8月11日 11:09
To: Gaurav agrawal
Cc: ONOS Dynamic Configuration Brigade
Subject: Re: [brigade-dynconfig] Name collision due to "Default" prefix

 

Hi Gaurav,

 

No, this was observed by our folks testing ONOS using yang obtained from some actual device,

so it's not from existing models in the repo.

[Gaurav] So if I understand correctly its private YANG and not a standard one.

 

May be one way to maintain backward compatibility and workaround this problem

could be by making that prefix a configurable compiler parameter.

So that person registering YANG can pass it as part of yang_model( ... ) parameter, etc.

 

What do you think?

[Gaurav] Yes it looks to be a good approach for this specific scenario but there could be more, so whether we should handle them on a case by basis or list all of them and handle together. I think we can maintain a list of such collision and during next release cycle can look into it. Also at beginning we may prioritize problems related to standard YANG if any, private YANG if encounters such collision can be modified manually for time being.

 

I'm assuming that "Default" getting added by compiler only has impact on POJO object, 

and will never appear in XML/JSON representation.

Is my understanding correct?

[Gaurav] Yes, you are right.

 

Thanks,

Yuta

 

 

 

On Thu, Aug 10, 2017 at 10:21 PM, Gaurav agrawal <gaurav....@huawei.com> wrote:

Hi Yuta,

 

Have you found this in some of existing models available in ONOS? Or somewhere in other standard YANG?

 

Since YANG identifier and JAVA identifier follows different naming conventions, there could be more situations which can result in name collision (for example: two containers with name “test-cont” and “test.cont”), so we might have to look for a holistic solution without breaking backward compatibility, also we need to see if we can completely avoid it or can just reduce the probability.

 

So far the plan was to document conversion rules in wiki for user information and usage and in the rare scenarios when there is a conflict manually modify YANG. But yes if see such scenarios are many as per standard YANG we might have to look for early resolution.

 

Thanks and Regards,

Gaurav

 

To unsubscribe from this group and stop receiving emails from it, send an email to brigade-dyncon...@onosproject.org.
To post to this group, send email to brigade-...@onosproject.org.

--

You received this message because you are subscribed to the Google Groups "Dynamic configuration" group.

To unsubscribe from this group and stop receiving emails from it, send an email to brigade-dyncon...@onosproject.org.
To post to this group, send email to brigade-...@onosproject.org.

 

--

You received this message because you are subscribed to the Google Groups "Dynamic configuration" group.

To unsubscribe from this group and stop receiving emails from it, send an email to brigade-dyncon...@onosproject.org.
To post to this group, send email to brigade-...@onosproject.org.

Yuta Higuchi

unread,
Aug 11, 2017, 8:46:30 PM8/11/17
to Gaurav agrawal, ONOS Dynamic Configuration Brigade
Make sense.

I've created tickets for ONOS-6908, 6909 so that we will not lose track of these 2 kind name collision issue found so far.



On Thu, Aug 10, 2017 at 10:59 PM, Gaurav agrawal <gaurav....@huawei.com> wrote:

Hi Yuta,

 

Please see in-line reply.

To unsubscribe from this group and stop receiving emails from it, send an email to brigade-dynconfig+unsubscribe@onosproject.org.
To post to this group, send email to brigade-dynconfig@onosproject.org.

--

You received this message because you are subscribed to the Google Groups "Dynamic configuration" group.

To unsubscribe from this group and stop receiving emails from it, send an email to brigade-dynconfig+unsubscribe@onosproject.org.
To post to this group, send email to brigade-dynconfig@onosproject.org.

--
You received this message because you are subscribed to the Google Groups "Dynamic configuration" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brigade-dynconfig+unsubscribe@onosproject.org.
To post to this group, send email to brigade-dynconfig@onosproject.org.

--
You received this message because you are subscribed to the Google Groups "Dynamic configuration" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brigade-dynconfig+unsubscribe@onosproject.org.
To post to this group, send email to brigade-dynconfig@onosproject.org.

Visit this group at https://groups.google.com/a/onosproject.org/group/brigade-dynconfig/.
To view this discussion on the web visit https://groups.google.com/a/onosproject.org/d/msgid/brigade-dynconfig/2F2059F256F9B24F82EAC5EE47F446C6E898E042%40dggemi501-mbx.china.huawei.com.
Reply all
Reply to author
Forward
0 new messages