12:12 p.m.
https://fedoraproject.org/wiki/Changes/Stratis_2.2.0
Stratis 2.2.0 now places Stratis filesystem symlinks in /dev/stratis,
rather than /stratis. Stratis creates and maintains the symlinks by
means of udev rules, rather than directly via stratisd as previously.
The /stratis directory is neither created nor used by stratisd 2.2.0.
== Owner ==
* Name: [[User:dkeefe|Dennis Keefe]], [[User:mulhern|Anne Mulhern]],
[[User:jbaublitz|John Baublitz]]
* Email: dkeefe(a)redhat.com, amulhern(a)redhat.com, jbaublitz(a)redhat.com
== Detailed Description ==
=== Stratisd 2.2.0 ===
This release creates and maintains Stratis filesystem symlinks in
/dev/stratis by means of udev rules. It includes a small Rust script,
stratis_uuids_to_names which is invoked by the Stratis udev rule which
sets the Stratis filesystem symlinks.
In the case where stratisd is updated in place, some filesystem
symlinks may remain in /stratis. This release includes a shell script,
stratis_migrate_symlinks.sh which may be used to clean up the /stratis
directory and ensure that the correct symlinks exist in /dev/stratis.
The script removes the /stratis directory once it has completed
without error. The shell script relies on a small Rust script,
stratis_dbusquery_version which is included with this version of
stratisd.
This release also extends the D-Bus interface in a few ways:
It sends org.freedesktop.DBus.ObjectManager.InterfacesAddedand
org.freedesktop.DBus.ObjectManager.InterfacesRemoved signals on the
D-Bus whenever a D-Bus object is added to or removed from the D-Bus
interface.
It adds a new D-Bus property, PhysicalPath, for the
org.storage.stratis2.blockdev.r2 interface. This property is
principally useful for encrypted Stratis block devices; it identifies
the block device on which the Stratis LUKS2 metadata resides.
It adds a new key, LockedPools, to the
org.storage.stratis2.FetchProperties.r2 interface for objects that
implement the org.storage.stratis2.Manager interface. This key returns
a D-Bus object that maps the UUIDs of locked pools to their
corresponding key descriptions.
Please consult the D-Bus API Reference for the precise D-Bus specification.
This release allows the user to specify their preferred log level more
directly and succinctly with the --log-level CLI option.
This release includes management of terminal settings for interactive
encryption-key entry.
This release includes some unsupported scripts which may be built from
the source distribution but are not intended to be released as part of
any package. These scripts depend on the extras feature in Cargo.toml.
This release also includes a number of minor bug fixes.
== Detailed Description ==
=== Stratis-cli 2.2.0 ===
This release requires stratisd 2.2.0. Some commands have been updated
to make use of the new stratisd D-Bus interfaces.
This release drops management of terminal settings for interactive
encryption-key entry; management of terminal settings is now handled
in stratisd 2.2.0.
== Feedback ==
== Benefits to Fedora ==
Users of Fedora will now benefit from Stratis 2.2.0 by:
* Devices being located in an existing and known top level directory.
* Applications that are restricted from using non-default top level
directories can now use Stratis symlinks
* Better integration with udev
== Scope ==
* Proposal owners:
** Update existing stratis-cli package to specify new release
** Update existing stratisd package to specify new release
* Other developers: N/A
* Release engineering: Self Contained
* Policies guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
Stratis symlinks have moved. Existing symlinks in /stratis/<pool
name>/<filesystem name> will need to be migrated to
/dev/stratis/<pool name>/<filesystem name>. This is accomplished by
running the migration script (stratis_migrate_symlinks.sh) that comes
with the
2.2.0 release of Stratis or rebooting the system. Any configurations
that make use of the old symlink locations will
need to be updated to use the new location. So, if there has been
manual changes to systemd unit files or /etc/fstab
for automatically mounting Stratis filesystems, then these will need
to be updated to reflect the change.
== How To Test ==
* Testing new filesystem paths can be done using the CLI provided by
stratis-cli package or D-Bus API provided by stratisd
package.
* Create a pool and filesystem using stratis command
stratis pool create p1 /dev/sdb
stratis fs create p1 fs1
* Check that the new path is in /dev/stratis/<pool name>/<filesystem name>
ls /dev/stratis/<pool name>
stratis fs list
== User Experience ==
Users with existing Stratis filesystems will notice a change in the
filesystem path from /stratis/<pool name>/<filesystem name> to
/dev/stratis/<pool name>/<filesystem name>. Appropriate action will
need to be taken to update system configurations that
make use of the older filesystem paths.
== Dependencies ==
We are not aware of any new dependencies
== Contingency Plan ==
* Contingency mechanism:
* Contingency deadline: N/A
* Blocks release? No
* Blocks product? No
== Documentation ==
Please see https://stratis-storage.github.io/ for design documents and
API reference.
Development and issue tracking is at https://github.com/stratis-storage/
== Release Notes ==
Includes recent version of Stratis
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
7:05 a.m.
Ben Cotton <bcotton(a)redhat.com> writes:
== Contingency Plan ==
* Contingency mechanism:
* Contingency deadline: N/A
* Blocks release? No
* Blocks product? No
Shouldn't there be a contingency plan? We should have a plan B for the
case that the update would introduce serious regressions.
Cheers,
Dan
1:13 p.m.
On Wed, Nov 4, 2020, at 1:12 PM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Stratis_2.2.0
Stratis 2.2.0 now places Stratis filesystem symlinks in /dev/stratis,
rather than /stratis. Stratis creates and maintains the symlinks by
means of udev rules, rather than directly via stratisd as previously.
The /stratis directory is neither created nor used by stratisd 2.2.0.
Thank you! The top level directory had previously made stratis a non-starter for me.
V/r,
James Cassell
5:10 a.m.
On Wed, Nov 04, 2020 at 01:12:44PM -0500, Ben Cotton wrote:
* Name: [[User:dkeefe|Dennis Keefe]], [[User:mulhern|Anne Mulhern]],
[[User:jbaublitz|John Baublitz]]
* Email: dkeefe(a)redhat.com, amulhern(a)redhat.com, jbaublitz(a)redhat.com
== Upgrade/compatibility impact ==
Stratis symlinks have moved. Existing symlinks in /stratis/<pool
name>/<filesystem name> will need to be migrated to
/dev/stratis/<pool name>/<filesystem name>. This is accomplished by
running the migration script (stratis_migrate_symlinks.sh) that comes
with the
2.2.0 release of Stratis or rebooting the system. Any configurations
that make use of the old symlink locations will
need to be updated to use the new location. So, if there has been
manual changes to systemd unit files or /etc/fstab
for automatically mounting Stratis filesystems, then these will need
to be updated to reflect the change.
How large is the risk that systems that were using the old /stratis/foo
paths will fail to mount the filesystems, and possibly fail to boot, after
the upgrade? (Sorry, I have never used stratis, so I don't know how often
those migration steps would be necessary.)
Shouldn't /startis symlink be created for compatibility on *upgrades* ?
Zbyszek
5:28 p.m.
On Sun, Nov 15, 2020 at 4:12 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
On Wed, Nov 04, 2020 at 01:12:44PM -0500, Ben Cotton wrote:
> * Name: [[User:dkeefe|Dennis Keefe]], [[User:mulhern|Anne Mulhern]],
> [[User:jbaublitz|John Baublitz]]
> * Email: dkeefe(a)redhat.com, amulhern(a)redhat.com, jbaublitz(a)redhat.com
> == Upgrade/compatibility impact ==
>
> Stratis symlinks have moved. Existing symlinks in /stratis/<pool
> name>/<filesystem name> will need to be migrated to
> /dev/stratis/<pool name>/<filesystem name>. This is accomplished by
> running the migration script (stratis_migrate_symlinks.sh) that comes
> with the
> 2.2.0 release of Stratis or rebooting the system. Any configurations
> that make use of the old symlink locations will
> need to be updated to use the new location. So, if there has been
> manual changes to systemd unit files or /etc/fstab
> for automatically mounting Stratis filesystems, then these will need
> to be updated to reflect the change.
How large is the risk that systems that were using the old /stratis/foo
paths will fail to mount the filesystems, and possibly fail to boot, after
the upgrade? (Sorry, I have never used stratis, so I don't know how often
those migration steps would be necessary.)
Shouldn't /startis symlink be created for compatibility on *upgrades* ?
It's not supported for booting yet. But if there's an fstab entry
using a path from /stratis, and also doesn't include the nofail or
noauto mount options, boot can fail waiting indefinitely on a file
system that won't ever appear
--
Chris Murphy
2:38 a.m.
On Sun, Nov 15, 2020 at 04:28:36PM -0700, Chris Murphy wrote:
On Sun, Nov 15, 2020 at 4:12 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
>
> On Wed, Nov 04, 2020 at 01:12:44PM -0500, Ben Cotton wrote:
> > * Name: [[User:dkeefe|Dennis Keefe]], [[User:mulhern|Anne Mulhern]],
> > [[User:jbaublitz|John Baublitz]]
> > * Email: dkeefe(a)redhat.com, amulhern(a)redhat.com, jbaublitz(a)redhat.com
>
> > == Upgrade/compatibility impact ==
> >
> > Stratis symlinks have moved. Existing symlinks in /stratis/<pool
> > name>/<filesystem name> will need to be migrated to
> > /dev/stratis/<pool name>/<filesystem name>. This is accomplished
by
> > running the migration script (stratis_migrate_symlinks.sh) that comes
> > with the
> > 2.2.0 release of Stratis or rebooting the system. Any configurations
> > that make use of the old symlink locations will
> > need to be updated to use the new location. So, if there has been
> > manual changes to systemd unit files or /etc/fstab
> > for automatically mounting Stratis filesystems, then these will need
> > to be updated to reflect the change.
>
> How large is the risk that systems that were using the old /stratis/foo
> paths will fail to mount the filesystems, and possibly fail to boot, after
> the upgrade? (Sorry, I have never used stratis, so I don't know how often
> those migration steps would be necessary.)
>
> Shouldn't /startis symlink be created for compatibility on *upgrades* ?
It's not supported for booting yet. But if there's an fstab entry
using a path from /stratis, and also doesn't include the nofail or
noauto mount options, boot can fail waiting indefinitely on a file
system that won't ever appear
Right, but the question is: how common is that? Do we even have any general
idea how many people are using stratis?
Zbyszek
6:42 p.m.
On Mon, Nov 16, 2020 at 1:39 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
On Sun, Nov 15, 2020 at 04:28:36PM -0700, Chris Murphy wrote:
> On Sun, Nov 15, 2020 at 4:12 AM Zbigniew Jędrzejewski-Szmek
> <zbyszek(a)in.waw.pl> wrote:
> >
> > On Wed, Nov 04, 2020 at 01:12:44PM -0500, Ben Cotton wrote:
> > > * Name: [[User:dkeefe|Dennis Keefe]], [[User:mulhern|Anne Mulhern]],
> > > [[User:jbaublitz|John Baublitz]]
> > > * Email: dkeefe(a)redhat.com, amulhern(a)redhat.com, jbaublitz(a)redhat.com
> >
> > > == Upgrade/compatibility impact ==
> > >
> > > Stratis symlinks have moved. Existing symlinks in /stratis/<pool
> > > name>/<filesystem name> will need to be migrated to
> > > /dev/stratis/<pool name>/<filesystem name>. This is
accomplished by
> > > running the migration script (stratis_migrate_symlinks.sh) that comes
> > > with the
> > > 2.2.0 release of Stratis or rebooting the system. Any configurations
> > > that make use of the old symlink locations will
> > > need to be updated to use the new location. So, if there has been
> > > manual changes to systemd unit files or /etc/fstab
> > > for automatically mounting Stratis filesystems, then these will need
> > > to be updated to reflect the change.
> >
> > How large is the risk that systems that were using the old /stratis/foo
> > paths will fail to mount the filesystems, and possibly fail to boot, after
> > the upgrade? (Sorry, I have never used stratis, so I don't know how often
> > those migration steps would be necessary.)
> >
> > Shouldn't /startis symlink be created for compatibility on *upgrades* ?
>
> It's not supported for booting yet. But if there's an fstab entry
> using a path from /stratis, and also doesn't include the nofail or
> noauto mount options, boot can fail waiting indefinitely on a file
> system that won't ever appear
Right, but the question is: how common is that? Do we even have any general
idea how many people are using stratis?
No idea. But I think the feature and its release notes can adequately
inform users of the possibility of boot failure and whatever
workaround is needed.
--
Chris Murphy
108
days inactive
121
days old
7 comments
6 participants
participants (6)
-
Ben Cotton -
Chris Murphy -
Dan Čermák -
Dennis Keefe -
James Cassell -
Zbigniew Jędrzejewski-Szmek