Bug 887283 - RECIPE_MEMBERS have bad value for VM multihost recipeset
Summary: RECIPE_MEMBERS have bad value for VM multihost recipeset
Alias: None
Product: Beaker
Classification: Community
Component: beah
Version: 0.10
Hardware: Unspecified
OS: Unspecified
urgent vote
Target Milestone: 0.12
Assignee: Dan Callaghan
QA Contact: Raymond Mancy
Whiteboard: MultiHost
Keywords: Regression
Depends On:
TreeView+ depends on / blocked
Reported: 2012-12-14 14:38 UTC by Tomas Rusnak
Modified: 2018-02-06 00:41 UTC (History)
10 users (show)

Clone Of:
Last Closed: 2013-04-11 04:55:54 UTC

Attachments (Terms of Use)
submit xml (4.62 KB, text/xml)
2012-12-14 14:38 UTC, Tomas Rusnak
no flags Details

Description Tomas Rusnak 2012-12-14 14:38:18 UTC
Created attachment 663627 [details]
submit xml

Description of problem
The RECIPE_MEMBERS variable should contain all hostnames from particular recipeset. In my case, I requested 3 VMs on one host (physical system):



How reproducible:

Steps to Reproduce:
1. submit file from attachment
2. open one of /var/beah/*.env file 
3. search for RECIPE_MEMBERS variable
Actual results:
RECIPE_MEMBERS="None machine1.example.com"

Expected results:
RECIPE_MEMBERS="machine1.example.com testvm1.example.com testvm2.example.com testvm3.example.com"

Comment 1 Dan Callaghan 2012-12-17 03:25:11 UTC
I assume you are talking about on the host here -- role env vars and RECIPE_MEMBERS should always be set correctly on the guests. On the host you will get None for the guest FQDNs. That's because Beaker doesn't actually know them in advance.

This changed in Beaker 0.10 for bug 655009. Previously Beaker did know the FQDNs in advance, and they were set in RECIPE_MEMBERS and the role env vars. The problem was if the host was on a different VLAN than the allocated guest address it would fail. That was the original point of bug 655009. So Beaker no longer allocates the guest addresses in advance.

Comment 2 Dan Callaghan 2012-12-17 03:40:59 UTC
The host can fetch the guest FQDNs from Beaker, but the API is not very nice and it doesn't go through beaker-proxy, so consider this a temporary workaround only. Python script pasted below. Bear in mind this only works once the guests have finished installing and have checked in to the Beaker server -- before that, Beaker doesn't know what their FQDNs will be.

Ultimately we need some new multi-host synchronisation mechanisms for guest recipes, which will allow the host to find its guests and vice versa.


import os
import xmlrpclib
import xml.dom.minidom

s = xmlrpclib.ServerProxy('%sRPC2' % os.environ['BEAKER'])
recipe_xml = s.recipes.to_xml(os.environ['RECIPEID'])
doc = xml.dom.minidom.parseString(recipe_xml)

guests = []
for recipe in doc.getElementsByTagName('recipe'):
    if recipe.getAttribute('id') == os.environ['RECIPEID']:
        for guestrecipe in doc.getElementsByTagName('guestrecipe'):
print ' '.join(guests)

Comment 3 Dan Callaghan 2013-03-25 06:38:31 UTC
On Gerrit:

With these patches, beah will reload roles at the start of every task. So the RECIPE_MEMBERS and role env vars on the host will contain the guest FQDNs, but only for tasks which are started *after* the guests have been installed (so after /distribution/virt/install).

Comment 5 Tomas Rusnak 2013-03-25 09:06:36 UTC
To have updated environment only for a task started after virt/install should be enough for our purpose. Typically for a task runned on Host system in sync with others runned on Guests systems.

Comment 8 Dan Callaghan 2013-04-11 04:55:54 UTC
Beaker 0.12 has been released.

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