Bug 1280159 - EPEL7 branch for zookeeper
EPEL7 branch for zookeeper
Status: NEW
Product: Fedora EPEL
Classification: Fedora
Component: zookeeper (Show other bugs)
epel7
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Christopher Tubbs
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-10 23:10 EST by Ian Wienand
Modified: 2018-01-29 16:15 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ian Wienand 2015-11-10 23:10:47 EST
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
Comment 1 Christopher Tubbs 2015-11-12 15:09:20 EST
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
Comment 2 Timothy St. Clair 2015-11-12 15:16:03 EST
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
Comment 3 Christopher Tubbs 2015-11-12 17:55:36 EST
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.
Comment 4 Ian Wienand 2015-11-12 17:59:21 EST
No, I mean EPEL
Comment 5 Arun S A G 2015-11-12 18:16:21 EST
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
Comment 6 Christopher Tubbs 2015-11-12 18:25:35 EST
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.
Comment 7 Arun S A G 2015-11-13 02:11:05 EST
Christ,

What about ivy-local? Is that something we need to package?
Comment 8 Christopher Tubbs 2015-11-13 10:59:35 EST
(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.
Comment 10 Christopher Tubbs 2015-11-16 11:36:52 EST
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.
Comment 13 Ian Wienand 2015-12-04 00:09:43 EST
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
Comment 14 Christopher Tubbs 2015-12-04 13:53:06 EST
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.
Comment 15 Arun S A G 2016-01-19 14:45:32 EST
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.
Comment 16 Tristan Cacqueray 2017-02-20 00:22:22 EST
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).
Comment 17 Christopher Tubbs 2017-02-22 20:52:32 EST
(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.
Comment 18 Tristan Cacqueray 2017-02-22 22:18:27 EST
(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.
Comment 19 Arun S A G 2017-10-09 18:38:37 EDT
Tristan,

Do you have the zookeeper-lite binary/src rpms somewhere in a repo?

Note You need to log in before you can comment on or make changes to this bug.