cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
453
Views
2
Helpful
3
Replies

What's a good way to expose data entry into CDB for cli/restconf user?

atreyulovesyou
Level 1
Level 1

hi,

So my team has an odd 'service' which amounts to yang on its own, no xml, no supporting code (so unhooked callbacks/no lifecycle interject).  no servicepoint registration (there's no xml) other than an INVALID registration of a service as python, pointing to a file that doesn't exist.

I thought it half done, or somehow abandoned when trawling through our repos refactoring and modernizing... but it is used.

you won't see it in 'set services ...', you will see it in 'show packages package oper-status'.  It drops no logs.

`set funny-fragmented-service options one two buckle my shoe` 

that works.  turns out its used for CDB data entry, where a consumer in another package uses that information.

I don't like a false flag in 'package-meta-data.xml' at all, the suggestion of it as a service while that element of package is invalid.

There must exist a better way for this kind of thing?  

is there something lighter weight than just turning this into a service that doesn't extend ncs:services (so it appears at root of cli and can match existing call logic), when that-something is purely for creating data records in CDB?

1 Accepted Solution

Accepted Solutions

snovello
Cisco Employee
Cisco Employee
Maybe the most lightweight thing you can do here would be to take the yang file, and just place it in the ‘src/yang’ directory of a different ideally related package. Then you can run make and simply remove this package.

View solution in original post

3 Replies 3

snovello
Cisco Employee
Cisco Employee
Maybe the most lightweight thing you can do here would be to take the yang file, and just place it in the ‘src/yang’ directory of a different ideally related package. Then you can run make and simply remove this package.

that'll work, thank you.  

if we want to get logging from it I guess I will need to make it into a little mini-service, as the hosting service (where we'd move yang to, the consumer of the data entered the little yang fragment provides) extends 'ncs:services', but the user are used to using the fragment data entry off the root....

meaning there's no service invocation, and we don't see the use of this if I don't do that and put the service at the root, which I think you can do??  guess I'll see  --- what i mean is they want 'set <THING> VALUES' versus 'set services <THING> VALUES'

Yes there is nothing special about extending ncs:services, you can define services wherever you want including the root.
Defining a service just to get logging will work. An alternative is to use a kicker and an action that logs the changes the kicker sees. You have to see if it’s worth the extra effort.