Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1473276

Summary: [RFE] Turn VirtualBMC into a proper systemd-managed daemon
Product: Red Hat OpenStack Reporter: Dmitry Tantsur <dtantsur>
Component: python-virtualbmcAssignee: Ilya Etingof <ietingof>
Status: CLOSED ERRATA QA Contact: mlammon
Severity: medium Docs Contact:
Priority: medium    
Version: 13.0 (Queens)CC: bfournie, bjacot, chris.brown, ietingof, mtenheuv, racedoro, shrjoshi, vcojot
Target Milestone: Upstream M2Keywords: FutureFeature, Triaged
Target Release: 14.0 (Rocky)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: python-virtualbmc-1.4.0-0.20180903195742.4e6e901.el7ost Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-01-11 11:48:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1636976    

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