Bug 824227

Summary:	initscript needs updating for new config save/restore method
Product:	Red Hat Enterprise Linux 6	Reporter:	Qian Cai <qcai>
Component:	fcoe-target-utils	Assignee:	Andy Grover <agrover>
Status:	CLOSED ERRATA	QA Contact:	Gris Ge <fge>
Severity:	urgent	Docs Contact:
Priority:	high
Version:	6.3	CC:	agrover, czhang, fge, kzhang, psabata, qcai, syeghiay
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	815981	Environment:
Last Closed:	2013-02-21 10:48:44 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:	815981
Bug Blocks:	750277

Description Qian Cai 2012-05-23 03:08:19 UTC

+++ This bug was initially created as a clone of Bug #815981 +++

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 1 Qian Cai 2012-05-23 03:11:10 UTC

This is to track the remaining issue.

Gris Ge 2012-05-17 06:09:43 EDT

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 14:06:52 EDT 

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

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

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 18:20:36 EDT

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 12 Andy Grover 2012-05-22 18:49:51 EDT

Changes too big and too late for 6.3. Nominating for 6.3.z and 6.4.

Comment 3 Andy Grover 2012-05-25 15:48:34 UTC

The workaround fit better in python-rtslib package: python-rtslib-2.1.fb12-3.el6.

Comment 5 Gris Ge 2013-01-23 09:04:06 UTC

VERIFY.

fcoe-target-utils-2.0rc1.fb16-3.el6.noarch and python-rtslib-2.1.fb21-1.el6.noarch works well for config save and restore.

Comment 7 errata-xmlrpc 2013-02-21 10:48:44 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-2013-0457.html