RESTCONF Server Implementation in ONOS - open issues

167 views
Skip to first unread message

Sean Condon

unread,
May 15, 2018, 11:55:30 AM5/15/18
to Dynamic configuration

Hi all


I've got back to looking at RESTCONF Server on ONOS again and I wanted to shake it out to see what all of the open issues are.

I don't know if anyone else is maintaing a list of issues, but it would be good to hold everything in the one place.


I'd like to get your opinions on these, whether you think they are real issues or not, or if I'm missing any. I did not get in to operations, streams or notifications.


I think some of them should not be too hard to fix, but I wanted to agree them before I expend any effort on them. Maybe we could discuss on tomorrow's Dyn Config call.


Best regards, Sean


===================================================================

# Open issues with RESTCONF Server in ONOS
The RESTCONF protocol is described in RFC 8040 https://tools.ietf.org/html/rfc8040

There are many things in RFC 8040 that are not implemented here in the ONOS implementation of RESTCONF

1) The datastore resource is not implemented (section 3.4) -
 this should allow GET of all data from the datastore (only data resources work)

2) Currently both configuration and state data resources can be written to RESTCONF using POST and
 PATCH, PUT and DELETE. state-data is not meant to be writable and should produce an error 404 with invalid-state -
see Section 4.1.1 (note this is necessary for ONOS because RESTCONF acts like a NETCONF writable
running style store, not like ODL which uses a writable-candidate store)

3) The implementation does not support the /.well-known/host-meta as in Section 3.1

4) The media types for json are set wrong It should be "application/yang-data+json" instead of ""application/json"

5) Security is not enabled on RESTCONF - this should be in protocols/restconf/server/rpp/.../web.xml

6) HTTPS is not available on RESTCONF by default - this is done at the Karaf container level, and is a configuration task

7) ETag (entity tag) headers are not supported. This should be maintained at the datastore level and returned with the response to a GET command. (Section 3.5.2)

8) Last-Modified header is not supported - this is optional, but could be useful for clients (Section 3.5.1)

9) In the response to a POST command the "Location" header should be present - it is not implemented (Section 4.4.1)

10) with-defaults query parameter for GET is not implemented - it's optional (section 3.5.4)

11) Calling a PUT command with an empty body does not return an proper RESTCONF error message

12) Insert and Point Query Parameters for the POST command in the case of Lists are not supported - Section 4.4.1

13) Success on DELETE should return 204 (currently returns 200) - Section 4.7

14) Deleting a data resource when it has already been deleted does not produce the required 404 error message (Section 4.7)

15) Replacing a Data Node using PUT is not implemented -  It should return 204. (Section 4.5) It is only possible through PATCH

16) When modifying a list item there is no check that the key in the URI matches the key in the body - Section 4.5 (end of page 48 of PDF)

17) Accept-Patch header is not given in response to the OPTIONS command

18) The "content" query parameter is not supported - Section 4.8.1

19) When GET of /onos/restconf is requested the details of the API should be returned as per Section 8 grouping restconf

20) Cache-Control header is not included in every response - see Section 5.5

21) The "If-None-Match" and "If-Modified-Since" header fields are not supported - see Section 5.5

22) The "ietf-yang-library" YANG module is not loaded in to the YANG models for RESTCONF - see Section 10





Yuta Higuchi

unread,
May 15, 2018, 1:00:09 PM5/15/18
to Sean Condon, Dynamic configuration
Thanks for summarizing, 
BTW are they in order or priority for you or they're just numbered for ease of discussion, etc.

It's day after tomorrow for me here, but let's discuss there.

Just quickly skimming through, I got an impression, 
many items boils down to the problem that, 
there is no way to store metadata in the store.

Also, I'm not sure if it's related, but something similar to 15),
I heard Hiroki working on ODTN is having issue updating when there already is an existing element.



--
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/5efbce568c0f43b69ab173c7ffda4f70%40microsemi.com.
For more options, visit https://groups.google.com/a/onosproject.org/d/optout.

Sean Condon

unread,
May 16, 2018, 7:13:03 AM5/16/18
to Yuta Higuchi, Dynamic configuration

Hi Yuta - my mistake - Thursday for the meeting - not sure if I will be able to attend though, as I'm planning a day off. I will let you know closer to the time.


They are in the order that I found them (rather than priority)


I'm not sure that the lack of storing metadata is the problem (at least YANG model related metadata) - it's more a case of payloads should be analysed when it's transformed to and from Data Nodes, so that it's partitioned in to config and state data.


Talk tomorrow, Sean

From: Yuta Higuchi <y-hi...@opennetworking.org>
Sent: 15 May 2018 17:59:48
To: Sean Condon
Cc: Dynamic configuration
Subject: Re: [brigade-dynconfig] RESTCONF Server Implementation in ONOS - open issues
 
EXTERNAL EMAIL

Yuta Higuchi

unread,
May 16, 2018, 11:51:44 AM5/16/18
to Sean Condon, Dynamic configuration
What I meant was like etag, Last-Modified type of things.
They are not the configuration data itself, but meta-data about them that needs to be tracked to support that.

Sean Condon

unread,
May 16, 2018, 12:02:14 PM5/16/18
to Yuta Higuchi, Dynamic configuration

So I guess there's nothing in DCS that could even do that? Is there a hash or a timestamp from the ConsistentMap that could be used?

