Bug 701999 - Shouldn't start by default
Summary: Shouldn't start by default
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: lldpad
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Petr Šabata
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker, RejectedNTH
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-04 13:58 UTC by Bastien Nocera
Modified: 2011-11-25 02:07 UTC (History)
13 users (show)

Fixed In Version: fcoe-utils-1.0.20-5.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-06 14:10:34 UTC
Type: ---


Attachments (Terms of Use)
enable lldpad and fcoe services when installing to an fcoe disk (806 bytes, patch)
2011-09-17 21:42 UTC, Adam Williamson
no flags Details | Diff

Description Bastien Nocera 2011-05-04 13:58:37 UTC
lldpad-0.9.41-2.fc15.x86_64

When FCoE isn't configured, or used, lldpad shouldn't start by default. It's completely unneeded on desktops, laptops, and even most server setups.

Instead, it should be started when required, by the fcoe-utils programs (using socket activation from systemd, udev, dbus, or anything else).

Comment 1 James Laska 2011-05-04 15:57:43 UTC
I agree, but I'm not sure this is a release blocker.  I'd certainly vote for this as a nice-to-have fix for Fedora 15.  This would mean that if a tested fix is a available before RC1, it would be included.

-1 blocker, +1 NTH

Comment 2 Petr Šabata 2011-05-04 16:03:16 UTC
We will have to disable services depending on lldpad as well, such as fcoe. I don't know if there are any other. If this is not required, lldpad & fcoe-utils shouldn't even be included in the default Fedora installation.

Generally, I am for this idea.

Should I make lldpad & fcoe-utils builds without the 'init' patches (enabling them by default) for testing?

