Bug 815981

Summary:	initscript needs updating for new config save/restore method
Product:	Red Hat Enterprise Linux 6	Reporter:	Andy Grover <agrover>
Component:	fcoe-target-utils	Assignee:	Andy Grover <agrover>
Status:	CLOSED ERRATA	QA Contact:	Gris Ge <fge>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	6.3	CC:	czhang, fge, kzhang, psabata, qcai, syeghiay
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	824227 (view as bug list)		Environment:
Last Closed:	2012-06-20 13:50:56 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:
Bug Blocks:	750277, 824227

Description Andy Grover 2012-04-24 23:03:03 UTC

fcoe-target.init is still applying tcm_start.sh on service start instead of using saveconfig.json. This means that rebooting the machine will not retain fcoe target configuration

Comment 4 Andy Grover 2012-05-08 23:29:17 UTC

*** Bug 819698 has been marked as a duplicate of this bug. ***

Comment 6 Gris Ge 2012-05-17 10:09:43 UTC

FAILED QA.

restart fcoe-target daemon can restore configure, BUT reboot CANNOT.

This is output after reboot:
====
[root@storageqe-13 ~]# targetcli ls /
targetcli ls /
o- / ................................................ [...]
  o- backstores ..................................... [...]
  | o- block ........................................ [0 Storage Object]
  | o- fileio ....................................... [1 Storage Object]
  | | o- disk1 .................... [/tmp/fcoe-lun1 (10.0G) deactivated]
  | o- pscsi ........................................ [0 Storage Object]
  o- loopback ....................................... [0 Target]
  o- tcm_fc ......................................... [0 Target]
[root@storageqe-13 ~]# chkconfig --list|grep fcoe
fcoe            0:off   1:off   2:on    3:on    4:on    5:on    6:off
fcoe-target     0:off   1:off   2:on    3:on    4:on    5:on    6:off
====

When fcoe-target start, chances are fcoe daemon not yet setup FCoE port. So targetcli refuse to create non-exist target.

Workround: 

Put this line into /etc/rc.local:
====
service fcoe-target restart
====

Possible solutions:
1. fcoe daemon only quit after all FCoE session created. (fcoe need a standalone tool for OS boot for this, like iscsi have iscsistart tool) 

2. Change fcoe-target daemon to S99, but still have chances for failure.

3. Devs use magic.

Comment 9 Andy Grover 2012-05-17 18:06:52 UTC

Petr, how to we ensure fcoe setup is complete before fcoe-target setup?

Comment 10 Petr Šabata 2012-05-22 14:00:21 UTC

You can't really ensure that.  Anything could go wrong.

The best thing you could do at the moment is check the output of fcoeadm, possibly in a loop with a timeout.

Comment 11 Andy Grover 2012-05-22 22:20:36 UTC

yuck, but ok. So:

If there are configured fcoe targets, grep the output of fcoeadm -i until they show up and then proceed.

What should the timeout be?

Comment 16 Petr Šabata 2012-05-23 12:51:23 UTC

(In reply to comment #11)
> yuck, but ok. So:
> 
> If there are configured fcoe targets, grep the output of fcoeadm -i until
> they show up and then proceed.
> 
> What should the timeout be?

I'd go with the usual 60 seconds.  You could also make that configurable since you're going to hack this in :)

Comment 19 errata-xmlrpc 2012-06-20 13:50:56 UTC

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.

http://rhn.redhat.com/errata/RHBA-2012-0854.html