Bug #12539: Upgrading from a SP'ed SLES to a GA keeps the Service Pack field - Rudder - Issue Tracker

Actions

Copy link

Bug #12539

closed

Upgrading from a SP'ed SLES to a GA keeps the Service Pack field

Added by Janos Mattyasovszky almost 6 years ago. Updated almost 2 years ago.

Status:

Rejected

Priority:

N/A

Assignee:

François ARMAND

Category:

Web - Nodes & inventories

Target version:

4.1.13

Pull Request:

Severity:

Critical - prevents main use of Rudder | no workaround | data loss | security

UX impact:

User visibility:

Getting started - demo | first install | level 1 Techniques

Effort required:

Priority:

Name check:

Fix check:

Regression:

Description

We've had a Server we tested SLES15 Beta, which was before that a SLES12 SP2.

The inventories looked before/after as following (some parts were removed):

<OPERATINGSYSTEM>
      <FULL_NAME>SUSE Linux Enterprise Server 12 (x86_64)</FULL_NAME>
      <KERNEL_NAME>linux</KERNEL_NAME>
      <KERNEL_VERSION>4.4.90-92.50-default</KERNEL_VERSION>
      <NAME>SuSE</NAME>
      <SERVICE_PACK>2</SERVICE_PACK>
      <VERSION>12</VERSION>
</OPERATINGSYSTEM>

<OPERATINGSYSTEM>
      <FULL_NAME>SUSE Linux Enterprise Server 15</FULL_NAME>
      <KERNEL_NAME>linux</KERNEL_NAME>
      <KERNEL_VERSION>4.12.14-16-default</KERNEL_VERSION>
      <NAME>SUSE</NAME>
      <VERSION>15</VERSION>
</OPERATINGSYSTEM>

I assume the missing <SERVICE_PACK> field was not removed and just left as-is, which caused the display to show it as a SLES15 SP2

Files

rudder-sp.png (6.48 KB) rudder-sp.png

Janos Mattyasovszky, 2018-04-27 09:20

Related issues 1 (0 open — 1 closed)

Actions

Copy link

Updated by Janos Mattyasovszky almost 6 years ago

Description updated (diff)

Actions

Copy link

Updated by Janos Mattyasovszky almost 6 years ago

Either you could remove the SP-Info if there is none in the inventory or the inventory could send <SERVICE_PACK>0</SERVICE_PACK> if there is none...

Actions

Copy link

Updated by François ARMAND almost 6 years ago

Translation missing: en.field_tag_list set to Sponsored
Category set to Web - Nodes & inventories
Assignee set to François ARMAND
Target version set to 4.1.13
Severity changed from Major - prevents use of part of Rudder | no simple workaround to Critical - prevents main use of Rudder | no workaround | data loss | security
Priority changed from 70 to 126

I believe that early on, we weren't very confident about the consistency from run to run of inventories, plus we add the hope to be able to implements only partial update.

In that early naive thinking, we thought that we should try to merge data between backend and new inventory.

With the insight of time having done its work, it's not what we want at all. We want inventories to be the source of truth for properties they manage, and if the new inventory tell "there is 2 cpus and no service pack", then it's the current truth, if the previous inventory told us there was 40 cpus and a service pack.

What we really want is a diff viewer that allows to see and check changes, so that the user can decide that the changes are what was expected.

I'm putting that one "critical" because it can lead to lie on the inventory data, and thought on groups, and the user as no way to know easily what's going on.

Actions

Copy link