Everything on my list for 1.1 is done now.
Thanks to Andrew, Geoffrey, Richard and Aron for their recent commits.
Unless someone identifies further issues that we have to address for 1.1,
I think that we are ready to release.
Unless someone else volunteers to be the RM, I will start the process
https://issues.apache.org/jira/browse/OMID-231 is the ticket.
On Mon, Aug 29, 2022 at 10:28 AM Istvan Toth wrote:
> I had a go at this, and it seems to be much easier than I thought.
>
> I'm going to open a ticket and PR for this soon.
>
> Istvan
>
> On Fri, Aug 26, 2022 at 5:15 PM Andrew
I had a go at this, and it seems to be much easier than I thought.
I'm going to open a ticket and PR for this soon.
Istvan
On Fri, Aug 26, 2022 at 5:15 PM Andrew Purtell
wrote:
> I agree with Geoffrey that OMID should align with Phoenix on default
> dependency versions but based on this you
I agree with Geoffrey that OMID should align with Phoenix on default dependency
versions but based on this you don’t have an immediate integration problem. I
don’t believe the Configuration API has changed in a long time.
The security posture of Hadoop 2 in general is a problem, though. I know
The only non-hbase Hadoop APIs referred in Omid are
org.apache.hadoop.conf.Configuration, and a few classes from of
org.apache.hadoop.security
(the latter is not referenced directly from the coprocessors) .
Also, the coprocessor JARs don't have any Hbase or Hadoop code shaded in.
On Fri, Aug
Is any OMID coprocessor code using Hadoop APIs?
> On Aug 25, 2022, at 9:41 AM, Istvan Toth wrote:
>
> We dependencyManage every Hadoop component in Phoenix, so going to Hadoop3
> in Omid is not strictly necessary.
> Hadoop is also added to the TSO libraries in the assembly, but AFAIK
>
We dependencyManage every Hadoop component in Phoenix, so going to Hadoop3
in Omid is not strictly necessary.
Hadoop is also added to the TSO libraries in the assembly, but AFAIK
Hadoop2 and Hadoop3 are wire compatible
(and I'm not sure if Omid even calls Hadoop endpoints directly), so that is
not
Thanks for volunteering to be RM for the next Omid release.
I agree we should have a release soon (I think we'll want Phoenix 5.2 to
use the new Omid). In addition to OMID-226, I suggest we also upgrade
Omid's internal Hadoop version to align with whatever default Hadoop we
choose for Phoenix
Hi!
Most of the planned OMID changes for Phoenix 5.2 have landed.
The only outstanding ticket that I'm aware of is OMID-226 which I also
expect to land soon.
Unless someone has more changes targeted for the next release, I propose
that we release the next Omid version soon after OMID-226.
I
Java code wise the current shim system is fine.
The packaging up to 1.0.2 is nightmarish, with having to manually exclude
hbase-1 artifacts if you use HBase 2.
However, that is mostly fixed by OMID-188.
I will check if Omid works with the current HBase 3 snapshot without
modifications, and
+1
If we're dropping Phoenix 4.x imminently, that means dropping HBase 1.x
and we should follow suit in Omid.
A "beta" HBase 3.0 is probably not too, too far away. I would consider
how "nice" the current shim logic is in Omid (i.e. is it actually
helpful? nice to work with? effective?), and
Hi!
When Geoffrey proposed releasing Phoenix 5.2.0, I asked for time to release
a new Omid version first, as there are a lot of unreleased fixes in master.
One of those fixes removes the need to add a lot of explicit excludes for
the Omid HBase-1 artifacts when depending on Omid for HBase 2.
12 matches
Mail list logo
