Community Meeting - Jan 26, 2021

We’ll be discussing the new forks and the project as a whole during the community meeting tomorrow (Jan 26). We’d be glad to have you!

1 Like

@searchymcsearchface How can I write you a PM?

If you click on my name it should give you the option to “Message.”

No, sadly not. I can not even PM the moderators (maybe my trust level is too low?). Can you PM me so that we have an open thread?

Relevant slides from the community meeting:

2 Likes

I couldn’t make it yesterday. Did you record the Meetup too? We are highly interested in the ongoing Development.
Thanks

2 Likes

Do you plan to fork also logstash and beats?

And the docs? Seems they are also ASLv2 licensed.

1 Like

Currently, we don’t record these sessions for a non-technical reason (a story for another time) but trying to get an exception due to interest.

Right now, we don’t have any plans to fork logstash nor beats. AFAIK they aren’t changing licenses and while there are some feature parity issues they should still be usable. Also, we have our hands full with Elasticsearch and Kibana.

1 Like

I was told that the docs were not eligible for forking, but looking at it myself I have questions. :face_with_monocle: I’m seeking further guidance.

If it is eligible there are definitely some hoops to jump through (different format and organization) and it would not be a small task to divide out x-pack specific stuff.

And if we could, the other question is if it’s better to just start fresh and build from the Open Distro docs? To be clear, this is not my decision to make, but my personal assessment of the first party docs is that they are wide but not deep and a tad unclear. Could we do better?

So, tl;dr Not sure. I would guess ‘no’, but now I’m double checking.

anyway, but at least we should make sure to not commingle the docs for the fork with open distro docs especially with the fact in mind to later put the fork (incl. docs) into a decentrally governed organization.

Open Distro plugins/tools are also destined for governance as well AFAIK.

ah, ok, didn’t know. Thats great and a strong commitment from AWS to OSS!

1 Like

Just a question: as in the ELK stack all the components gets released ‘all togheter’ by version number in order to ensure compatibility, how do you plan to ensure compatibility between the new ES fork and the remaining elastic oss components (in primis logstash and beats), expecially if a new versioning scheme is used ?

1 Like

That’s a great question. I have thoughts, but I would be speaking without full knowledge if I responded now. Let me take this up with the team and get back with you.

IMHO the question from @tvc_apisani is two fold:

  1. API compatibility (ES Rest API/Kibana Rest Api)
  2. ECS compatibility (Overview | Elastic Common Schema (ECS) Reference [1.7] | Elastic)

Right?

See also the comments from @igorid70 About Stepping up: Elasticsearch & Kibana Forks - #2 by igorid70

@frotsch Good breakdown (also responded to @igorid70 in that thread)

To answer your questions

  1. We have no appetite to break the API. If subsequent versions of Elasticsearch come out (not this fork) that break with 7.10, then that is a different issue.
  2. I can’t see us breaking anything to do with ECS as long as it stays open source, which seems like a fairly safe bet.

Normal disclaimers that these are crystal balls but I can tell you where the team is at on these issues today.

Will there be any possible impact from the possible outcome of Oracle v Google in the USSC as far as API compatability goes? Obviously not now, but future versions might get hit.

I think the whole open source community will be upset if that case goes sideways. I doubt it would apply to anything that is already released as open source. After the decision, we will need to figure out how it applies in our circumstance.