cancel
Showing results for 
Search instead for 
Did you mean: 
Create a Post

Bug in R80.10 Dashboard solr

OK I have come across a bug in the R80.10 Smart dashboard. I am 99.9% sure it is a bug with the SOLR indexing engine but I am happy to be proved wrong. I have repeated it several times on demand and you should all be able to do it using the demo mode. I would like to know if any one has seen this before and hopefully point me at a KB to fix it rather then having to log a TAC case. the bug is as follows:

Create a new object and assign this object a automatic NAT (static or hide does not seem to matter). 

Publish the changes to the database

Now Edit the object you have just created and remove the NAT

Publish these new changes

Search for the NAT address that you just removed and it will still list the object even though it does not have the NAT

associated to it.

GUIDB Edit shows there is no actual nat associated with the object which adds support that the issue is on the SOLR engine and not the actual database itself. 

Have a go yourselves in demo mode you should be able to replicate it yourselves. 

Any one logged this already and have an answer? 

0 Kudos
2 Replies

Re: Bug in R80.10 Dashboard solr

My question is about the behaviour: When you have published the new changes after removing NAT and performed a policy install, is the deleted NAT rule used now ? Did you test that with R80.10 Jumbo Take_189 using SmartConsole package Build 105 ?

The is another issue with R80.10 NAT here sk122203: Automatic NAT rules are incorrectly matched in R80.10

0 Kudos

Re: Bug in R80.10 Dashboard solr

No it is not matched, the actual NAT and object is correct, If you use GUI DB Edit to review the object it shows no associated NAT and the NAT rules are not listed. This appears to just affect the Dashboard and references to the object when searching which is why I suspect this is a problem with the SOLR index and not something more sinister. Although it would be interesting to see if this also effects log searches on the NAT IP address. I have raised a TAC Case now and it looks like CP have accepted this as a bug and sent it straight over to R&D to look into which was very quick.

0 Kudos