[c-nsp] IOS(-XE) 'configure replace' robustness

[James Bensley]

On 3 May 2017 at 17:44, Saku Ytti <saku at ytti.fi> wrote:
> On 3 May 2017 at 18:45, James Bensley <jwbensley at gmail.com> wrote:
>
> Hey James,
>
>> However “show run “ shows me the full config is there. So that’s a
>> step forwards, all the config is being applied (it seems the config
>> parser for "configure replace" is very picky!), but the router
>> indicates it has failed so once my TAC engineer is back from holiday,
>> is sticking time. Just before they went on holiday they said they had
>> been working with the BU relating to the config parser and an internal
>> defect had been opened so a public bug ID maybe be formed, we shall
>> wait and see, but they didn't say why the internal defect was opened
>> so that is another mystery too (was it because the parser has leading
>> white space issues? Or was it because it shows an operation as failed
>> when it was successfull? Or was it because it can't roll back when an
>> operation failed?).
>
>
> Thanks for your input. Personally I believe if startup-config is
> accepted, then 'config replace' should be accepted.

Absolutely!

> Personally I do
> not do anything with 'configure replace' which expect to see
> post-parser config, that dilutes value of automation so much it makes
> it near worthless. Cleanly designed configuration generation will not
> produce clean-post-parser config. Only really fugly domain specific
> code will do that.
> I hope IOS-XE gets this sorted. I don't care if it's via netconf of
> CLI, I just want to be able to give it full working config.

Yeah me too! This is part of a greenfield build that has CSR1000v as
CPEs and ASR9000s as PEs. I've had moderate success with ASR9000s
using a mixture of OpenConfig YANG models and Cisco's proprietary YANG
models serialised as JSON over gRPC. So the plan is/was to use JSON
over gRPC to manage the 9K's and the JSON over REST API in IOS-XE to
manage the CSR1000v's. To get the devices up quickly thought I was
hoping to use Ansible and Jinja2 as a "quick and easy" way to generate
an initial full config that is "thrown" over the CLI. Then once they
are up and running transition to the REST API in IOS-XE and gRPC in
IOS-XR.

I will now amend my plans and look to start implementing the REST API
for IOS-XE ASAP. I can handle falling back to CLI if some feature
isn't present in an API yet and actually managed a device via both API
an CLI (and hopefully closing down the CLI over the coming years), but
generating the entire config for the initial deployment is not really
possible in either IOS-XE or IOS-XR via their APIs yet so I'm a bit
disappointed that even this first hurdle on IOS-XE has had issues.

Cheers,
James.