NSO bug with rollback "nr" number - NCS 3.4.6

khgrant · ‎11-03-2016

Team,

Look like there is bug with NCS 3.4.6, with rollbacks using nr numbers. I tried following scenarios:

From NCS GUI

Go to rollbacks under Views

You will see existing rollback files and “nr” assigned to each

Now make some config changes from NCS CLI and commit.

You will notice that existing nr=0 row will be given contents of new changes you made from CLI , although the rollback file name on screen for nr=0 will remain old

From custom GUI application integrated using JSON RPC

For each of my commit transaction, I am giving separate label so that I can find this transaction later using this label.

I am first using get_rollbacks method and picking the nr number for the matching label.

If someone commits anything after my get_rollbacks call then I have wrong nr number

Anyone faced this issue, any resolution in later version?

khgrant · ‎11-09-2016

Team,

Any input on this thread is appreciated. Please also recommend if you also see this an issue and we open a bug for it.

khgrant · ‎11-09-2016

Hi Imran,

Right, the ‘nr’ number as provided in the JSON-RPC get_rollbacks method is the ‘rolling’ rollback number.

In the rolling scheme – NR - is the juniper-like scheme which will maintain ‘0’ as the most current commit, with the ‘nr’ for all other commits being incremented.

There is also a parallel fixed number scheme where the fixed number of the rollback that (by default config) is the 100xx number on the file or in the header of the rollback file:

# Created by: admin

# Date: 2016-11-03 15:56:15

# Via: cli

# Type: delta

# Label: Lag1-Rollback

# Comment:

# No: 10030

The Java API presents both numbers:

From Java maapi (assume similar in JSON-RPC) the getNR:

for (MaapiRollback file : rbList ) {

LOGGER.info("Rollback File List:" + file.toString());

int fnr = file.getFixedNR();

LOGGER.info("Rollback File Fixed NR:" + fnr);

int nr = file.getNR();

LOGGER.info("Rollback File NR:" + nr);

String fcreator = file.getCreator();

LOGGER.info("Rollback File creator:" + fcreator);

String fdate = file.getDate();

LOGGER.info("Rollback File date:" + fdate);

String fvia = file.getVia();

LOGGER.info("Rollback File via:" + fvia);

But since you are Labeling your commits and using that to determine the ‘nr’ number the Fixed number doesn’t do much for you anyway, that’s because the other rollback methods load_rollback, install_rollback currently only accept the rolling ‘nr’ number and not the fixed number.

So once you determine the ‘nr’ number you must use that number immediately, in the same transaction, to protect that the ‘nr’ does not get changed by another commit happening before you use it.

What would be useful would be for the ‘fixed number’ to also be returned from the get_rollbacks method and then add the capability that the fixed number be able to be used in the load_rollback/install_rollback methods as well.

So I think it is an enhancement, more-so than a bug, but would be worthy enhancement.

With that said, doing rollbacks (selective or cumulative) with other commits happening in parallel can be a recipe for confusion, if not disaster, if the results of the rollback can impact the configuration being committed following the commit being reverted. Really need to be careful here.

Regards,

-Larry

khgrant · ‎11-09-2016

Thanks Larry for the detailed response.

So in summary, if we go through Java, then maapi is one option we can use.

If staying with JSON RPC and using nr#, then there is still a chance that we might revert wrong transaction which can be a potential disaster.

So if we want to stay with JSON RPC, then solutions are

Request an enhancement to NSO so that we revert by Fix# rather than dynamic number

Write an action, which will take the label/comment submitted at the time of transaction and will find transaction by label and use fixed rollback file.

Thanks again for your help.