Bug 1100181

Summary:	Beaker should assign an externally routable floating IP address to OpenStack systems
Product:	[Retired] Beaker	Reporter:	Nick Coghlan <ncoghlan>
Component:	scheduler	Assignee:	Dan Callaghan <dcallagh>
Status:	CLOSED WONTFIX	QA Contact:	tools-bugs <tools-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	develop	CC:	aigao, asaha, dcallagh, rmancy
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-05-30 07:02:09 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:	1040239
Bug Blocks:

Description Nick Coghlan 2014-05-22 07:55:49 UTC

The initial OpenStack integration in bug 1040239 relies on the default IP address assigned to the created OpenStack instances. This is sufficient to get single host tests running (since the instance can still contact the Beaker lab controller and server as a client), but doesn't reliably support multihost testing, and doesn't allow SSH access to the running instances at all.

Beaker should assign a floating IP address and report that in the web UI rather than the local instance address.

Comment 1 Dan Callaghan 2014-05-27 00:23:31 UTC

On Gerrit: http://gerrit.beaker-project.org/3103

Comment 4 Dan Callaghan 2014-05-28 00:17:19 UTC

As implemented this breaks rhts-sync-set/block, even for single-host recipe sets syncing to themselves (such as the patchbot dogfood jobs).

I'm still not exactly sure why... it must be related to the fact that beah is trying to sync with the floating IP address, which is neither a hostname nor IP address belonging to the actual test system (from its point of view).

Comment 5 Dan Callaghan 2014-05-30 07:01:45 UTC

It turns out that assigning floating IPs to the OpenStack instances is not a good approach.

The problem is that the instances themselves don't know about their own floating IP address. Similarly the hostname for the floating IP address (if it has working A<->PTR records at all) won't match the system's actual hostname. There are a lot of places where we assume that the system has a working, valid FQDN in DNS, since that's always been a requirement of Beaker.

For example, beah uses DNS to figure out all the possible hostnames for "this" system, which it needs to know as part of its event-passing stuff for rhts-sync-block. I tried overriding it with HOSTNAME= in beah_beaker.conf but then straight away the dogfood jobs hit an error because they were creating an LC with an IP address for its hostname which results in an invalid e-mail address.

I think it would just be creating way too much complexity and drama.

If you want your OpenStack instances to have a public IP address for SSH'ing into them, you will have to use a public network in OpenStack.

So I'm closing this as WONTFIX, and will revert the patch that was committed.

(It does mean that when we enable multihost recipe sets on OpenStack we may need to make it all-or-nothing (either all recipes in the recipe set are on OpenStack, or none are) to deal with the likelihood that the OpenStack instances are behind a NAT.)