RHEL dumps Btrfs and replaces it with Stratis

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

RHEL dumps Btrfs and replaces it with Stratis

Roman Bysh-5
Hi all,

Looks like Redhat will no longer use Btrfs in their next release and has replaced it with Stratis.
Stratis appears to be an XFS derivative designed by Redhat.

Can we see this as an option for openSUSE in the future?


Cheers!

Roman
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RHEL dumps Btrfs and replaces it with Stratis

Richard Brown
On 23 September 2017 at 21:52, Roman Bysh <[hidden email]> wrote:
> Hi all,
>
> Looks like Redhat will no longer use Btrfs in their next release and has
> replaced it with Stratis.
> Stratis appears to be an XFS derivative designed by Redhat.
>
> Can we see this as an option for openSUSE in the future?

My answer will be the same as normally

If someone contributes it to openSUSE, yes

If no one contributes it to openSUSE, no

I am not aware of anyone working on it for openSUSE at this time.

Cheers
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RHEL dumps Btrfs and replaces it with Stratis

Roman Bysh-5
On 23/09/17 04:47 PM, Richard Brown wrote:

> On 23 September 2017 at 21:52, Roman Bysh <[hidden email]> wrote:
> > Hi all,
> >
> > Looks like Redhat will no longer use Btrfs in their next release and has
> > replaced it with Stratis.
> > Stratis appears to be an XFS derivative designed by Redhat.
> >
> > Can we see this as an option for openSUSE in the future?
>
> My answer will be the same as normally
>
> If someone contributes it to openSUSE, yes
>
> If no one contributes it to openSUSE, no
>
> I am not aware of anyone working on it for openSUSE at this time.
>
> Cheers
>
Thanks Richard.

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RHEL dumps Btrfs and replaces it with Stratis

Neal Gompa
In reply to this post by Richard Brown
On Sat, Sep 23, 2017 at 4:47 PM, Richard Brown <[hidden email]> wrote:

> On 23 September 2017 at 21:52, Roman Bysh <[hidden email]> wrote:
>> Hi all,
>>
>> Looks like Redhat will no longer use Btrfs in their next release and has
>> replaced it with Stratis.
>> Stratis appears to be an XFS derivative designed by Redhat.
>>
>> Can we see this as an option for openSUSE in the future?
>
> My answer will be the same as normally
>
> If someone contributes it to openSUSE, yes
>
> If no one contributes it to openSUSE, no
>
> I am not aware of anyone working on it for openSUSE at this time.
>

For what it's worth, it's not even in *Fedora* yet because Stratis is
written in Rust, and the required Rust packaging work was delayed
until Fedora 28. The only blockers on the openSUSE side right now are
supporting the new rich dependencies without breaking the Tumbleweed
compose (aka, new product builder), which I think is supposed to be
deployed by now, and RPM supporting with/without rich operators, which
is in RPM 4.14, which should be making its way into Tumbleweed and
SLE/Leap 15 soonish.


--
真実はいつも一つ!/ Always, there's only one truth!
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RHEL dumps Btrfs and replaces it with Stratis

Dominique Leuenberger / DimStar
On Sat, 2017-09-23 at 19:22 -0400, Neal Gompa wrote:

> On Sat, Sep 23, 2017 at 4:47 PM, Richard Brown <[hidden email]
> g> wrote:
> > On 23 September 2017 at 21:52, Roman Bysh <[hidden email]>
> > wrote:
> > > Hi all,
> > >
> > > Looks like Redhat will no longer use Btrfs in their next release
> > > and has
> > > replaced it with Stratis.
> > > Stratis appears to be an XFS derivative designed by Redhat.
> > >
> > > Can we see this as an option for openSUSE in the future?
> >
> > My answer will be the same as normally
> >
> > If someone contributes it to openSUSE, yes
> >
> > If no one contributes it to openSUSE, no
> >
> > I am not aware of anyone working on it for openSUSE at this time.
> >
>
> […] The only blockers on the openSUSE side right now are
> supporting the new rich dependencies without breaking the Tumbleweed
> compose (aka, new product builder), which I think is supposed to be
> deployed by now, and RPM supporting with/without rich operators,
> which […]
Nope, we did still not migrate to the new product builder; but we are
getting closer and think we are missing about one more feature on the
OBS side of things to get this done (unless we keep on finding more
things)

Cheers,
Dominique

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RHEL dumps Btrfs and replaces it with Stratis

Aleksa Sarai
In reply to this post by Neal Gompa
> For what it's worth, it's not even in *Fedora* yet because Stratis is
> written in Rust, and the required Rust packaging work was delayed
> until Fedora 28. The only blockers on the openSUSE side right now are
> supporting the new rich dependencies without breaking the Tumbleweed
> compose (aka, new product builder), which I think is supposed to be
> deployed by now, and RPM supporting with/without rich operators, which
> is in RPM 4.14, which should be making its way into Tumbleweed and
> SLE/Leap 15 soonish.

Is there a doc somewhere about the current status of Rust packaging on
openSUSE? From memory, the Debian folks were having a lot of trouble
with it -- though I see that you're a member of the SIG-Rust for Fedora[1].

What was/is the plan to deal with the nightly compiler issue, not to
mention the more generic cargo issue?

[1]: https://fedoraproject.org/wiki/SIGs/Rust

--
Aleksa Sarai
Snr. Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RHEL dumps Btrfs and replaces it with Stratis

