Closed mbenkmann closed 9 years ago
From mux2...@gmail.com on March 14, 2013 03:13:43
Implementing issue #34
should fix this.
From mux2...@gmail.com on March 14, 2013 07:51:31
The re-check has confirmed that removing the object and hard reboot of the VM causes the old install job to remain. Implementing issue #34
should fix this. It's only a cosmetic error because all jobs will progress in lockstep and will be removed when one of them is done.
Status: Done
From mux2...@gmail.com on March 14, 2013 11:00:11
I had 3 install jobs when setting up grisham as server. I'm not sure what exactly caused this. The first time the installation started, I still had a template match rule which created the object and I did a hard shutdown of the VM and deleted the object. This is probably responsible for one of the stale jobs. Maybe I did this a 2nd time? Another thing I did wrong was to not set the system to "active" right away. I re-entered the system edit dialog and changed it (Resulting in the GOsa message "The system is currently installing. If you want to save it, press OK").
Re-check the use case of bringing a new system that doesn't exist in LDAP online, then selecting it, making it a repo server, NOT SETTING IT TO ACTIVE, saving, then re-entering the edit, making it active and saving again.
Original issue: http://code.google.com/p/go-susi/issues/detail?id=84