From: Yuta Higuchi <y-hi...@opennetworking.org>
Sent: 16 May 2018 16:51:22
 
EXTERNAL EMAIL

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,
May 16, 2018, 3:31:01 PM5/16/18
to Sean Condon, Dynamic configuration
Unfortunately no, current DCS does not have a way to store timestamp.

For hash, at the end they get serialized into bytes, so computing something based on that each time is feasible for the scenario.


EXTERNAL EMAIL

Henry Yu

unread,
May 20, 2018, 4:50:32 PM5/20/18
to Yuta Higuchi, Sean Condon, Dynamic configuration, Aihuaguo (Aihua Guo, CRC)

Hi Sean and all,

 

Per our discussion in the last Thursday’s meeting, I am trying to identify the items that can be implemented in the next few weeks, i.e., the items that may not require changes in the YANG datastore (e.g., DCS 2.0). Would you please review the following list? If we agree to work on them first, then I can raise JIRAs to track them.


3) The implementation does not support the /.well-known/host-meta as in Section 3.1
4) The media types for json are set wrong It should be "application/yang-data+json" instead of ""application/json"

11) Calling a PUT command with an empty body does not return an proper RESTCONF error message

13) Success on DELETE should return 204 (currently returns 200) - Section 4.7
14) Deleting a data resource when it has already been deleted does not produce the required 404 error message (Section 4.7)
15) Replacing a Data Node using PUT is not implemented -  It should return 204. (Section 4.5) It is only possible through PATCH

17) Accept-Patch header is not given in response to the OPTIONS command

20) Cache-Control header is not included in every response - see Section 5.5

22) The "ietf-yang-library" YANG module is not loaded in to the YANG models for RESTCONF - see Section 10



@Sean: Could you please elaborate a bit more on the following item? And can it also be done without DCS 2.0?


19) When GET of /onos/restconf is requested the details of the API should be returned as per Section 8 grouping restconf

Thanks,

Henry

EXTERNAL EMAIL

EXTERNAL EMAIL

 

--

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.

Sean Condon

unread,
May 21, 2018, 9:36:08 AM5/21/18
to Henry Yu, Yuta Higuchi, Dynamic configuration, Aihuaguo (Aihua Guo, CRC)

Hi Henry


The list looks about right.

I think 9) is also possible without too much effort.



Regarding 19, I think what's meant here is that when I do a get on /onos/restconf, I should get back a JSON or XML structure that lists

--data

--operations

--yang-library-version

Like listed in Section 3.3. It should be possible without DCS 2.0


Sean

From: Henry Yu <henr...@huawei.com>
Sent: 20 May 2018 21:50:22
To: Yuta Higuchi; Sean Condon
Cc: Dynamic configuration; Aihuaguo (Aihua Guo, CRC)
Subject: RE: [brigade-dynconfig] RESTCONF Server Implementation in ONOS - open issues
 

Henry Yu

unread,
May 24, 2018, 10:05:55 AM5/24/18
to Sean Condon, Yuta Higuchi, Dynamic configuration, Aihuaguo (Aihua Guo, CRC)

Thanks, Sean.  So we can also add  9) and 19) to our list.   

 

Henry

Sean Condon

unread,
May 24, 2018, 10:21:34 AM5/24/18
to Henry Yu, Yuta Higuchi, Dynamic configuration, Aihuaguo (Aihua Guo, CRC)

Hi Henry - can you take a look at patch

https://gerrit.onosproject.org/#/c/18517/


so that we can try to cross 4) off our list


Sean

From: Henry Yu <henr...@huawei.com>
Sent: 24 May 2018 15:05:43
To: Sean Condon; Yuta Higuchi
 
EXTERNAL EMAIL

Henry Yu

unread,
May 24, 2018, 10:39:32 AM5/24/18
to Sean Condon, Yuta Higuchi, Dynamic configuration, Aihuaguo (Aihua Guo, CRC)

Thanks for the patch, Sean.  The changes look fine.  (The git-review email notification sends to my gmail account, which I do not check regularly at work. So if you do not hear from me, please send a reminder email to this huawei email address.)

Henry Yu

unread,
May 24, 2018, 11:37:47 AM5/24/18
to Sean Condon, Yuta Higuchi, Dynamic configuration, Aihuaguo (Aihua Guo, CRC)

Hi Sean and all,

 

I created the JIRAs for track the list. They can be seen on the “To Do” column of the Kanban board below:

 

https://jira.onosproject.org/secure/RapidBoard.jspa?rapidView=28

 

Thanks,

Henry

 

 

From: Sean Condon [mailto:sean....@microsemi.com]

Sent: Monday, May 21, 2018 9:36 AM
To: Henry Yu <henr...@huawei.com>; Yuta Higuchi <y-hi...@opennetworking.org>
Cc: Dynamic configuration <brigade-...@onosproject.org>; Aihuaguo (Aihua Guo, CRC) <aihu...@huawei.com>

Sean Condon

unread,
May 24, 2018, 4:59:56 PM5/24/18
to Henry Yu, Yuta Higuchi, Dynamic configuration, Aihuaguo (Aihua Guo, CRC)

Thanks Henry - it's good to track them - Sean

From: Henry Yu <henr...@huawei.com>
Sent: 24 May 2018 16:37:37

To: Sean Condon; Yuta Higuchi
 
EXTERNAL EMAIL

Reply all
Reply to author
Forward
0 new messages