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).
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
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?
(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.
(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...
(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.
(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.
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.
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.
Note that it is possible to have services start on live images, but not start by default on an installed system.
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.
(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.
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).
(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
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.
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.
CCing some anaconda maintainers: does this patch look sane?
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?
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.
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.
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.
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.
"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.
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.
(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.
petr: so both the lldpad and fcoe services (daemons) need to be running for anaconda to be able to discover FCoE-attached disks?
(and if so, how did it work in f15? or did it...not work?)
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...
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?
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.
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?
Why don't we just remove support for so-called advanced storage devices from the live installer and call it a day?
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.
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?
Either way, FWIW, lldpad can be disabled by default and that will not prevent anaconda from functioning wrt fcoe disks.
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.
Go ahead and switch fcoemon to not run by default. We can start it if we find we decide it is needed.
(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...
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
can you do this for f16 too? thanks.
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
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
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
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.
Please see comment on bug 750193#c4
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.