I'm wondering about an EL7 branch for zookeeper? It is wanted as a dependency in OpenStack for distributed lock management with tooz All I could find about this is one cryptic message from 2013 [1] I'd be willing to help, but there might be more issues around this than I realise... [1] https://lists.fedoraproject.org/pipermail/bigdata/2013-July/000047.html
I submitted a request[1] to create the EL7 branch. I don't know when/if it will happen, but I think there are other use cases beyond OpenStack. [1]: https://admin.fedoraproject.org/pkgdb/package/requests/1320
You meant epel7 branch vs. el7 branch. b/c el7 branch would mean fully supported through rhel ;-) FWIW I started down this road a while back, here were my last notes: https://bugzilla.redhat.com/show_bug.cgi?id=1177055#c10 Current missing dep-graph for zk rebuild on epel7: Error: No Package found for checkstyle Error: No Package found for ivy-local Error: No Package found for jdiff Error: No Package found for jtoaster Error: No Package found for netty
Yeah, I assumed EL7 was being used here as shorthand for EPEL7 (since that's all that is directly supported by Fedora for EL). If the originator intended to mean RHEL7, not EPEL7, then I don't think this issue is applicable to the Fedora community.
No, I mean EPEL
We need el7 branch for checkstyle https://admin.fedoraproject.org/pkgdb/package/checkstyle/ jdiff https://admin.fedoraproject.org/pkgdb/package/jdiff/ netty https://admin.fedoraproject.org/pkgdb/package/netty/ ivy-local doesn't exist in fedora
We can probably drop the dependency on checkstyle. That's just for zookeeper development. It's not needed downstream in Fedora. Same with jdiff, I think. Netty is essential, though. I'm surprised if it's not already in RHEL7 and not needed to be added to EPEL7.
Christ, What about ivy-local? Is that something we need to package?
(In reply to Arun S A G from comment #7) > What about ivy-local? Is that something we need to package? Unclear. I'm not that familiar with the ivy/ant builds. I'm more familiar with (x)mvn.
Looks like ivy-local can be worked around... but one must create a local ivy repository in the build. I'm still investigating how to do that (help wanted). checkstyle can be skipped (though it's useful for development) jdiff is actually used for javadocs, as a doclet... not sure if we want to package or skip that one... not sure what the EPEL guidelines are for javadocs. It does look like netty will need to be packaged for sure. We could probably patch to skip mockito tests. I'm not sure what jtoaster is for, yet, but that's another one not packaged.
While Christopher is obviously the expert here, I think there are several other of us interested who could lend a hand, but don't have exact experience with the package and it's not clear exactly how to start. While I think we should broadly sync via bugzilla, I think a more dynamic place to sync up would help. I've created https://etherpad.openstack.org/p/zookeeper-epel7 I try fleshing this out with as much as I can figure as a start
Definitely not an expert, especially when it comes to ant/ivy, so any help would be greatly appreciated. Thanks for setting up the etherpad shared doc. I've made some updates to it. Anything useful we flesh out there which is not already reflected here should be noted here for posterity. As BZs are filed for the dependencies, we can make them block this ticket, too.
I raised a redhat support ticket to let them package zookeeper and include it in RHEL7. I just got a response saying they have no plans to package zookeeper and include it in RHEL7. So it is upto us.
Hello folks, I've tried to port the f25 spec down to epel7 without success either... It's a never ending string of dependencies, which at some point starts to conflict too much with what is available on centos7. I stopped at the objectweb-asm which doesn't seems compatible with java-1.8. Anyway centos7 does have all the requirements to build a lightweight zookeeper.jar, e.g. not including javadoc, binding, clients or netty, just a bare minimal zookeeper.jar, which seems enough to work as a DLM for openstack. So I have been working on a zookeeper-lite-distgit that I'd like to use for nodepool/zuulv3 integration testing in the context of the software factory project: https://softwarefactory-project.io/r/6550 I don't know if it's acceptable to rewrite a package in such a way, but if this can be included in epel7, I'd be happy to submit this zookeeper-lite package (assuming the resulting zookeeper.jar works and the package is acceptable regarding to fedora guidelines).
(In reply to Tristan Cacqueray from comment #16) > Hello folks, I've tried to port the f25 spec down to epel7 without success > either... It's a never ending string of dependencies, which at some point > starts to conflict too much with what is available on centos7. I stopped at > the objectweb-asm which doesn't seems compatible with java-1.8. I've been slowly working through this dependency list, opening new branches for missing deps, and working around unneeded ones. There are some workarounds for the objectweb-asm issue. It takes time, but I am working on it. Any help getting these deps in, is always appreciated, of course. > > Anyway centos7 does have all the requirements to build a lightweight > zookeeper.jar, e.g. not including javadoc, binding, clients or netty, just a > bare minimal zookeeper.jar, which seems enough to work as a DLM for > openstack. > DLM? > So I have been working on a zookeeper-lite-distgit that I'd like to use for > nodepool/zuulv3 integration testing in the context of the software factory > project: > > https://softwarefactory-project.io/r/6550 > > I don't know if it's acceptable to rewrite a package in such a way, but if > this can be included in epel7, I'd be happy to submit this zookeeper-lite > package (assuming the resulting zookeeper.jar works and the package is > acceptable regarding to fedora guidelines). If you wish to use something like that, you should submit it as a separate package. I'm making progress on getting the full and proper zookeeper package built for EPEL7.
(In reply to Christopher Tubbs from comment #17) > (In reply to Tristan Cacqueray from comment #16) > > Hello folks, I've tried to port the f25 spec down to epel7 without success > > either... It's a never ending string of dependencies, which at some point > > starts to conflict too much with what is available on centos7. I stopped at > > the objectweb-asm which doesn't seems compatible with java-1.8. > > I've been slowly working through this dependency list, opening new branches > for missing deps, and working around unneeded ones. There are some > workarounds for the objectweb-asm issue. It takes time, but I am working on > it. Any help getting these deps in, is always appreciated, of course. > Hi Christopher, I had a hard time figuring out where epel7 branch were being worked on and what are the workarounds... Would you mind adding blocker for this ticket so that it's easier to follow? And is there a repository collecting the current specs and workaround for epel7? > > > > Anyway centos7 does have all the requirements to build a lightweight > > zookeeper.jar, e.g. not including javadoc, binding, clients or netty, just a > > bare minimal zookeeper.jar, which seems enough to work as a DLM for > > openstack. > > > > DLM? > It means Distributed Lock Manager, which seems like the use case for zookeeper in openstack. > > So I have been working on a zookeeper-lite-distgit that I'd like to use for > > nodepool/zuulv3 integration testing in the context of the software factory > > project: > > > > https://softwarefactory-project.io/r/6550 > > > > I don't know if it's acceptable to rewrite a package in such a way, but if > > this can be included in epel7, I'd be happy to submit this zookeeper-lite > > package (assuming the resulting zookeeper.jar works and the package is > > acceptable regarding to fedora guidelines). > > If you wish to use something like that, you should submit it as a separate > package. I'm making progress on getting the full and proper zookeeper > package built for EPEL7. Well I have little to no experience in java packaging, and this was just an attempt at getting the ball rolling... A proper zookeeper package would be better.
Tristan, Do you have the zookeeper-lite binary/src rpms somewhere in a repo?
> Do you have the zookeeper-lite binary/src rpms somewhere in a repo? it's in Software Factory repos: https://softwarefactory-project.io/r/gitweb?p=scl/zuul-distgit.git;a=tree;h=refs/heads/master;hb=refs/heads/master This one is using SCL python35
Thank you. I created a copr for zookeeper lite https://copr.fedorainfracloud.org/coprs/sagarun/zookeeper-lite/ and it has binary rpms for EPEL7
The zookeeper package has been retired.