5:48 a.m.
Currently there are some challenges to this. First for LNet we have lnetctl
and lctl for configuring the network. The nice thing about lnetctl it is
light weight with no need of liblustreapi. This is not the case for lctl.
So if you wanted a LNET only rpm it would only have to support lnetctl.
Lastly setting LNet parameters via procfs/sysfs is handled only with lctl
which again introduces the liblustreapi dependency. That I hope to resolve
with LU-5030.
On Thu, Nov 20, 2014 at 10:49 AM, Nathan Rutman <nathan.rutman(a)seagate.com>
wrote:
What does the community think about splitting the LNET build out of
Lustre
as a separate set of (source and binary) RPMs?
This would make it easier/faster to build, install, and upgrade Lustre in
existing installations without changing things we don't need to. It would
also make it easier to re-use LNET in other projects, and make it easier
for unusual users to maintain a customized LNET.
I have no idea how this might affect landing in mainstream kernel.
Thoughts / opinions?
*--*
*Nathan Rutman · Principal Systems ArchitectSeagate Technology** · *+1
503 877-9507* · *PST
_______________________________________________
lwg mailing list
lwg(a)lists.opensfs.org
http://lists.opensfs.org/listinfo.cgi/lwg-opensfs.org
2:05 p.m.
New subject: [Lwg] Splitting up Lustre and LNET RPMs?
James,
For a very long time there was ptlctl, which was an lnet-specific (portals) subset of the
lctl commands. I don't recall off hand if this still exists anymore, or if it was
removed in the last release because nobody used it.
As for /proc interface handling, that could be moved into libcfs/utils for LNet and then
used by lustre tools. Since we are also looking to move from /proc to /sys tunables, and
the handling of these parameters may take significant changes in the code, it would
probably be a good time to rewrite it and put it under an LGPL license at the same time.
Cheers, Andreas
On Nov 24, 2014, at 11:55, James Simmons
<uja.ornl@gmail.com<mailto:uja.ornl@gmail.com>> wrote:
Currently there are some challenges to this. First for LNet we have lnetctl and lctl for
configuring the network. The nice thing about lnetctl it is light weight with no need of
liblustreapi. This is not the case for lctl. So if you wanted a LNET only rpm it would
only have to support lnetctl. Lastly setting LNet parameters via procfs/sysfs is handled
only with lctl which again introduces the liblustreapi dependency. That I hope to resolve
with LU-5030.
On Thu, Nov 20, 2014 at 10:49 AM, Nathan Rutman
<nathan.rutman@seagate.com<mailto:nathan.rutman@seagate.com>> wrote:
What does the community think about splitting the LNET build out of Lustre as a separate
set of (source and binary) RPMs?
This would make it easier/faster to build, install, and upgrade Lustre in existing
installations without changing things we don't need to. It would also make it easier
to re-use LNET in other projects, and make it easier for unusual users to maintain a
customized LNET.
I have no idea how this might affect landing in mainstream kernel.
Thoughts / opinions?
--
Nathan Rutman · Principal Systems Architect
Seagate Technology · +1 503 877-9507<tel:%2B1%20503%20877-9507> · PST
_______________________________________________
lwg mailing list
lwg@lists.opensfs.org<mailto:lwg@lists.opensfs.org>
http://lists.opensfs.org/listinfo.cgi/lwg-opensfs.org
_______________________________________________
HPDD-discuss mailing list
HPDD-discuss@lists.01.org<mailto:HPDD-discuss@lists.01.org>
https://lists.01.org/mailman/listinfo/hpdd-discuss
9:43 a.m.
New subject: [Lwg] Splitting up Lustre and LNET RPMs?
Most of those challenges are the result of sloppy command design and
code layering violations. It might be worth while to split lnet into
its own project simply because it would more naturally help enforce
clear APIs and devisions of responsibility amongst the tools.
You are certainly correct that splitting LNet out would be more work
than just changing build systems. Some real code work would be
necessary as well.
While we are at it, maybe ptlrpc should be its own project as well. :)
Chris
On 11/24/2014 10:48 AM, James Simmons wrote:
Currently there are some challenges to this. First for LNet we have
lnetctl and lctl for configuring the network. The nice thing about
lnetctl it is light weight with no need of liblustreapi. This is not the
case for lctl. So if you wanted a LNET only rpm it would only have to
support lnetctl. Lastly setting LNet parameters via procfs/sysfs is
handled only with lctl which again introduces the liblustreapi
dependency. That I hope to resolve with LU-5030.
On Thu, Nov 20, 2014 at 10:49 AM, Nathan Rutman
<nathan.rutman(a)seagate.com <mailto:nathan.rutman@seagate.com>> wrote:
What does the community think about splitting the LNET build out of
Lustre as a separate set of (source and binary) RPMs?
This would make it easier/faster to build, install, and upgrade
Lustre in existing installations without changing things we don't
need to. It would also make it easier to re-use LNET in other
projects, and make it easier for unusual users to maintain a
customized LNET.
I have no idea how this might affect landing in mainstream kernel.
Thoughts / opinions?
*--*
*Nathan Rutman · Principal Systems Architect
Seagate Technology** · *+1 503 877-9507
<tel:%2B1%20503%20877-9507>* · *PST
_______________________________________________
lwg mailing list
lwg(a)lists.opensfs.org <mailto:lwg@lists.opensfs.org>
http://lists.opensfs.org/listinfo.cgi/lwg-opensfs.org
_______________________________________________
HPDD-discuss mailing list
HPDD-discuss(a)lists.01.org
https://lists.01.org/mailman/listinfo/hpdd-discuss
9:57 a.m.
New subject: [Lwg] Splitting up Lustre and LNET RPMs?
It would also be a good idea to move the commands themselves to a different project. For
one thing, this will make it easier for Linux distributions to package the Lustre utils
for use with the upstream modules. It also seems like a better practice, in general,
for userspace code to be kept in a different project. See e2fsprogs for a good example.
robert
On Nov 26, 2014, at 14:43 , Christopher J. Morrone
<morrone2(a)llnl.gov> wrote:
Most of those challenges are the result of sloppy command design and code layering
violations. It might be worth while to split lnet into its own project simply because it
would more naturally help enforce clear APIs and devisions of responsibility amongst the
tools.
You are certainly correct that splitting LNet out would be more work than just changing
build systems. Some real code work would be necessary as well.
While we are at it, maybe ptlrpc should be its own project as well. :)
Chris
On 11/24/2014 10:48 AM, James Simmons wrote:
> Currently there are some challenges to this. First for LNet we have
> lnetctl and lctl for configuring the network. The nice thing about
> lnetctl it is light weight with no need of liblustreapi. This is not the
> case for lctl. So if you wanted a LNET only rpm it would only have to
> support lnetctl. Lastly setting LNet parameters via procfs/sysfs is
> handled only with lctl which again introduces the liblustreapi
> dependency. That I hope to resolve with LU-5030.
>
> On Thu, Nov 20, 2014 at 10:49 AM, Nathan Rutman
> <nathan.rutman(a)seagate.com <mailto:nathan.rutman@seagate.com>> wrote:
>
> What does the community think about splitting the LNET build out of
> Lustre as a separate set of (source and binary) RPMs?
> This would make it easier/faster to build, install, and upgrade
> Lustre in existing installations without changing things we don't
> need to. It would also make it easier to re-use LNET in other
> projects, and make it easier for unusual users to maintain a
> customized LNET.
> I have no idea how this might affect landing in mainstream kernel.
> Thoughts / opinions?
>
> *--*
> *Nathan Rutman · Principal Systems Architect
> Seagate Technology** · *+1 503 877-9507
> <tel:%2B1%20503%20877-9507>* · *PST
>
> _______________________________________________
> lwg mailing list
> lwg(a)lists.opensfs.org <mailto:lwg@lists.opensfs.org>
> http://lists.opensfs.org/listinfo.cgi/lwg-opensfs.org
>
>
>
>
> _______________________________________________
> HPDD-discuss mailing list
> HPDD-discuss(a)lists.01.org
> https://lists.01.org/mailman/listinfo/hpdd-discuss
>
_______________________________________________
HPDD-discuss mailing list
HPDD-discuss(a)lists.01.org
https://lists.01.org/mailman/listinfo/hpdd-discuss
2853
days inactive
2855
days old
3 comments
4 participants
participants (4)
-
Christopher J. Morrone -
Dilger, Andreas -
James Simmons -
Read, Robert