Dmitry, hi! About this case https://bugs.launchpad.net/fuel/+bug/1356954. Short description: we marked node as error because lost access to it during mcollective, but deploy other nodes. Current mechanic: if this failed node (reason not important) have no critical significance, we marked it as error and continue. If we deploy 20 nodes, we can easily survive fail (for any reason: mcollective, network, puppet) of 2 computes nodes for example. I think this is a correct behavior, but i can mistake.
If we add information why we marked this node as error (mcollective connection problem) in brief, we can save a lot of time. On Thu, Aug 28, 2014 at 2:43 PM, Dmitry Mescheryakov < [email protected]> wrote: > Vladimir, > > Good idea! I can suggest another bit to improve: when astute fails to > connect to mcollective on a node, just a number of debug/info messages > appear in the log. At the same time that ruins the deployment and > clearly should be logged as error. An example could be seen in logs > provided in the following bug > https://bugs.launchpad.net/fuel/+bug/1356954 > > Thanks, > > Dmitry > > > 2014-08-28 12:05 GMT+04:00 Vladimir Sharshov <[email protected]>: > > Hi! > > > > I believe many of us try to investigate Astute logs to find problem with > > cluster. > > And in mostly case it was very difficult. Please find time and look to > this > > document: https://etherpad.openstack.org/p/fuel-astute-log-improvement > > > > Your feedback will help us to improve this moment. > > > > Feel free to contact with me. > > > > IRC nickname in #fuel-dev: warpc > > Skype: warpcv > > > > -- > > Mailing list: https://launchpad.net/~fuel-dev > > Post to : [email protected] > > Unsubscribe : https://launchpad.net/~fuel-dev > > More help : https://help.launchpad.net/ListHelp > > >
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