Comment 3 James Laska 2011-05-04 16:07:52 UTC
(In reply to comment #2)
> We will have to disable services depending on lldpad as well, such as fcoe. I
> don't know if there are any other. If this is not required, lldpad & fcoe-utils
> shouldn't even be included in the default Fedora installation.
> 
> Generally, I am for this idea.

Who is responsible for enabling these services?  Should/does anaconda enable them after FCOE installs?

> Should I make lldpad & fcoe-utils builds without the 'init' patches (enabling
> them by default) for testing?

Yes ... sooner the better.

Comment 4 Petr Šabata 2011-05-04 16:11:47 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > We will have to disable services depending on lldpad as well, such as fcoe. I
> > don't know if there are any other. If this is not required, lldpad & fcoe-utils
> > shouldn't even be included in the default Fedora installation.
> > 
> > Generally, I am for this idea.
> 
> Who is responsible for enabling these services?  Should/does anaconda enable
> them after FCOE installs?

Yes, I believe Anaconda should decide if those get installed and enabled.

> 
> > Should I make lldpad & fcoe-utils builds without the 'init' patches (enabling
> > them by default) for testing?
> 
> Yes ... sooner the better.

On it...

Comment 5 James Laska 2011-05-04 16:23:50 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > We will have to disable services depending on lldpad as well, such as fcoe. I
> > > don't know if there are any other. If this is not required, lldpad & fcoe-utils
> > > shouldn't even be included in the default Fedora installation.
> > > 
> > > Generally, I am for this idea.
> > 
> > Who is responsible for enabling these services?  Should/does anaconda enable
> > them after FCOE installs?
> 
> Yes, I believe Anaconda should decide if those get installed and enabled.

According to anaconda/pyanaconda/storage/devices.py:
   class FcoeDiskDevice(DiskDevice, NetworkStorageDevice):
       """ An FCoE disk. """
       _type = "fcoe"
       _packages = ["fcoe-utils", "dracut-network"]

fcoe-utils and dracut-network are installed whenever an FCOE install is completed.  If that packageset needs adjustment (to include lldpad), please file a bug against anaconda.

Assuming those packages are correct, I think we probably want to keep the services enabled by default once installed (via %scripts).  There isn't support in anaconda at this time to enable services for certain partition scenarios, only to install packages.  To work with this support ... we just need to ensure the desired packages are listed in anaconda, and it should handle the rest?

> > > Should I make lldpad & fcoe-utils builds without the 'init' patches (enabling
> > > them by default) for testing?

Note ... if any additional installer changes are needed ... those will be difficult to implement for F15 given the time in the schedule.

Comment 6 Petr Šabata 2011-05-04 16:32:04 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > > > We will have to disable services depending on lldpad as well, such as fcoe. I
> > > > don't know if there are any other. If this is not required, lldpad & fcoe-utils
> > > > shouldn't even be included in the default Fedora installation.
> > > > 
> > > > Generally, I am for this idea.
> > > 
> > > Who is responsible for enabling these services?  Should/does anaconda enable
> > > them after FCOE installs?
> > 
> > Yes, I believe Anaconda should decide if those get installed and enabled.
> 
> According to anaconda/pyanaconda/storage/devices.py:
>    class FcoeDiskDevice(DiskDevice, NetworkStorageDevice):
>        """ An FCoE disk. """
>        _type = "fcoe"
>        _packages = ["fcoe-utils", "dracut-network"]
> 
> fcoe-utils and dracut-network are installed whenever an FCOE install is
> completed.  If that packageset needs adjustment (to include lldpad), please
> file a bug against anaconda.

No, fcoe-utils depend on lldpad already. No need to pull it in explicitly.

> 
> Assuming those packages are correct, I think we probably want to keep the
> services enabled by default once installed (via %scripts).  There isn't support
> in anaconda at this time to enable services for certain partition scenarios,
> only to install packages.  To work with this support ... we just need to ensure
> the desired packages are listed in anaconda, and it should handle the rest?
> 
> > > > Should I make lldpad & fcoe-utils builds without the 'init' patches (enabling
> > > > them by default) for testing?
> 
> Note ... if any additional installer changes are needed ... those will be
> difficult to implement for F15 given the time in the schedule.

Well, this explains why we did this in the first place. Thanks for looking into that.

Moving this to f16/rawhide now.

Comment 7 James Laska 2011-05-05 11:39:39 UTC
Summarizing the issue ...

 * The live images include lldpad and fcoe-utils to allow users to install to FCOE targets
 * The lldpad service is enabled by default when installed
 * The live image installs itself to any system, which includes lldpad (and iscsi and many other services) regardless of whether FCOE was used during installation

Not really sure there is anything we can do in the F15 timeframe, and this isn't a recent change.  The Final RC1 is scheduled for compose on May 10 (Tues), if there is a well tested fix, we can include something as a nice-to-have for F15, otherwise, I think a more appropriate (and likely invasive anaconda change) will be needed in F16.

Comment 8 Bastien Nocera 2011-05-05 12:46:09 UTC
I only realised that this was installed after it starting eating amounts of CPU (around 10% on an Atom dual-core machine, see bug 701943).

I guess something would need to be done for anaconda and its dependencies to be removed from the installation once a live CD is installed to disk.

Comment 9 Bruno Wolff III 2011-05-06 18:09:30 UTC
Note that it is possible to have services start on live images, but not start by default on an installed system.

Comment 10 Tim Flink 2011-05-06 18:24:15 UTC
Discussed in the 2011-05-06 blocker review meeting. Rejected as F15 final
blocker as it does not hit any release criteria. Rejected as NTH because there
is no clear path to fixing this in a way that would be appropriate given the
short time before F15 release.

If there is a workable proposal to fix this, please re-propose as a
blocker/nth.

Comment 11 Petr Šabata 2011-05-11 12:32:20 UTC
(In reply to comment #9)
> Note that it is possible to have services start on live images, but not start
> by default on an installed system.

That's not enough. The service needs to be enabled on FCoE-based installations.

Comment 12 Adam Williamson 2011-09-02 20:01:08 UTC
any progress here? we have this problem in f16; live images and installs have lldpad running and eating lots of CPU time (thanks to 701943).

Comment 13 Petr Šabata 2011-09-05 12:12:52 UTC
(In reply to comment #12)
> any progress here? we have this problem in f16; live images and installs have
> lldpad running and eating lots of CPU time (thanks to 701943).

Depends on what you mean.  There's an untested fix for lldpad (scratch build available [1]).  Concerning Anaconda...  I don't know.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=701943#c14

Comment 14 Adam Williamson 2011-09-17 21:34:52 UTC
Just noticed this from jlaska in comment #5:

"There isn't support in anaconda at this time to enable services for certain partition scenarios, only to install packages."

I don't believe this is true. I believe _services is used to tell anaconda a given service should be enabled for a certain type of storage, just as you use _packages to tell it a certain package should be installed. See anaconda commit 924de431101c38d5145a354e3e2df07f7ec053cc:

"Make sure multipathd starts on systems using mpath storage (#615040)
    
Multipath storage is currently the only type of storage where we need to
make sure a userspace service is running.  Add in support for us to
expand on this later if necessary."


git diff 700010b205dddd48cd4b04443580487413b5fba9 924de431101c38d5145a354e3e2df07f7ec053cc shows you whole commit which looks pretty generic.

The only problem is it uses chkconfig; it should probably be updated to use systemctl, but at present, either should work for this basic case, since they've been rendered compatible to a degree.

I'll attach a patch for anaconda that I believe should cause anaconda to enable the lldpad and fcoe services when an FCoE disk is being used. This should allow us to have these services disabled by default and rely on anaconda to enable them.

Comment 15 Adam Williamson 2011-09-17 21:42:06 UTC
Created attachment 523729 [details]
enable lldpad and fcoe services when installing to an fcoe disk

This patch just tells anaconda to enable the lldpad and fcoe services when installing to an FCoE disk. This should mean we no longer need to enable those services by default, we can rely on anaconda to do it when necessary.

Comment 16 Adam Williamson 2011-09-17 21:42:28 UTC
CCing some anaconda maintainers: does this patch look sane?

Comment 17 Chris Lumens 2011-09-18 02:35:10 UTC
Yes, that looks reasonable for the non-live case.

On the live case - how do we have services run on the livecd but potentially not on the final installed system?

Comment 18 Adam Williamson 2011-09-18 03:34:12 UTC
I'm not sure I understand - why would we want the service to run in the live boot? Does anaconda need the services running before it starts in order to detect a FCoE disk?

My expectation was we could do rather the opposite: have the services *not* run when booted live, then anaconda could enable them for the installed system only if necessary - just like with a non live install.

Comment 19 Bruno Wolff III 2011-09-18 13:18:17 UTC
My expectation is that hardware would just work with the live image. The real problem with lldpad is that it was consuming lots of resources not that it was running. (Other kinds of services, such as httpd, I wouldn't expect to run by default.)

Once you do an install and you know the system won't need lldpad (at least in the short run), then it makes sense to not run it by default. With a live image you don't know what kind of hardware you are going to run it on.

There are things that just are done / run on the live image. The commands are copied into an init script (I think there have been recent changes to do things more systemdish.) that only does stuff if the kernel command line indicates that a live image is running.

Comment 20 Adam Williamson 2011-09-18 19:38:38 UTC
I admit I know nothing about them, but I don't think FCoE disks 'just work' anyway, they require configuration. Given that booting a Fedora live image and then accessing an FCoE disk from it seems an extremely unusual use case, it doesn't seem to make sense to have this service running while booted live.

Comment 21 Chris Lumens 2011-09-22 13:55:45 UTC
My understanding of things is that if you don't have this service running, you wouldn't be able to see FCoE disks in the live installer.  Is that correct?

I don't necessarily think that's a problem we need to be worried about, mind you.  It seems to me the live installer and FCoE have vastly different use cases.  I just want everyone to be clear.

Adam - can you send your patch to anaconda-maint-list?  If you're not subscribed, just send anyway and I'll approve.

Comment 22 Adam Williamson 2011-09-22 20:13:09 UTC
"My understanding of things is that if you don't have this service running, you
wouldn't be able to see FCoE disks in the live installer.  Is that correct?"

I was kinda working on the assumption that anaconda would still be able to find the disk, but you would need lldpad running on the installed system in order to use it. This is clearly something we need to be sure about, indeed. (Still, couldn't anaconda just start the service when it needed to look for an FCoE disk? Doesn't seem like much of a stretch. Surely it needs to do this in the 'regular installer' case anyway, you don't have the lldpad service running there, do you?) Ditto for the fcoe service itself.

If these indeed don't need to be running when you install, but only when you boot a system with FCoE disks, a solution similar to the device-mapper-multipath one is possible: systemd has the capability to fire a service only if a given file exists (among other neat capabilities), so we simply set the device-mapper-multipath service to be 'enabled' by default but to only actually fire if the file /etc/multipath.conf existed.

Comment 23 Adam Williamson 2011-09-22 20:15:04 UTC
A quick grep in the anaconda source reveals:

pyanaconda/storage/fcoe.py:        self.lldpadStarted = False
pyanaconda/storage/fcoe.py:        if self.lldpadStarted:
pyanaconda/storage/fcoe.py:        iutil.execWithRedirect("lldpad", [ "-d" ],
pyanaconda/storage/fcoe.py:        self.lldpadStarted = True

rather looks like anaconda already has the capability to start lldpad when it needs it. There is no similar code for the fcoe service, which to me implies it isn't actually needed to discover disks.

Comment 24 Petr Šabata 2011-09-23 07:40:06 UTC
(In reply to comment #23)
> A quick grep in the anaconda source reveals:
> 
> pyanaconda/storage/fcoe.py:        self.lldpadStarted = False
> pyanaconda/storage/fcoe.py:        if self.lldpadStarted:
> pyanaconda/storage/fcoe.py:        iutil.execWithRedirect("lldpad", [ "-d" ],
> pyanaconda/storage/fcoe.py:        self.lldpadStarted = True
> 
> rather looks like anaconda already has the capability to start lldpad when it
> needs it. There is no similar code for the fcoe service, which to me implies it
> isn't actually needed to discover disks.

It is and it should be added.

Comment 25 Adam Williamson 2011-09-23 16:56:50 UTC
petr: so both the lldpad and fcoe services (daemons) need to be running for anaconda to be able to discover FCoE-attached disks?

Comment 26 Adam Williamson 2011-09-23 17:00:07 UTC
(and if so, how did it work in f15? or did it...not work?)

Comment 27 Petr Šabata 2011-09-30 09:12:21 UTC
fcoemon manages FCoE interfaces so I'd yes, both are needed.

(In reply to comment #26)
> (and if so, how did it work in f15? or did it...not work?)

I guess it didn't; seems like nobody uses this in Fedora, though...

Comment 28 Adam Williamson 2011-10-04 02:38:19 UTC
well, it just seems odd. I'd assume whoever wrote the code must have had access to reference hardware or *something*. or was it all just written to spec and never actually tested to work?

Comment 29 Chris Lumens 2011-10-05 13:53:58 UTC
It's rare that we actually get the hardware to test this kind of stuff.

So where do we stand with this bug?  We can add the fcoe service as a thing to start up, but that's going backwards from what was asked for in the livecd case.

Comment 30 Adam Williamson 2011-10-05 20:29:20 UTC
it seems to me like we should have lldpad and fcoemon set up to be disabled by default in their packages, but have anaconda activate them if you choose to search for FCoE disks, and have anaconda set them to be activated in the installed system if you actually enable any FCoE disks during install.

Can anaconda do this activate-a-service-when-needed thing when running in a live environment, or not?

Comment 31 David Lehman 2011-10-05 23:00:23 UTC
Why don't we just remove support for so-called advanced storage devices from the live installer and call it a day?

Comment 32 Adam Williamson 2011-10-05 23:29:16 UTC
The only problem with that, again, is that firmware RAID is in 'advanced storage devices', and it wouldn't necessarily make sense to drop that.

but FCoE and iSCSI, as far as I'm concerned, sure. installing to those kind of devices from a live image does seem like a 'doctor, it hurts' kind of scenario to me.

Comment 33 David Lehman 2011-10-06 01:38:57 UTC
Re: needing fcoemon to use fcoe devices: mdmon manages md devices but that doesn't mean we need to run it for anaconda to do it's job on md devices.

Who has tested this and shown that fcoe support is currently broken, or are we all just assuming as much?

Comment 34 David Lehman 2011-10-06 01:40:02 UTC
Either way, FWIW, lldpad can be disabled by default and that will not prevent anaconda from functioning wrt fcoe disks.

Comment 35 Adam Williamson 2011-10-06 01:46:02 UTC
right, but obviously following the same principle, we don't want fcoemon enabled for everything either.

I'm 'assuming' fcoemon needs to be enabled for anaconda on the basis of https://bugzilla.redhat.com/show_bug.cgi?id=701999#c27 , as I personally know jack squat about FCoE. AFAIK QA team doesn't have any FCoE hardware. We don't have any test cases for FCoE. So basically, to my knowledge, we've never done any testing of it for F15 or F16.

Comment 36 David Lehman 2011-10-06 13:44:59 UTC
Go ahead and switch fcoemon to not run by default. We can start it if we find we decide it is needed.

Comment 37 Petr Šabata 2011-10-06 14:01:03 UTC
(In reply to comment #36)
> Go ahead and switch fcoemon to not run by default. We can start it if we find
> we decide it is needed.

Alrighty then...

Comment 38 Petr Šabata 2011-10-06 14:09:48 UTC
New lldpad and fcoe-utils no longer enable their services on installations.

lldpad-0.9.43-5.fc17
fcoe-utils-1.0.20-4.fc17

Comment 39 Adam Williamson 2011-10-06 21:34:59 UTC
can you do this for f16 too? thanks.

Comment 40 Fedora Update System 2011-10-07 09:14:40 UTC
fcoe-utils-1.0.20-4.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/fcoe-utils-1.0.20-4.fc16

Comment 41 Fedora Update System 2011-10-07 09:16:22 UTC
lldpad-0.9.43-5.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/lldpad-0.9.43-5.fc16

Comment 42 Fedora Update System 2011-10-31 14:30:30 UTC
fcoe-utils-1.0.20-5.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/fcoe-utils-1.0.20-5.fc16

Comment 43 Fedora Update System 2011-11-05 01:22:33 UTC
lldpad-0.9.43-5.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 44 Edgar Hoch 2011-11-21 14:54:54 UTC
Please see comment on bug 750193#c4

Comment 45 Fedora Update System 2011-11-25 02:07:36 UTC
fcoe-utils-1.0.20-5.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.


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