Neal Gompa
On Sun, Oct 1, 2017 at 8:46 PM, Aleksa Sarai <[hidden email]> wrote:

>> For what it's worth, it's not even in *Fedora* yet because Stratis is
>> written in Rust, and the required Rust packaging work was delayed
>> until Fedora 28. The only blockers on the openSUSE side right now are
>> supporting the new rich dependencies without breaking the Tumbleweed
>> compose (aka, new product builder), which I think is supposed to be
>> deployed by now, and RPM supporting with/without rich operators, which
>> is in RPM 4.14, which should be making its way into Tumbleweed and
>> SLE/Leap 15 soonish.
>
>
> Is there a doc somewhere about the current status of Rust packaging on
> openSUSE? From memory, the Debian folks were having a lot of trouble with it
> -- though I see that you're a member of the SIG-Rust for Fedora[1].
>
> What was/is the plan to deal with the nightly compiler issue, not to mention
> the more generic cargo issue?
>
> [1]: https://fedoraproject.org/wiki/SIGs/Rust
>

As far as I know, there isn't a page about this for openSUSE. Luke
Jones, who is the member of the SIG (the member list is a bit out of
date) that works on openSUSE packaging, has been busy with his GSoC
project and school things, so he has been away for some time.

I've been meaning to take a stab at either rebasing openSUSE's rpm to
4.14 or backporting the necessary richops to the current rpm, but
SUSE's rpm package is rather scary compared to Fedora or Mageia's, in
part because SUSE-specific configuration changes are mushed into the
upstream rpm package rather than being split out into a
rpm-config-SUSE package (like redhat-rpm-config in Fedora and
rpm-mageia-setup in Mageia). I believe Simon Lees (who is CC'd to this
email) was working on splitting things up to make it easier to do rpm
upgrades. I've also been trying to take a stab at making the rpm
packaging not suck as much, but it's tricky...

Contrary to the name of the SIG, Fedora, Mageia, and openSUSE are
equally involved in developing the packaging. Rémi Verschelde
represents Mageia. Luke Jones represents openSUSE. I'm involved in all
three (somehow! :P). Igor Gnatenko and Josh Stone represent Fedora and
RHEL/EPEL.

At least at the moment, I believe we're avoiding the nightly compiler
issue by just not building that stuff right now. As for the "generic
Cargo issue", I'm not sure what you mean?

--
真実はいつも一つ!/ Always, there's only one truth!
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RHEL dumps Btrfs and replaces it with Stratis

Aleksa Sarai
>> As for the "generic Cargo issue", I'm not sure what you mean?
>
> I'm also not sure what this is about.

Sorry, I was referring to two separate things by this:

1. A Rust binary can depend on many different versions of a crate. While
this isn't a problem with RPM, how are we going to maintain a mirror of
every version of every package in the crates repo inside OBS? Sounds
expensive.

2. Are we going to generate RPM specs from Cargo.toml? In which case,
are we going to run into the maintenance issues of doing this
(especially given (1))? Or will we do it on as-needed basis, and does
that mean we'll need to come up with a better way of handling the nodejs
handling problem?

--
Aleksa Sarai
Snr. Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: RHEL dumps Btrfs and replaces it with Stratis

Simon Lees-3
In reply to this post by Neal Gompa


On 02/10/17 23:55, Neal Gompa wrote:

> On Sun, Oct 1, 2017 at 8:46 PM, Aleksa Sarai <[hidden email]> wrote:
>>> For what it's worth, it's not even in *Fedora* yet because Stratis is
>>> written in Rust, and the required Rust packaging work was delayed
>>> until Fedora 28. The only blockers on the openSUSE side right now are
>>> supporting the new rich dependencies without breaking the Tumbleweed
>>> compose (aka, new product builder), which I think is supposed to be
>>> deployed by now, and RPM supporting with/without rich operators, which
>>> is in RPM 4.14, which should be making its way into Tumbleweed and
>>> SLE/Leap 15 soonish.
>>
>>
>> Is there a doc somewhere about the current status of Rust packaging on
>> openSUSE? From memory, the Debian folks were having a lot of trouble with it
>> -- though I see that you're a member of the SIG-Rust for Fedora[1].
>>
>> What was/is the plan to deal with the nightly compiler issue, not to mention
>> the more generic cargo issue?
>>
>> [1]: https://fedoraproject.org/wiki/SIGs/Rust
>>
>
> As far as I know, there isn't a page about this for openSUSE. Luke
> Jones, who is the member of the SIG (the member list is a bit out of
> date) that works on openSUSE packaging, has been busy with his GSoC
> project and school things, so he has been away for some time.
>
> I've been meaning to take a stab at either rebasing openSUSE's rpm to
> 4.14 or backporting the necessary richops to the current rpm, but
> SUSE's rpm package is rather scary compared to Fedora or Mageia's, in
> part because SUSE-specific configuration changes are mushed into the
> upstream rpm package rather than being split out into a
> rpm-config-SUSE package (like redhat-rpm-config in Fedora and
> rpm-mageia-setup in Mageia). I believe Simon Lees (who is CC'd to this
> email) was working on splitting things up to make it easier to do rpm
> upgrades. I've also been trying to take a stab at making the rpm
> packaging not suck as much, but it's tricky...
>
If this week doesn't end up crazy busy with unexpected things like last
week i'll probably get back to working on it next week. But it involves
quite some work so I don't think it will be a quick process.

--

Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                           Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B


signature.asc (499 bytes) Download Attachment