Why deployment agent is a separate part of CPUSE

[MartinTzvetanov]

Hi,

I still hear people who patch their system with the latest hotfix without updating the DA and then **bleep** hit the fan. Why DA is a separate part of the update package? Why DA is not integrated in the package or why the hotfix does not check if the installed DA is the minimum required? 

[PhoneBoy]

The deployment agent is required to install update packages via CPUSE.
It’s always recommended to check for and install the latest deployment agent before installing any package.
Newer packages sometimes require updates to the Deployment Agent.
Maybe @Tsahi_Etziony or one of his team can provide some more details here.

[MartinTzvetanov]

I don't ask what DA does, I ask why it's a separate part from the hotfix. 

[PhoneBoy]

Not sure why technically speaking, which is why I tagged the R&D owner. 🙂

[JozkoMrkvicka]

I would ask the same question this way:

If we can have Management API commands updated in newer jumbo, why we cannot get newer CPUSE deployment agent too ?

The same applies for LOM firmaware upgrade, cpinfo update,  cpm_doctor update.

[Boaz_Orshav]

Hi

  I'm sorry for the inconvenience and indeed we are aware of this issue.

  For machines which are connected to download center the DA will update itself and if the self update is turned on, the DA will still notify or even block installations if it's not the latest.

  DA which is not connected to download center is not aware that a newer one was released. The Jumbo enforces a minimal DA but it's not always the latest.

  Adding the DA to the Jumbo itself is on our plans but technically has some edge cases, hence was not implemented so far.

[Tsahi_Etziony]

I'd like to add to what @Boaz_Orshav wrote.

The installation logic is divided between the DA and to the package itself. the advantage of having a separate DA is that when we find a bug, we don't have to update all the available packages.

Our biggest concern is the offline users, since the online users will always have the updated DA and there are lower chances that they'll encounter an issue. For offline users, even if we did put all the installation logic in the package - if we find a bug a fix it later on, they'd have to replace their package to avoid that bug. This is the same as updating the DA prior to the installation. Checking for a newer package prior to the installation is complicated if you have several packages to install, and especially if you have an internal certification process for each package. Checking for a newer DA is simpler. 

As Boaz mentioned - if we do find a bug or a missing feature that is required for a successful package installation prior to its release, we add the fix or the feature to a newer DA, and the package is released with a "minimum DA" value. the package won't allow the installation with an older DA than the set value.

One more thing - I mentioned that each package has a value of a minimum DA needed for its installation, but on top of that, online machines will not allow the installation of any package if there is a newer DA available, until that DA is updated on the machine.