Description of problem: Customers that add a standard Openstack env. to the Infrastructure / Openstack Infra will not receive UI error and will receive zero env data as expected. GSS has had a number of customers and escalation due to the Openstack env being added in the wrong location. CloudForms needs to inform the user that the env is of the wrong type. Version-Release number of selected component (if applicable): 5.4.0/5.4.1 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This appears to be the error that happens during a Refresh on a provider setup this way: (Notably, the ERROR -- : [NoMethodError]: undefined method `ports' for nil:NilClass) > [----] I, [2015-07-07T05:11:58.209543 #3203:42fe8c] INFO -- : MIQ(EmsRefresh::Refreshers::OpenstackInfraRefresher.refresh) Refreshing all targets... > [----] I, [2015-07-07T05:11:58.209650 #3203:42fe8c] INFO -- : MIQ(EmsRefresh::Refreshers::OpenstackInfraRefresher.refresh) EMS: [MyTestOpenStack], id: [1] Refreshing targets for EMS: [MyTestOpenStack], id: [1]... > [----] I, [2015-07-07T05:11:58.209732 #3203:42fe8c] INFO -- : MIQ(EmsRefresh::Refreshers::OpenstackInfraRefresher.refresh) EMS: [MyTestOpenStack], id: [1] EmsOpenstackInfra [MyTestOpenStack] id [1] > [----] I, [2015-07-07T05:11:59.092361 #3203:42fe8c] INFO -- : <Fog> MIQ(EmsRefresh::Parsers::OpenstackInfra.ems_inv_to_hashes) Collecting data for EMS name: [MyTestOpenStack] id: [1]... > [----] E, [2015-07-07T05:11:59.263963 #3203:42fe8c] ERROR -- : MIQ(EmsRefresh::Refreshers::OpenstackInfraRefresher.refresh) EMS: [MyTestOpenStack], id: [1] Refresh failed > [----] E, [2015-07-07T05:11:59.264090 #3203:42fe8c] ERROR -- : [NoMethodError]: undefined method `ports' for nil:NilClass Method:[rescue in block in refresh] > [----] E, [2015-07-07T05:11:59.264227 #3203:42fe8c] ERROR -- : /var/www/miq/vmdb/app/models/ems_refresh/parsers/openstack_infra.rb:67:in `hosts_ports' > /var/www/miq/vmdb/app/models/ems_refresh/parsers/openstack_infra.rb:79:in `load_hosts' > /var/www/miq/vmdb/app/models/ems_refresh/parsers/openstack_infra.rb:35:in `ems_inv_to_hashes' > /var/www/miq/vmdb/app/models/ems_refresh/parsers/openstack_infra.rb:8:in `ems_inv_to_hashes' > /var/www/miq/vmdb/app/models/ems_refresh/refreshers/openstack_infra_refresher.rb:7:in `parse_inventory' > /var/www/miq/vmdb/app/models/ems_refresh/refreshers/ems_refresher_mixin.rb:20:in `block in refresh' > /var/www/miq/vmdb/app/models/ems_refresh/refreshers/ems_refresher_mixin.rb:8:in `each' > /var/www/miq/vmdb/app/models/ems_refresh/refreshers/ems_refresher_mixin.rb:8:in `refresh' > /var/www/miq/vmdb/app/models/ems_refresh/refreshers/base_refresher.rb:8:in `refresh' > /var/www/miq/vmdb/app/models/ems_refresh.rb:80:in `block in refresh' > /var/www/miq/vmdb/app/models/ems_refresh.rb:78:in `each' > /var/www/miq/vmdb/app/models/ems_refresh.rb:78:in `refresh' > /var/www/miq/vmdb/app/models/miq_queue.rb:356:in `block in deliver' > /opt/rubies/ruby-2.0.0-p645/lib/ruby/2.0.0/timeout.rb:66:in `timeout' > /var/www/miq/vmdb/app/models/miq_queue.rb:352:in `deliver' > /var/www/miq/vmdb/lib/workers/queue_worker_base.rb:107:in `deliver_queue_message' > /var/www/miq/vmdb/lib/workers/queue_worker_base.rb:135:in `deliver_message' > /var/www/miq/vmdb/lib/workers/queue_worker_base.rb:152:in `block in do_work' > /var/www/miq/vmdb/lib/workers/queue_worker_base.rb:146:in `loop' > /var/www/miq/vmdb/lib/workers/queue_worker_base.rb:146:in `do_work' > /var/www/miq/vmdb/lib/workers/worker_base.rb:323:in `block in do_work_loop' > /var/www/miq/vmdb/lib/workers/worker_base.rb:320:in `loop' > /var/www/miq/vmdb/lib/workers/worker_base.rb:320:in `do_work_loop' > /var/www/miq/vmdb/lib/workers/worker_base.rb:141:in `run' > /var/www/miq/vmdb/lib/workers/worker_base.rb:122:in `start' > /var/www/miq/vmdb/lib/workers/worker_base.rb:23:in `start_worker' > /var/www/miq/vmdb/lib/workers/bin/worker.rb:3:in `<top (required)>' > /opt/rubies/ruby-2.0.0-p645/lib/ruby/gems/2.0.0/bundler/gems/rails-4842a8377644/railties/lib/rails/commands/runner.rb:52:in `eval' > /opt/rubies/ruby-2.0.0-p645/lib/ruby/gems/2.0.0/bundler/gems/rails-4842a8377644/railties/lib/rails/commands/runner.rb:52:in `<top (required)>' > /opt/rubies/ruby-2.0.0-p645/lib/ruby/gems/2.0.0/bundler/gems/rails-4842a8377644/railties/lib/rails/commands.rb:64:in `require' > /opt/rubies/ruby-2.0.0-p645/lib/ruby/gems/2.0.0/bundler/gems/rails-4842a8377644/railties/lib/rails/commands.rb:64:in `<top (required)>' > script/rails:6:in `require' > script/rails:6:in `<main>' > [----] E, [2015-07-07T05:11:59.264270 #3203:42fe8c] ERROR -- : MIQ(EmsRefresh::Refreshers::OpenstackInfraRefresher.refresh) EMS: [MyTestOpenStack], id: [1] Unable to perform refresh for the following targets: > [----] E, [2015-07-07T05:11:59.264398 #3203:42fe8c] ERROR -- : --- EmsOpenstackInfra [MyTestOpenStack] id [1] > [----] I, [2015-07-07T05:11:59.276935 #3203:42fe8c] INFO -- : MIQ(EmsRefresh::Refreshers::OpenstackInfraRefresher.refresh) Refreshing all targets...Complete Note that the user will not see this error until a refresh occurs (so, no up front information is provided when they add the provider). I'm providing this mainly for Knowledge Base information for use in diagnosing these issues until we can get this fixed.
Ladas, is there any way we can catch this when the user adds the Keystone server under OpenStack Infra? Not sure how to detect this when the provider is being added, but maybe you have a good idea.
Well I guess first thing should be a proper helptext in the UI, explaining what the Openstack Infra is. Not sure if I can do any proper validation. it's basically Openstack like any other. It just happens that using that Openstack you deploy another Openstack and you can see the connection. I could do at least a check, that Ironic service is there maybe? Which would be maybe tied to validate credentials? Not sure if there is any other validation in the UI currently? That in general would be a check if all required OpenStack services are there.
https://github.com/ManageIQ/manageiq/pull/3784 The above PR simply changes the text on the "Add New Providers" page to be more specific. We should probably investigate going further with the validations to see if there's a way to prevent users from adding any OpenStack Keystone server.
New commit detected on manageiq/master: https://github.com/ManageIQ/manageiq/commit/b7c8100366997a4addc9e848e62c507d1bdf7cc2 commit b7c8100366997a4addc9e848e62c507d1bdf7cc2 Author: Greg Blomquist <gblomqui> AuthorDate: Mon Aug 10 15:35:36 2015 -0400 Commit: Greg Blomquist <gblomqui> CommitDate: Mon Aug 10 17:16:23 2015 -0400 Update name of OpenStack Infrastructure Change OpenStack infrastructure to "OpenStack Platform Director" in an attempt to call attention to the fact that a very specific type of OpenStack Infrastructure is supported. https://bugzilla.redhat.com/show_bug.cgi?id=1249692 https://bugzilla.redhat.com/show_bug.cgi?id=1251139 app/models/manageiq/providers/openstack/infra_manager.rb | 2 +- spec/models/ems_openstack_infra_spec.rb | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
I'm putting this bug back to assigned to see if there's any other way we can deal with this besides with just naming/documentation. It would definitely be nice to have a way to alert users who attempt to add an OpenStack Cloud as an OpenStack Infrastructure provider. Just not sure what it is. If Ladas can't find a way to do it, then we can put this to POST and just rely on the name change commit from comment #6. Note: the downstream bug (bug #1251139) is fixed the change in comment #6, and we are not currently targeting a specific backported version for a more detailed patch.
New commit detected on cfme/5.4.z: https://code.engineering.redhat.com/gerrit/gitweb?p=cfme.git;a=commitdiff;h=918d880e607e30b16fae654165f3266ff154d11c commit 918d880e607e30b16fae654165f3266ff154d11c Author: Greg Blomquist <gblomqui> AuthorDate: Sun Aug 16 17:25:31 2015 -0400 Commit: Greg Blomquist <gblomqui> CommitDate: Tue Aug 18 13:29:55 2015 -0400 Update name of OpenStack Infrastructure Change OpenStack infrastructure to "OpenStack Platform Director" in an attempt to call attention to the fact that a very specific type of OpenStack Infrastructure is supported. https://bugzilla.redhat.com/show_bug.cgi?id=1249692 https://bugzilla.redhat.com/show_bug.cgi?id=1251139 vmdb/app/models/ems_openstack_infra.rb | 2 +- vmdb/spec/models/ems_openstack_infra_spec.rb | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
Verified fixed in version 5.5.0.3 It seems that we cannot really know what sort of openstack the user is trying to add so the only way to help the situation is to name the provider type "OpenStack Platform Director" specifically in the UI so they hopefully realize they are making a mistake. Important! Customer is able to add the OpenStack Cloud added as OpenStack Infra provider and there will be no message to inform him about mistake.
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/RHSA-2015:2551