Is anyone using OMID or Tephra in production?

[Andrew Purtell <ap...@apache.org>]

At my employer we maintain a fork of Phoenix that we try to keep as close
to open source as possible given our internal requirements. One issue we
are facing in recent months is a tightening corporate policy on the
presence of known software vulnerabilities in our dependencies. Of course,
this means CVEs, but Sonatype also sells their own knowledge base, and
there are other inputs. The Phoenix project (and all Apache projects) can
opt in to a similar stream of software vulnerability notifications by
enabling GitHub's dependabot on your respective repositories mirrored there.

Transactional table support in itself is not at issue, but the Tephra and
OMID(2) transaction engines are problematic. Tephra depends on a specific
version of libthrift that has a high scoring CVE, and Twill, which is the
Apache Attic and has a lot of quite old dependencies itself. Tephra in
particular seems quite problematic and I think the community has reached
the same conclusion in the form of PHOENIX-6627, and, for what it's worth,
if you need someone to see that work through to the end I would like to
volunteer for that. I am less certain about the state of OMID. Its
dependencies are getting out of date but they could be managed up. HBase 1
support should be completely dropped, though, because it is officially EOL
and its dependencies will never be updated again.

Beyond that, let me note that both Tephra and OMID were contributed by
entities that have departed from the community some time ago. They were
both failed incubations that were transferred to Phoenix. It was a good
option at the time. The hope was that Phoenix could get up to speed on the
internals of these components and develop capacity for maintaining them in
its community. My take is that has not happened, though. Is that a fair
assessment? Is anyone running either Tephra or OMID in production? Is
anyone running them in production at scale or under high load? Does the
community feel capable and confident in dealing with some deep technical
internal problem in either engine that a user might encounter down the
road? If you are a Phoenix user running either Tephra or OMID in
production, even if you don't normally participate in the community or its
discussions, would you be willing to write in some testimonial? Any and all
data points would be appreciated.

-- 
Best regards,
Andrew

Re: Is anyone using OMID or Tephra in production?

[Istvan Toth <st...@apache.org>]

Hi!

I'm unfortunately not the big hiding transactional user that we're looking
for, but I'd like to add the following:

   - Omid is part of my employer's HBase / Phoenix offerings. We're
   supporting it, and have no plans to drop it.
   - We have limited visibility into its actual usage, I personally know
   that at least one significant customer is either piloting or using it in
   production.
   - I'm preparing for the 1.1.0 release, and have already removed HBase 1
   support in OMID-222, and the log4j2 migration in OMID-224 is waiting for a
   final review.
   - I plan to do an OWASP scan before release, but if you have any other
   concerns about the dependencies, then let's discuss them in a ticket or
   another thread.
   - So far our work on Omid has been mostly maintenance with integration
   type bug fixes, but we have the developers who can dig in and fix any core
   issues that crop up.

As for the Tephra removal, thanks for the offer to see it through. I hazard
that Zsolt won't have a problem with you taking over the patch. I'll try to
get hold of him to confirm it on the ticket.

I also second the request, if you are using Phoenix transactions, please do
speak up!

regards
Istvan

On Tue, Aug 9, 2022 at 8:49 PM Andrew Purtell <ap...@apache.org> wrote:

> At my employer we maintain a fork of Phoenix that we try to keep as close
> to open source as possible given our internal requirements. One issue we
> are facing in recent months is a tightening corporate policy on the
> presence of known software vulnerabilities in our dependencies. Of course,
> this means CVEs, but Sonatype also sells their own knowledge base, and
> there are other inputs. The Phoenix project (and all Apache projects) can
> opt in to a similar stream of software vulnerability notifications by
> enabling GitHub's dependabot on your respective repositories mirrored there.
>
> Transactional table support in itself is not at issue, but the Tephra and
> OMID(2) transaction engines are problematic. Tephra depends on a specific
> version of libthrift that has a high scoring CVE, and Twill, which is the
> Apache Attic and has a lot of quite old dependencies itself. Tephra in
> particular seems quite problematic and I think the community has reached
> the same conclusion in the form of PHOENIX-6627, and, for what it's worth,
> if you need someone to see that work through to the end I would like to
> volunteer for that. I am less certain about the state of OMID. Its
> dependencies are getting out of date but they could be managed up. HBase 1
> support should be completely dropped, though, because it is officially EOL
> and its dependencies will never be updated again.
>
> Beyond that, let me note that both Tephra and OMID were contributed by
> entities that have departed from the community some time ago. They were
> both failed incubations that were transferred to Phoenix. It was a good
> option at the time. The hope was that Phoenix could get up to speed on the
> internals of these components and develop capacity for maintaining them in
> its community. My take is that has not happened, though. Is that a fair
> assessment? Is anyone running either Tephra or OMID in production? Is
> anyone running them in production at scale or under high load? Does the
> community feel capable and confident in dealing with some deep technical
> internal problem in either engine that a user might encounter down the
> road? If you are a Phoenix user running either Tephra or OMID in
> production, even if you don't normally participate in the community or its
> discussions, would you be willing to write in some testimonial? Any and all
> data points would be appreciated.
>
> --
> Best regards,
> Andrew
>

