Bug 1473276 - [RFE] Turn VirtualBMC into a proper systemd-managed daemon
Summary: [RFE] Turn VirtualBMC into a proper systemd-managed daemon
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-virtualbmc
Version: 13.0 (Queens)
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: Upstream M2
: 14.0 (Rocky)
Assignee: Ilya Etingof
QA Contact: mlammon
URL:
Whiteboard:
: 1419723 1551762 (view as bug list)
Depends On:
Blocks: 1636976
TreeView+ depends on / blocked
 
Reported: 2017-07-20 11:45 UTC by Dmitry Tantsur
Modified: 2019-01-11 11:48 UTC (History)
8 users (show)

Fixed In Version: python-virtualbmc-1.4.0-0.20180903195742.4e6e901.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-01-11 11:48:07 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1751570 0 None None None 2018-02-25 12:11:55 UTC
OpenStack gerrit 488874 0 None MERGED multiprocess server, ZMQ-based management cli tool 2021-02-18 15:27:22 UTC
OpenStack gerrit 590408 0 None MERGED update constraint for virtualbmc to new release 1.4.0 2021-02-18 15:27:23 UTC
OpenStack gerrit 594168 0 None MERGED update constraint for virtualbmc to new release 1.4.0 2021-02-18 15:27:23 UTC
OpenStack gerrit 594169 0 None MERGED Bump pyghmi version to 1.2.4 2021-02-18 15:27:23 UTC
RDO 14221 0 None None None 2018-07-31 15:12:03 UTC
RDO 15368 0 None None None 2018-08-15 15:19:44 UTC
RDO 15371 0 None None None 2018-08-15 15:16:55 UTC
RDO 15413 0 None None None 2018-08-15 15:20:36 UTC
Red Hat Product Errata RHEA-2019:0045 0 None None None 2019-01-11 11:48:38 UTC

Description Dmitry Tantsur 2017-07-20 11:45:38 UTC
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).

Comment 6 Ilya Etingof 2017-11-10 16:25:45 UTC
*** Bug 1419723 has been marked as a duplicate of this bug. ***

Comment 7 Bob Fournier 2018-03-12 15:06:15 UTC
*** Bug 1551762 has been marked as a duplicate of this bug. ***

Comment 10 Bob Fournier 2018-07-31 14:19:40 UTC
@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?

Comment 11 Bob Fournier 2018-08-01 13:30:27 UTC
Moving back to ON_DEV until RDO fix for systemd merges.

Comment 13 Christopher Brown 2018-11-09 13:10:07 UTC
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.

Comment 14 Ilya Etingof 2018-11-21 15:58:14 UTC
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?

Comment 15 Christopher Brown 2018-11-21 17:10:52 UTC
(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.

Comment 17 errata-xmlrpc 2019-01-11 11:48:07 UTC
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


Note You need to log in before you can comment on or make changes to this bug.