Bug 1313930 - Service provisioning based on orchestration template not respect zone
Service provisioning based on orchestration template not respect zone
Status: CLOSED DUPLICATE of bug 1380535
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Automate (Show other bugs)
Unspecified Unspecified
medium Severity medium
: GA
: cfme-future
Assigned To: Bill Wei
Alex Newman
Depends On:
  Show dependency treegraph
Reported: 2016-03-02 11:00 EST by kpichard
Modified: 2016-10-18 10:17 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-10-18 10:17:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description kpichard 2016-03-02 11:00:57 EST
Description of problem:
On cloudForms when you have two zones with two instance worker (one on each zone).
Each instance hasn't access to the provider that isn't in the other region. 
When you create an orchestration template and a service to run this orchestration, then you choose one provider, to run this service. 
The service is started but tasks are plited into all worker instance in the region regardless the zone where provider is.   

Version-Release number of selected component (if applicable):

How reproducible: 

Every time

Steps to Reproduce:

1. Spawn 3 cloudforms instances, 1 db (accessible from 2 network), 2 worker (one on each network), put each worker instance into a different zone. 

2. Attach 2 providers (in my case openstack) one in each worker zone. 

3. Create an orchestration template, then attach it to the catalogue, run it on one of the selected provider.

Actual results:
It split the tasks on all worker instances in region regardless the zone which the openstack is attached. 

Expected results:
As you choose the provider you when to run the orchestration, it should take care of the zone where you provider is attached to split tasks on worker in this zone only.

Additional info:
My two worker instance are on separated network.
Comment 2 Greg McCullough 2016-03-10 08:58:15 EST
Service template provision tasks often run with a nil zone since they do not have a link back to a provider to determine the zone.  But with orchestration if the catalog item was configured with a provider it should the provider's zone.  If the provider selection is deferred to automate that complicates the issue and that may need to be a separate ticket.
Comment 3 kpichard 2016-04-04 03:12:27 EDT
Hello Greg,

In this case the orchestration task was attached to a provider, so in my view the product is supposed to associate this task to a proper zone and to a proper worker.

I don't get the point with the separated ticket ?
Comment 4 Bill Wei 2016-10-18 10:17:18 EDT

*** This bug has been marked as a duplicate of bug 1380535 ***

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