Re: Is anyone using OMID or Tephra in production?

[Istvan Toth <st...@apache.org>]

Hi!

I'm unfortunately not the big hiding transactional user that we're looking
for, but I'd like to add the following:

   - Omid is part of my employer's HBase / Phoenix offerings. We're
   supporting it, and have no plans to drop it.
   - We have limited visibility into its actual usage, I personally know
   that at least one significant customer is either piloting or using it in
   production.
   - I'm preparing for the 1.1.0 release, and have already removed HBase 1
   support in OMID-222, and the log4j2 migration in OMID-224 is waiting for a
   final review.
   - I plan to do an OWASP scan before release, but if you have any other
   concerns about the dependencies, then let's discuss them in a ticket or
   another thread.
   - So far our work on Omid has been mostly maintenance with integration
   type bug fixes, but we have the developers who can dig in and fix any core
   issues that crop up.

As for the Tephra removal, thanks for the offer to see it through. I hazard
that Zsolt won't have a problem with you taking over the patch. I'll try to
get hold of him to confirm it on the ticket.

I also second the request, if you are using Phoenix transactions, please do
speak up!

regards
Istvan

On Tue, Aug 9, 2022 at 8:49 PM Andrew Purtell <ap...@apache.org> wrote:

> At my employer we maintain a fork of Phoenix that we try to keep as close
> to open source as possible given our internal requirements. One issue we
> are facing in recent months is a tightening corporate policy on the
> presence of known software vulnerabilities in our dependencies. Of course,
> this means CVEs, but Sonatype also sells their own knowledge base, and
> there are other inputs. The Phoenix project (and all Apache projects) can
> opt in to a similar stream of software vulnerability notifications by
> enabling GitHub's dependabot on your respective repositories mirrored there.
>
> Transactional table support in itself is not at issue, but the Tephra and
> OMID(2) transaction engines are problematic. Tephra depends on a specific
> version of libthrift that has a high scoring CVE, and Twill, which is the
> Apache Attic and has a lot of quite old dependencies itself. Tephra in
> particular seems quite problematic and I think the community has reached
> the same conclusion in the form of PHOENIX-6627, and, for what it's worth,
> if you need someone to see that work through to the end I would like to
> volunteer for that. I am less certain about the state of OMID. Its
> dependencies are getting out of date but they could be managed up. HBase 1
> support should be completely dropped, though, because it is officially EOL
> and its dependencies will never be updated again.
>
> Beyond that, let me note that both Tephra and OMID were contributed by
> entities that have departed from the community some time ago. They were
> both failed incubations that were transferred to Phoenix. It was a good
> option at the time. The hope was that Phoenix could get up to speed on the
> internals of these components and develop capacity for maintaining them in
> its community. My take is that has not happened, though. Is that a fair
> assessment? Is anyone running either Tephra or OMID in production? Is
> anyone running them in production at scale or under high load? Does the
> community feel capable and confident in dealing with some deep technical
> internal problem in either engine that a user might encounter down the
> road? If you are a Phoenix user running either Tephra or OMID in
> production, even if you don't normally participate in the community or its
> discussions, would you be willing to write in some testimonial? Any and all
> data points would be appreciated.
>
> --
> Best regards,
> Andrew
>