Deployment failed on Centos due to error: Cannot find device "hapr-host"

[Tatyanka]

VERSION:
  feature_groups:
    - mirantis
  production: "docker"
  release: "6.1"
  api: "1.0"
  build_number: "178"
  build_id: "2015-03-09_22-54-44"
  nailgun_sha: "a9a6578a649a2a006c4810b3d0aa6876ac6e8b83"
  python-fuelclient_sha: "4eb787f1ad969bd23c93d192865543dbd45a8626"
  astute_sha: "2d61ee42ec6dae3181d292c7769d32e40d463893"
  fuellib_sha: "62e68af896887ebe18944e6a0a9721e269119ad4"
  ostf_sha: "8df5f2fcdae3bc9ea7d700ffd64db820baf51914"
  fuelmain_sha: "c73b87f7cbc371307a21c368a45a65aa3f4b7a5d"

OS: Centos

Deploy cluster in HA mode with Murano and Neutron GRE

Scenario:
1. Create cluster. Set install Murano option
2. Add 1 node with controller role
3. Add 1 nodes with compute role
4. Deploy the cluster
5. Verify Murano services
6. Run OSTF
7. Register Murano image
8. Run OSTF Murano platform tests

Actual result:
Deployment failed. Task hiera failed on compute according astute.yaml is not here

[Dima Shulyak (dshulyak)]

It is expected behaviour that astute.yaml will not be created on compute, if task on controller failed.
And it was openstack-controller.pp in current case:

2015-03-10T03:26:57 debug: [416] 16b16d81-d428-4d95-a4b8-4eb24424a12b: MC agent 'puppetd', method 'last_run_summary', results: {:sender=>"1", :statuscode=>0, :statusmsg=>"OK", :data=>{:output=>"Currently stopped; last completed run 85 seconds ago", :status=>"stopped", :events=>{"total"=>169, "failure"=>0, "success"=>169}, :enabled=>1, :running=>0, :time=>{"config_retrieval"=>5.193858, "total"=>16.207686, "schedule"=>0.001111, "last_run"=>1425957932, "filebucket"=>0.000218, "file"=>0.442138, "exec"=>10.570361}, :idling=>0, :runtime=>85, :stopped=>1, :resources=>{"scheduled"=>0, "failed"=>0, "skipped"=>0, "total"=>181, "out_of_sync"=>169, "changed"=>169, "restarted"=>19, "failed_to_restart"=>0}, :lastrun=>1425957932, :version=>{"config"=>1425957900, "puppet"=>"3.4.2"}, :changes=>{"total"=>169}}}
  2015-03-10T03:26:57 debug: [416] Node 1(primary-controller) status: error
2015-03-10T03:26:57 debug: [416] Node 1 has failed to deploy. There is no more retries for puppet run.
2015-03-10T03:26:57 debug: [416] {"nodes"=>[{"status"=>"error", "error_type"=>"deploy", "uid"=>"1", "role"=>"primary-controller"}]}
2015-03-10T03:26:57 err: [416] Task '{"priority"=>1300, "type"=>"puppet", "uids"=>["1"], "parameters"=>{"puppet_modules"=>"/etc/puppet/modules", "puppet_manifest"=>"/etc/puppet/modules/osnailyfacter/modular/openstack-controller/openstack-controller.pp", "timeout"=>3600, "cwd"=>"/"}}' on node 1 valid, but failed

There was errors in puppet log

2015-03-10T03:25:17.745912+00:00 notice: (/Stage[main]/Openstack::Ha::Nova/Openstack::Ha::Haproxy_service[nova-api-1]/Exec[haproxy restart for nova-api-1]/returns) 2015/03/09_20:25:17 ERROR: Cannot find device "hapr-host"

If those errors are not root cause of this failure, then puppetd reported wrong result

[Oleksiy Molchanov (omolchanov)]

I didn't reproduce this bug on the newest ISO.

Dima, the errors you provided do exist, but they doesn't break the deployment.

I will open a new bug to fix the ocf and this one will set to incomplete.

[Bogdan Dobrelya (bogdando)]

Please do not create additional bugs, we can fix ocf in the scope of this bug

[Oleksiy Molchanov (omolchanov)]

We cannot fix this, because we should lower priority. Right now we have SCF that doesn't allow us to fix non-critical or non-high bugs.

[Oleksiy Molchanov (omolchanov)]

As SCF was moved, changing to confirmed.

[Bartłomiej Piotrowski (bpiotrowski)]

I can't really reproduce the problem using iso 315. From what I understand. we ensure that the interface is created here[1].

[1] https://github.com/stackforge/fuel-library/blob/master/deployment/puppet/cluster/files/ocf/ns_haproxy#L285

Oleksiy, what do you think?

[Oleksiy Molchanov (omolchanov)]

Bartlomiej, this errors appear only during haproxy pcs resource restart as we do not have any check here - https://github.com/stackforge/fuel-library/blob/master/deployment/puppet/cluster/files/ocf/ns_haproxy#L299 and lower.

I am lowering this bug to medium cause it doesn't break anything.

[Bogdan Dobrelya (bogdando)]

Raised to high as it seems as a major regression in the ns_haproxy OCF logic and there are several duplicates reported

[Bogdan Dobrelya (bogdando)]

But if this issue doesn't break deployment, I guess we could lower this to medium again

[Oleksiy Molchanov (omolchanov)]

Marking it as duplicate for 1459678, I will revise it there.