Preserving insertion order in leaf-list

CDB and CDB API
1

Yang 1.1 says the implementation is free to define sort order when populating a leaf-list when using “ordered-by system”. which is the default. IE clients don’t specify order, the implementation is free to decide order.

I’m populating an array of IPs, and then using CONFD_SET_TAG_LIST to push them into the DB, into a leaf-list that is marked config false.

The DB is then sorting them using internal rules before serving them up to someone who queries that leaf-list.

How do I insert them into the DB and preserve insertion order? (Note this is not a client pushing to the server, this is me inserting items into the DB to be served up to a client)

It seems counter-intuitive to use “ordered-by user”, because this data is operational. As the server I’m trying to communicate order through the list, I don’t need the client to send me back a list in a particular order.

Does that make sense? RFC for 1.1 implies that as the server I should be able to serve up the list in the order I choose, but when I import the yang model into confd, it doesn’t preserve the order I inserted entries in.

I’ve asked this in a different form before, and was told to use “ordered-by user”, but that seems counter-intuitive to how 1.1 defines ordering. I’m the server in this case, because I’m serving up operational data. How do I control the order of the operational leaf-list I’m populating?

For reference, I’m initializing the DB with a list from a DHCP response, so I’m trying to report the same order that the DHCP contained. The yang model says the leaf-list is a default list, ie “ordered-by system”, which in this case is me, because I’m the server.

ie: If DHCP contains 192.168.2.101, 192.168.2.1 and 192.168.2.10, and someone reads my config-false leaf list, I want to report back 192.168.2.101, 1, 10, but if I use CONFD_SET_TAG_LIST, it sorts the items as they are inserted, so my list ends up being reports as 192.168.2.1, 10, 101

Is the DB just overriding my insertion order because it’s treating my CDB call as being the same as one from a client sending me a RESTCONF set?

2

I believe it is simple: if you use ordered-by system, or do not use the statement at all, you indicate that the ordering does not matter to you and the system is free to order the entries as it needs. So your only option is ordered-by user. Technically, the RFC says that this statement is ignored for state data; ConfD obviously goes beyond that provided that the state data is stored in its database (i.e. not handled by a callpoint), which is apparently your case.

You find this counter-intuitive, since “I am the server”, as you wrote. I don’t think the statement is true - you might be arguably called the server had you implemented a data provider that was used by ConfD to serve the state data, but that is not the case. You are using the system to store and serve the data; so your role is more of a user, in the RFC’s terminology.

3

below is my personal view, might be different for others… :slight_smile:

NETCONF server/behavior implementer in the use-case is ConfD itself, and how it serves leaf-list items ordered by system is, as you mention, defined in section 7.7.7.1 of RFC 7950…

Your code setting/modifying the database contents is not in direct cont(r)act with end-user querying the NETCONF server. It is not acting as NETCONF server, rather that “source/origin of data”, which has no definition or behavior description in NETCONF/YANG RFC…

I assume that ConfD uses standard lexicographic ordering for “ordered-by system” leaf-lists, and I guess that config true/false has no role in regard to different behavior for ordering, and it follows same rules…

If you need specific order different from one provided automatically, you may need to use “order-by user” in the end…

4

oops, @mvf beat me to answer :slight_smile: i have to check state data info, i missed that previously…

5

I disagree, but I can understand your interpretation.

I view the confd DB as part of the implementation (hence why I’m allowed to mess with the data through callpoints), and the whole package of restconf server, plus DB on is the “server”.

The reason I’m implementing a CDB call and not a callpoint is the operational data is “write rarely read many” and it seems like a waste to have a callpoint fire every single time that operational leaf-list is read when I know it’s going to be pre-populated at boot and rarely change, if ever.

6

Just so I’m understanding this clearly, if I use a callpoint, I’m considered the implementation/server, but if I use the management interface, I’m not?

7

Yes, something like that. When you implement a callpoint and the data is queried by a NB user, ConfD works pretty much as mere relay and your callbacks serve the data. When you store the data in ConfD’s DB and the data is queried, it is ConfD that serves it, no other code is invoked.

8

There is tailf:sort-order and by default the ‘normal’ is being used which will order using the key values. So the list would not order by insertion/creation.

1 Like