Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sys-fs/mdadm: add mdadm for default layout options for edge #146

Merged
merged 1 commit into from Dec 13, 2019

Conversation

@dongsupark
Copy link
Member

dongsupark commented Dec 13, 2019

To be able to make use of new features about default layout, we should move mdadm from portage-stable to coreos-overlay, update its version to 4.1, and apply patches on top of it.

This PR should be merged together with flatcar-linux/portage-stable#25.

To be able to make use of new features about default layout, we
should move mdadm from portage-stable to coreos-overlay, update its
version to 4.1, and apply patches on top of it.
@rata
rata approved these changes Dec 13, 2019
Copy link
Member

rata left a comment

LGTM, thanks a lot!

Please note that I have not tried to compile it and use it. But the patches look reasonable, but the patches look reasonable :)

@rata

This comment has been minimized.

Copy link
Member

rata commented Dec 13, 2019

Not sure what the version will be. I don't remember the gentoo convention (it's been ~10 years since my last use of gentoo), but shouldn't we mark it as a different version? For example, debian adds a -2 or -N to the package version.

Should we do something similar? Maybe it's there and I'm missing it? :)

@pothos

This comment has been minimized.

Copy link
Member

pothos commented Dec 13, 2019

I think it would be good to generate a /usr/lib/modprobe.d/raid0.conf file with options raid0 default_layout=2 in it. Then when the initramfs gets generated it should be copied there automatically as far as I understand. This way we don't need to add kernel command line arguments everywhere.

@dongsupark

This comment has been minimized.

Copy link
Member Author

dongsupark commented Dec 13, 2019

shouldn't we mark it as a different version?

We already did.
The original Gentoo upstream file was sys-fs/mdadm/mdadm-4.1.ebuild, while the Flatcar one is sys-fs/mdadm/mdadm-4.1-r1.ebuild, with a -r1 suffix. The next version would be 4.1-r2 , -r3, etc.

@dongsupark

This comment has been minimized.

Copy link
Member Author

dongsupark commented Dec 13, 2019

I think it would be good to generate a /usr/lib64/modprobe.d/raid0.conf file with options raid0 default_layout=2 in it.

That sounds like a good idea.
But this PR is about updating the mdadm tool, not exactly about the base layout or bootengine of Flatcar.
Will soon dig into the initramfs issue.

@pothos

This comment has been minimized.

Copy link
Member

pothos commented Dec 13, 2019

I thought that this package is a good place to set the module parameter.

@rata

This comment has been minimized.

Copy link
Member

rata commented Dec 13, 2019

shouldn't we mark it as a different version?

We already did.
The original Gentoo upstream file was sys-fs/mdadm/mdadm-4.1.ebuild, while the Flatcar one is sys-fs/mdadm/mdadm-4.1-r1.ebuild, with a -r1 suffix. The next version would be 4.1-r2 , -r3, etc.

Oh, right. But isn't gentoo using -r1 tags for gentoo changes/patches? I mean, isn't it possible that gentoo releases sys-fs/mdadm/mdadm-4.1.ebuild in a while and we won't have any easy way to distinguish between their release and ours? Should we consider something else, like -k1 (guessint that k < r for emerge and k stand for kinvolk, of course ;))

In debian backports you usually use the ~ separator too, for example, so it is clear it is a change but as a version is lower than the next stable version (for example 4.1-1~bpo8 will be upgraded in debian to 4.1-1).

Maybe we can use like: -r1-k1 to patch -r1 and just -k1 to patch a release without any revision yet?

@dongsupark

This comment has been minimized.

Copy link
Member Author

dongsupark commented Dec 13, 2019

I thought that this package is a good place to set the module parameter.

I am not sure.
Even without updating the mdadm with this PR, kernel module parameters for default layout can be updated.

@dongsupark

This comment has been minimized.

Copy link
Member Author

dongsupark commented Dec 13, 2019

