<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>Hi, SUSE developers<br><br></div>Thanks for your great work on OpenStack packaging for SUSE distribution.<br><br>I have tested some functionality of ceilometer on sles 11 sp3, and have two minor problem, which can create critical availability problem, but can be easily fixed . They all locate in the service init script.<br>
<br></div>* {start,check,kill}proc program base on process basename<br></div>  this problem blocks alarm services, since ceilometer-alarm-evaluator and ceilometer-alarm-notifier have more than 15 prefix character exactly same, and blocks agent services in All-In-One scenario too, (ceilometer-agent-central & ceilometer-agent-compute)<br>
</div>  Dirk Muller has provided a fix which using -p option to ensure the killproc will not affect another process, but I verify it on sles 11 sp3 in my all-in-one environment, and find that it does no longer kill other process, but it cannot kill its own process now, which means each time I restart the ceilometer-alarm-*, I get a new one but not replace the old one<br>
</div>  I have a ugly workaround which simply shorten the ceilometer process name, it still works fine. But this problem needs to be fixed in upstream, by a better solution<br><br></div>* ceilometer-{api,collector} depend on mongodb<br>
</div>  mongodb is full-feature supported in havana (thanks to SUSE developer, they backport metaquery for sql backend, even it needs to be improved too), but I've already found that ceilometer-{api,collecor} cannot behavior normal when host boot, they both complain that cannot connect to database, api process will quit but collector process will stay broken and cannot recover itself anymore even mongodb is available after boot.<br>
</div>  the problem may be quite simple, even though the two services specify the mongodb as a shoud-start service, but when host boot, mongodb may already start but in an unavailable state, which cause the two services fail. I've no idea how to solve this problem in a nice way, but I just sleep 5 seconds before startproc the service's process, then everything seems fine in my little environment. this workaround is ugly too, since it sleeps each time besides host boot.<br>
<br></div>If you need any detail, I can provide more. These two problem need to be fixed seriously (maybe quickly) since it strongly affects feature availability and user experience<br><br></div><div>Thanks<br></div></div>