Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Nagendra Tomar <Nagendra.Tomar@microsoft.com>
CC:     Anna Schumaker <anna.schumaker@netapp.com>,
        Olga Kornievskaia <aglo@umich.edu>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [EXTERNAL] [PATCH v3 0/5] SUNRPC: Create sysfs files for changing
 IP address
Thread-Topic: [EXTERNAL] [PATCH v3 0/5] SUNRPC: Create sysfs files for
 changing IP address
Thread-Index: AQHXIZBVLVquEkVXvE+nUFCuYvpQ/Q==
Date:   Thu, 25 Mar 2021 16:03:01 +0000
Message-ID: <FCA81F8D-9CB6-4085-AE08-AF5ADE4F915B@oracle.com>
References: <SG2P153MB0361F4B85684C232E63C04749E679@SG2P153MB0361.APCP153.PROD.OUTLOOK.COM>
 <CAN-5tyFLha3Wvy6m12S=9m+Yu0pg5wtEn_+4=aadXzECwBzoWA@mail.gmail.com>
 <SG2P153MB0361BA94D52E1123DEE7E1EC9E629@SG2P153MB0361.APCP153.PROD.OUTLOOK.COM>
 <CAFX2JfkH2c0jXHQnKezfcCFs9rwNVhnTtg+8pOtTZbLyKU7VBw@mail.gmail.com>
 <SG2P153MB036155B6E43C625295AEBDC19E629@SG2P153MB0361.APCP153.PROD.OUTLOOK.COM>
In-Reply-To: <SG2P153MB036155B6E43C625295AEBDC19E629@SG2P153MB0361.APCP153.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <99D007E0F312C84AA102F07CEA65C9DF@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 87ee8b13-b5d6-406a-1dc8-08d8efa777af
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2021 16:03:01.8650
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 1R4CSEvWEou9WvIUMDJeetUs99nHlHBC4vbvZmlBmTVDLwZ1IBbY2mf73EE1CU+N1xZo5rPz7u61zyL/IK1s7w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR10MB4387
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9934 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 spamscore=0
 mlxscore=0 phishscore=0 suspectscore=0 mlxlogscore=999 bulkscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2103250114
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9934 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 mlxscore=0
 priorityscore=1501 bulkscore=0 impostorscore=0 lowpriorityscore=0
 phishscore=0 mlxlogscore=999 suspectscore=0 clxscore=1015 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2103250113
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Mar 25, 2021, at 11:03 AM, Nagendra Tomar <Nagendra.Tomar@microsoft.co=
m> wrote:
>=20
>> I've been thinking of the write-to-sysfs approach as just the kernel
>> interface. I would expect there to be some future userspace tool built
>> on the sysfs files that is easier for admins to use. This future tool
>> could probably be coded to handle dns resolutions and write the result
>> to the sysfs file.
>=20
> Yeah, I got the idea. I was hoping to avoid any additional userspace tool=
.
> IIUC the userspace tool would be more like an always-running program that=
=20
> periodically does the name resolution and updates the sysfs xprt addr
> file. It can be done using mount helpers which take the NFS server's host=
name
> and start the process to periodically resolve the hostname and write to s=
ysfs.
> Then on unmount the program has to be stopped.

Well there are variations on this idea. One variation might be
a single orchestrator daemon that would manage the sysfs files
using inotify, so it wouldn't have to track the operation of
mount/umount.

The sysfs files are meant to be only a conduit. User space is
meant to dynamically provide settings based on policy. The
opportunity here is to make this something that can be active
and rules-based instead of a static configuration (ie, more
like udev and less like /etc/fstab).

And note that any solution has to be container-aware. mount
certainly is, and that's another reason why the DNS query is
done at that time. An upcall would have to be done in the same
namespace(s) as the mount was done.

(I'm not advocating any particular approach, merely pointing
out some things that need consideration).


> With the dns resolution upcall on reconnect, all of this could be avoided=
.
> Infact as Olga said, if we extend your patch to treat hostnames specially=
 -=20
> do dns resolution upcall if the sysfs has the hostname instead of IP addr=
ess,
> that will serve my usecase well too.
>=20
> Thanks,
> Tomar

--
Chuck Lever