Oh, right. But isn't gentoo using -r1 tags for gentoo changes/patches? I mean, isn't it possible that gentoo releases sys-fs/mdadm/mdadm-4.1.ebuild in a while and we won't have any easy way to distinguish between their release and ours? Should we consider something else, like -k1 (guessint that k < r for emerge and k stand for kinvolk, of course ;))

That is true.
If Gentoo updates it to -r1, then it can be the same as Flatcar package.
That issue has existed in every overlay, like chromiumos-overlay, upstream coreos-overlay and Flatcar's coreos-overlay. I am not sure there is a way to avoid it.
Anyway it has been not a big deal so far. In most cases, when syncing coreos-overlay with upstream Gentoo, the new version might be a completely higher one, which has nothing to do with a revision number. (e.g. 4.1-r1 to 4.2) We just have to rename it carefully before creating the new ebuild. Of course I admit that the whole process would not be straightforward.

In debian backports you usually use the ~ separator too, for example, so it is clear it is a change but as a version is lower than the next stable version (for example 4.1-1~bpo8 will be upgraded in debian to 4.1-1).
Maybe we can use like: -r1-k1 to patch -r1 and just -k1 to patch a release without any revision yet?

Ok, there must be reasons why Debian does that. I respect that.
Anyway I have been simply not enthusiastic enough to change the versioning mechanism in a "Kinvolk-specific way". There would be rather a lot more things out there that I would want to change in Flatcar Linux. (Build systems, CI, scripts, etc)
I think for now, as far as we are based on Gentoo, it would be painless to be close to Gentoo's way as much as possible.

@rata

This comment has been minimized.

Copy link
Member

rata commented Dec 13, 2019

Oh, right. But isn't gentoo using -r1 tags for gentoo changes/patches? I mean, isn't it possible that gentoo releases sys-fs/mdadm/mdadm-4.1.ebuild in a while and we won't have any easy way to distinguish between their release and ours? Should we consider something else, like -k1 (guessint that k < r for emerge and k stand for kinvolk, of course ;))

That is true.
If Gentoo updates it to -r1, then it can be the same as Flatcar package.
That issue has existed in every overlay, like chromiumos-overlay, upstream coreos-overlay and Flatcar's coreos-overlay. I am not sure there is a way to avoid it.
Anyway it has been not a big deal so far. In most cases, when syncing coreos-overlay with upstream Gentoo, the new version might be a completely higher one, which has nothing to do with a revision number. (e.g. 4.1-r1 to 4.2) We just have to rename it carefully before creating the new ebuild. Of course I admit that the whole process would not be straightforward.

Oh, okay. If we are already living with this potential issue, no problem :-)

I hope Gentoo will get an -r1 to add these patches soon, but let's see :-D

In debian backports you usually use the ~ separator too, for example, so it is clear it is a change but as a version is lower than the next stable version (for example 4.1-1~bpo8 will be upgraded in debian to 4.1-1).
Maybe we can use like: -r1-k1 to patch -r1 and just -k1 to patch a release without any revision yet?

Ok, there must be reasons why Debian does that. I respect that.
Anyway I have been simply not enthusiastic enough to change the versioning mechanism in a "Kinvolk-specific way". There would be rather a lot more things out there that I would want to change in Flatcar Linux. (Build systems, CI, scripts, etc)
I think for now, as far as we are based on Gentoo, it would be painless to be close to Gentoo's way as much as possible.

I agree to be as close to upstream as possible.

I was just mentioning this as ideas to avoid the problem of not able to distinguish between our's and upstream. But as we don't mind about it (chromiumos-overlay, upstream coreos-overlay and Flatcar's coreos-overlay already have that problem), just sorry for the noise :)

@rata
rata approved these changes Dec 13, 2019
@dongsupark

This comment has been minimized.

Copy link
Member Author

dongsupark commented Dec 13, 2019

Thanks!

@dongsupark dongsupark merged commit 87701d2 into flatcar-master-edge Dec 13, 2019
@dongsupark dongsupark deleted the dongsu/add-mdadm branch Dec 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.