DSU and how it uses yum

<[email protected]>
Newsgroups gmane.linux.hardware.dell.poweredge
Message-ID <008B1276B9D1764F8E841933BD42AFD91900141E52@BLRX7MCDC204.AMER.DELL.COM>
Dell - Internal Use - Confidential
Great feedback! Adding an option in dsu to get the output as CSV/XML file is already in development pipeline.
Agreed that, it is not always good to download inventory and catalog on every dsu execution session. We will discuss the alternatives and soon come up with a better user experience.

The OMSA install/upgrade is not currently handled by dsu tool. The OMSA rpms are hosted in DSU repository for install/update directly using yum command. We have forwarded this issue to the corresponding team and will work with them to improve this.

Thanks,
Soorej


-----Original Message-----
From: linux-poweredge-bounces-Lists On Behalf Of [email protected]
Sent: Monday, November 9, 2015 5:23 PM
To: linux-poweredge-Lists
Subject: [Linux-PowerEdge] DSU and how it uses yum

Installing and then removing the dsucatalog and invcol packages for each run of dsu does seem like really poor design. It should leave those on the system and at the beginning of each run check the installed version of both packages versus what the repo has, if there's an update prompt the user about the updates before proceeding.

This also puts unnecessary load on the Dell repos. Take this scenario that I've done myself more than once:
Admin that is new to dsu runs the following sequence.

-- Runs "dsu -i". Sees the hardware but realizes it only shows hardware and the current firmware installed, no info about available updates is shown.

-- Runs "dsu" to see which packages are needing to be updated.

-- Runs "dsu -n" so he/she doesn't have to manually select each available update.

That admin just downloaded, installed, and then removed dsucatalog and invcol three times. How does that make sense?

And running a yum upgrade from this tool seems even worse. I tend to update the srvadmin packages for OMSA via yum so there hasn't been a big issue for me there but it certainly reinforced the need to update them outside of dsu. Anytime dsu is going to update the srvadmin packages it should only update those, it shouldn't ever touch any other package that isn't part of the srvadmin collection or a dependency.

While I'm on the subject, if "dsu -i" is going to grab the dsucatalog and invcol packages shouldn't it be able to display both the current firmware installed for each component along with the available firmware. Running "dsu" does this so the -i option should as well. There should be some formatting options for this too.

I'd like to see something like:
# dsu -i --format=csv
Feature,current version,available version "OpenManage Server Administrator","8.2.0","8.2.0"
"BIOS","2.0.0","2.5.2"
"Lifecycle Controller","2.10.10.10","2.20.20.20"

With that and if dsu doesn't have to download install the dsucatalog and invcol packages every time it's run a small script to track updates in other tools would be pretty easy. Get us the info in a programatically friendly version and let us do with it whatever best fits our needs. For instance I'd take that output and generate a wiki formatted file to inject into a local mediawiki setup, then each system would have that info available from our wiki in a nice human readable format that is automatically updated daily, weekly or whatever interval I think it should be.

_______________________________________________
Linux-PowerEdge mailing list
[email protected]
https://lists.us.dell.com/mailman/listinfo/linux-poweredge
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.