-
Notifications
You must be signed in to change notification settings - Fork 2
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
RHEL 8 support #98
RHEL 8 support #98
Conversation
There are no metapackages in RHEL. We can create metapackages simliar to *.deb, but should we do it? It would not be RHEL-way. I suggest to leave it for separate PR. What do you think @ryannowarm? |
Agreed. Leave it out for now. Perhaps in a future PR we could consider Yum Groups? |
Just a note, this is a monster PR(90 commits). In the future, smaller PRs earlier might be better. |
Yes, I'm sorry for that :( It was hard to split that in time as the concept was changing couple of time while implementing this. Easiest way to go through this PR would be go file by file. There are following main groups of change (I think it would be easiest to go from top to bottom of this list):
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, I like the way the code is written. A couple of overall suggestions:
- Move much of the copy-n-pasted stuff into a common directory that can be used by both deb and rpm builds. This is something that we could do in a follow on PR.
- Take the dozens of "stream-of-consciousness-style" commits and squash them into fewer logical commits with descriptive commit messages. I think this is pretty important so that future code readers can make sense of things.
@kunal11191 there are build failures shown in checks section below, are those related to RHEL? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kunal11191 there are build failures shown in checks section below, are those related to RHEL?
@kbgl right now PR checks are not working on RHEL but on older builds bionic, focal, buster (arm64, armhf, amd64).
Above mentioned builds on dev are failing with below given error message
`Generating source package of 'maestro'
INFO: Source preparation!
Cloning into '/pelion-build/build/downloads/maestro/maestro'...
Fetching origin
Note: checking out '20caa5d032424a11146b7923eaaed74e80de96da'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b
HEAD is now at 20caa5d Add aarch64
INFO: Generating Debian source packages!
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying greaselib-autoreconf.diff
dpkg-source: info: applying gperftools-enable-unwind.diff
dpkg-source: info: applying eventfd.diff
dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B .pc/eventfd.diff/ --reject-file=- < /pelion-build/build/tmp-build/maestro/maestro-0.0.1/debian/patches/eventfd.diff subprocess returned exit status 1
patching file processes/wakeupfd.go
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored
dpkg-source: info: the patch has fuzz which is not allowed, or is malformed
dpkg-source: info: if patch 'eventfd.diff' is correctly applied by quilt, use 'quilt refresh' to update it
script returned exit code 2`
|
||
3. To install use `yum` command, for example if all packages are in current directory run: | ||
```bash | ||
sudo yum install *.rpm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we use -y in this command?
sudo yum -y install *.rpm
also i think we are missing uninstall steps like https://github.com/PelionIoT/distro-pelion-edge/blob/0916ff9c31221884f8668a9c56148a767d271145/README.md#removing-packages
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, we can use -y
. Now i'm working on unification of README.md and README.rhel.md, this file will be removed in next PR.
Looks like problem in CI. The change with hash |
since redhat-83-support is supposed to be merged to dev it will take latest version of dev add your code to it and then trigger builds and tests. |
Thanks for the explanation. |
@kbgl , we need CI to pass before merging this. I'm trying to retrigger the CI without much luck. I've opened a bug for the SQA team on this: https://go.arm.com/X5mPLLW FYI: @mohitsingalarm and @kunal11191 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving this am able to build required files for both rhel and centos on arm64 and amd64; also able to install and run smoke suite
For usage please look into README.rhel.md. I'm still extending README.rhel.md, we can later join the content into README.md. For a long term we can drop pelion-build-all.sh and docker-run.sh and use build-all.sh and docker-run-env.sh instead.
Currently supported:
General idea was to separate environment setup from build scripts, and reuse docker function to build single package, all package or run shell for selected environment.
According to RHEL policy all services are disabled after installation so required services has to be enabled. Dependent services are started automatically, eg. enabling devicedb will start edge-core, wait-for-pelion-identity, maestro.
@kunal11191 please run tests, at the moment I run simple tests, but Kubelet is not well tested - service starts and log output looks similar to Debian's log.
@ryannowarm blocking wait-for-pelion-identity.service functionality is implemented in d893b52, 0ba03a5 and 63c9296. In short: wait-for-pelion-identity.service type is 'oneshot', and the script called there does not exit until we generate identity - which blocks startup of other pelion services. Seems to boot up faster than 'restart' approach.
It is not yet ready for merge still needs:
Environment for Ubuntu Focal was also created, I will update it and push after closing this PR. Similarly we can port all debian-like distros to new scripts
Please let me know if you have any problems with the scripts.