[sles-beta] Beta8 - Update - VMware - Startup

Waite, Dick Dick.Waite at softwareag.com
Wed Jun 11 00:44:50 MDT 2014


Many Thanks for the good words Thorsten.

I'd like SUSE to understand why for me (SAG) and I think others an Update / Upgrade is my bread and butter and a new Install is only done a couple of times a year.

I have "lots" of virtual machines loaded with various configuration of SAG's application.  When a new Beta starts I do run a New Install with Beta 1 and 2 on x86_64 and if they work I run on zLinux.

When the New Installs are looking good, I then run "Update / Upgrade" on a clone of an Application machine. I need to know our application are compatible with your new release. If the "simple" application machine passes its QE checks, then we clone more complex application machine and we run QE against these. The QE can last a day or a week or ....

The same when we get new hardware, a known working environment is cloned onto the hardware, QE run and run and maybe after a few months that hardware gets a stamp.

I am not going to use a New Install and then load and configure the applications, which often take weeks, 'cos this is not what our customers do or what we encourage.

Evolution is our and I think many others way. We know the application works, its got a stamp, we know the hardware works, its got a stamp, so we create the "clone" attach the two new iso's, we do need the SDK, and run an Update/Upgrade and when this is finished, then the simple and complex QE cycles are started.

My 1st "M/F" was a grand old Marconi in 1972. There was no way you could run a New Install, you had to "Update" the next machine from what you had on the 1st one. The same in the '80 with ICL and IBM, updates were the way... "Do not change two items at the same time", very often in SPOD and Sys_prog offices. In the '90 you could New Install, not sure how many did. I did run a new install Jan 3rd 2000. I had been in POK on Dec 18th when IBM told a select few about Linux for zSeries. For that one it was a new build, but since 2002 I have tried very hard to run Updates/Upgrade and these all came from good city of Neuerburg. I'm not trying to say the good people on x86_64 don't care or worry as much, we have some very large x86_64 environments and we work these the same as zSeries.

I don't need a New Install and I'm sure many shops on this list don't use New Installs, Update / Upgrade what is working on the hardware under it and the applications running on it. Keep it simple stupid (KISS), the grand motto of IT.

So I'll be there on the 18th looking for Beta9, I hope I don't have to do any manual intervention and the issues seen on the attached zip are also fixed. I did attached two zips, but it seems only one get to the the list, sorry, I hope this zip gives you the other 50% of the picture.

To finish the picture, when your new release has been running for "some time", we then use the new compilers and goodies and see how our application can "exploit" these new features. Yes it takes time but customers like their database's running 24*7*365, no database, no profits or customers.

Why not try on the next release to get your Update/Upgrade working first, when I think you will find the New Install falls out from this, least it did in the '80s ;o)

Wishing you all a very good day, and a very successful SLES 12

__R

________________________________________
From: sles-beta-bounces at lists.suse.com [sles-beta-bounces at lists.suse.com] on behalf of Thorsten Kukuk [kukuk at suse.de]
Sent: 10 June 2014 13:38
Cc: 'sles-beta at lists.suse.com'
Subject: Re: [sles-beta] Beta8 - Update - VMware - Startup

Hi,

On Tue, Jun 10, Waite, Dick wrote:

> Grand Hot Afternoon,
>
>         I feel in the attached zips we have some answers as to why a VMware machine does not update clean. I will create a SR when the good Novell system lets me.

Hm, according to the pictures, the update was successfull and
does boot?
The grub2 branding problem should be fixed with the next Beta.
The kde -> gnome migration: I'm afraid this got somehow broken in your
case during your manual resolving of the kdelibs4-branding conflict.
Since the screenshot shows the conflict only to 50%, it's impossible
to say what the problem is.

  Thorsten
--
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta

Software AG – Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany – Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: SLE-12-Beta8_01.zip
Type: application/x-zip-compressed
Size: 1404597 bytes
Desc: SLE-12-Beta8_01.zip
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140611/4871c2bc/attachment.bin>


More information about the sles-beta mailing list