On 10/09/2013 12:44 PM, Ken Schneider - openSUSE pecked at the keyboard and wrote:
On 10/09/2013 12:21 AM, Greg KH pecked at the keyboard and wrote:
On Tue, Oct 08, 2013 at 12:07:18PM -0400, Ken Schneider - openSUSE wrote:
On 10/08/2013 04:01 AM, Wirlach Manfred pecked at the keyboard and wrote:
Hi all,
yesterday I startet to migrate my openSUSE machines from normal distribution to the rolling-update Tumbleweed (currently openSUSE 12.3) - machines are productive and so Factory was no option.
After switching to Tumbleweed everything works fine except DRBD. I found out that there is an inconsistency between drbd kernel module (V8.4.3 in kernel-default) and the drbd admin tools (V8.3.11 from repository) which ends up with the inability to start the cluster volumes.
As workaround I found a matching rpm on suse build service, but please include a proper drbd-tools version in the Tumbleweed repos.
Thx in advance.
Manfred
Stability, stability, stability is what is needed for production machines which is something that TW _cannot_ provide/guarantee. Therefore it is not recommended for your use case.
It all depends on what your "production" is? I know lots of valid use cases for constantly rolling updates for real-life-production-systems, so please don't think that "stability" is somehow the only way stuff like that can work.
I'll be glad to add the drbd tools to Tumbleweed, Wirlach, what repo should I pull them from to ensure they are kept up to date with the kernel releases?
thanks,
greg k-h
Properly administered/managed /production/ machines should never be updated without properly testing any software update whether it be kernel or application updates.
Tested on a test machine of course. The IT direstor at the places I worked at would fire anyone for allowing -untested- updates to production machines.
I don't want to imply that TW is not stable just that bugs will always exist the the least likely place.
-- Ken Schneider SuSe since Version 5.2, June 1998 -- Every serious IT admin should test its software before deployment, but hey - no risk, no fun;-) I always try to do it, but be honest - do you really test ALL services on the machines? How large is you test environment? How do you test apps with complex dependencies from other services?
My experience is that we all test the main applications well, but many problems come along with commodity services in background and slightly changed default parameters or permissions. For instance the Tumbleweed update changes the hostname to its FQDN. The apps worked well after upgrade (opensuse guys did a great job!), but corosync cluster and drbd had problems due to changed node names in cluster config... Best Regards Manfred -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org