Query response <get> vs <get-config>
Kawshik Sarkar
Hi, So when I query with <get> i get updated information from the datastore.<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101"> <get-config> <source> <running/> </source> </get-config> </rpc> ]]>]]> |
|
Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES@Cisco) <mgradzki@...>
Hi,
<get-config> is mapped to HC’s internal database. <get> reads actual vpp state.
If you configure VPP using HC, then config database is updated. But if you use other CP agent or CLI, then you might see difference between config and operational data stores.
Some yang models are not symmetric (config vs state), which might be another reason why <get> and <get-config> returns different data.
Regards, Marek
From: hc2vpp@... [mailto:hc2vpp@...]
On Behalf Of Kawshik Sarkar
Sent: 8 lutego 2018 20:00 To: hc2vpp@... Subject: [hc2vpp] Query response <get> vs <get-config>
Hi, So when I query with <get> i get updated information from the datastore. When I query with <get-config> the datastore doesnt get upgraded. Check The attachment where I have consoled into device, set the mtu as ''9216'' but the <get-config> doesnt reflect that. Also the interface
is up but it shows ''false'..'I queried both source ''running'' and ''Candidate''. Same results. This is my rpc: BR Kawshik |
|
Kawshik Sarkar
Hi marek Thank you for your reply..The limitation that creates is this. And I know this because we configure (our Cisco ,juniper and Dell boxes through yang netconf and python..).....what we do is this...we do a normal configuration let’s say setup “segment routing” from “cli”...once the configuration is done from ‘Cli’...we do a “get- config” and check which yang fields gets updated ..we then understand those are the same exact rpc we need to send to setup “segment routing”...From a design perspective if ur “get-config “ datastore and HC datastore are diff we will never be able to understand what configuration changes have occurred on the yang tree due to a corresponding cli config..so for every nitty gritty configuration we will have to have documentation on what exact rpc’s to generate. Don’t u think the agent should be standardized to behave how Cisco Dell juniper behaves?why keep it separate? On Fri, Feb 9, 2018 at 2:04 AM Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) <mgradzki@...> wrote:
|
|
Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES@Cisco) <mgradzki@...>
Hi,
I agree that it would be useful if Honeycomb and CLI shared configuration.
But there are couple of problems. VPP does not really have notion of config. VPP’s CLI is referred as “debug CLI”. VPP developers encourage to use API.
So ultimate solution might be 1) shared config database, reused by different CP agents 2) production-grade CLI that uses 1)
Ed: any views on that?
If you just want to see what RPC’s are needed to configure feature X, there are couple of possibilities: 1) Take look at postman collections we provide (usually there is reference to corresponding CLI request). 2) First configure feature, then start HC (at startup, HC initializes config based on VPP state) 3) If for some reason HC needs to be running. You can try to restart HC to trigger config reconciliation. 4) Implement RPC that triggers config reconciliation.
Regards, Marek
From: Kawshik Sarkar [mailto:kawshikrandom@...]
Sent: 9 lutego 2018 15:22 To: Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) <mgradzki@...> Cc: hc2vpp@...; honeycomb-dev@... Subject: Re: [hc2vpp] Query response <get> vs <get-config>
Hi marek
Thank you for your reply..The limitation that creates is this. And I know this because we configure (our Cisco ,juniper and Dell boxes through yang netconf and python..).....what we do is this...we do a normal configuration let’s say setup “segment routing” from “cli”...once the configuration is done from ‘Cli’...we do a “get- config” and check which yang fields gets updated ..we then understand those are the same exact rpc we need to send to setup “segment routing”...From a design perspective if ur “get-config “ datastore and HC datastore are diff we will never be able to understand what configuration changes have occurred on the yang tree due to a corresponding cli config..so for every nitty gritty configuration we will have to have documentation on what exact rpc’s to generate. Don’t u think the agent should be standardized to behave how Cisco Dell juniper behaves?why keep it separate?
On Fri, Feb 9, 2018 at 2:04 AM Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) <mgradzki@...> wrote:
|
|