Bug 815981 - initscript needs updating for new config save/restore method
Summary: initscript needs updating for new config save/restore method
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: fcoe-target-utils
Version: 6.3
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: Andy Grover
QA Contact: Gris Ge
URL:
Whiteboard:
Depends On:
Blocks: 750277 824227
TreeView+ depends on / blocked
 
Reported: 2012-04-24 23:03 UTC by Andy Grover
Modified: 2012-06-20 13:50 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 824227 (view as bug list)
Environment:
Last Closed: 2012-06-20 13:50:56 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0854 0 normal SHIPPED_LIVE fcoe-target-utils bug fix and enhancement update 2012-06-19 20:48:32 UTC

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


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