Currently, VirtualBMC works by forking a new process on every 'vbmc start' invocation. This makes it hard to manage it by standard means, including starting it on system boot and restarting when it fails. Instead, we need one daemon (vbmcd?) serving IPMI for all virtual nodes, and the vbmc command merely talking to it. Of course, we'll need to somehow maintain a reasonable upgrade path for both upstream CI and TripleO use cases. We'll have to update packaging to include systemd units. And we'll probably need puppet-ironic and instack-undercloud code managing the new service (now it's done either manually or via tripleo-quickstart).
*** Bug 1419723 has been marked as a duplicate of this bug. ***
*** Bug 1551762 has been marked as a duplicate of this bug. ***
@shrjoshi - it looks like this was moved to POST from ON_QA because there was no Fixed In Version set, is that correct? I'm trying to understand why it was moved to ON_QA and Fixed in Version was not set in the first place. Is the code in a downstream build?
Moving back to ON_DEV until RDO fix for systemd merges.
Hello, would it be possible to get an update on this? I understand from a review of the upstream patch this is quite a large change but it would be good to understand if there is a chance of this being backported to OSP 13. vbmc in that release seems a little broken.
I think backporting virtualbmc would be hard for two reasons: * virtualbmc tool now depends on pyzmq which I don't see in OSP13 * the change itself is massive On top of that, it has been decided to drop virtualbmc from further OSP (because of the pyzmq dependency). How broken virtualbmc was back then? I could probably fix the issues in the code. Not sure how expensive further maintenance of the patch downstream would be? WDYT?
(In reply to Ilya Etingof from comment #14) > I think backporting virtualbmc would be hard for two reasons: > > * virtualbmc tool now depends on pyzmq which I don't see in OSP13 > * the change itself is massive > > On top of that, it has been decided to drop virtualbmc from further OSP > (because of the pyzmq dependency). > > How broken virtualbmc was back then? I could probably fix the issues in the > code. Not sure how expensive further maintenance of the patch downstream > would be? > > WDYT? Well, its just the dep that is missing as per: https://review.rdoproject.org/r/#/c/17322/1/python-virtualbmc.spec however there is an error when using vbmc, though it seems to work successfully. Its probably not worth the backport effort, especially as its not going to be included going forward.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2019:0045