Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

textproc/opensearch: Update to 2.8.0 #1

Merged
merged 3 commits into from
Jun 21, 2023
Merged

textproc/opensearch: Update to 2.8.0 #1

merged 3 commits into from
Jun 21, 2023

Conversation

smortex
Copy link
Member

@smortex smortex commented Jun 7, 2023

2023-06-06

I just started to update ports, started the build but have not tested yet.

2023-06-07

OpenSearch and OpenSearch-Dashboard start. Older dashboards / visualizations are not shown. Importing them seems to fail. Not sure why.

@alonsobsd
Copy link
Member

I think we can not follow the same release model like opensearch because it could break easily some ports like wazuh for example. Probably 2.7.1 will be released in some moment. Perphaps the best could be add devel ports for update it with latest version of opensearch? (opensearch-devel, opensearch-dashboards-devel) or just add a specific version for wazuh for example (opensearch26, opensearch26-dashboards)? what do you think about it?

@smortex
Copy link
Member Author

smortex commented Jun 7, 2023

Hum… https://opensearch.org/blog/what-is-semver/ made me think this should not happen (2.7.1), but maybe I am wrong. I'll ask the question on Slack and add a link here so that maybe someone can help us.

@smortex
Copy link
Member Author

smortex commented Jun 7, 2023

Got confirmation form someone from AWS/OpenSearch that after 2.8.0, the next version will be 2.8.1 or 2.9.0 but there will be no more 2.7.x or any older 2.x version. They do releases for the two maintained branches: 1.x and 2.x, and releases are cut from these.

That being said, if it helps with your use case, we can create a different port for each minor version, knowing that it will not be updated once a newer minor version is released, so at that point we can mark the port DEPRECATED and set an EXPIRATION_DATE, e.g.

textproc/opensearch26 (2.6.0, DEPRECATED)
textproc/opensearch27 (2.7.0, DEPRECATED)
textproc/opensearch28 (2.8.0)

We can also have textproc/opensearch for the lastest version, and when a new minor version is made available copy it and then update:

textproc/opensearch26 (2.6.0, DEPRECATED)
textproc/opensearch27 (2.7.0, DEPRECATED)
textproc/opensearch (2.8.0)

becomes when 2.9.0 is released:

textproc/opensearch26 (2.6.0, DEPRECATED)
textproc/opensearch27 (2.7.0, DEPRECATED)
textproc/opensearch28 (2.8.0, DEPRECATED)
textproc/opensearch (2.9.0)

@hackacad
Copy link
Member

hackacad commented Jun 8, 2023

'd agree on splitting Ports into versions. I think the same goes for Wazuh, etc.?

I think using flavors would be a good option. For example, a meta port opensearch would link to opensearch2x (latest).

For pkg.FreeBSD.org, you will always get the latest version. If you need to stick to a specific version (e.g., Wazuh not being up to date), you can either install the specific release or configure your branch in pourdriere/make.conf (DEFAULT_VERSIONS). The advantage would be the you don't need to touch any automation templates/workflows.

@hackacad hackacad marked this pull request as ready for review June 13, 2023 12:51
Copy link
Member

@hackacad hackacad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues after upgrade from 2.4 and 2.6

@dblock
Copy link

dblock commented Jun 14, 2023

The only reason we release something like 2.7.1 would be a critical (high?) security vulnerability that cannot wait for a 2.8.0. We should clarify this in OpenSearch docs, too, please feel free to open an issue/contribute.

@smortex
Copy link
Member Author

smortex commented Jun 14, 2023

The only reason we release something like 2.7.1 would be a critical (high?) security vulnerability that cannot wait for a 2.8.0. We should clarify this in OpenSearch docs, too, please feel free to open an issue/contribute.

@dblock 2.8.0 is currently available 😅 …

Did you mean:

  • a 2.8.1 would be released if a security fix could not wait 2.9.0 (i.e. only the latest version can get updates); or
  • a 2.7.1 would be released if a security fix could not wait 2.8.1 (i.e. on older minor version may have updates if updating the current minor version is causing some trouble).

@smortex
Copy link
Member Author

smortex commented Jun 14, 2023

Got confirmation from slack. If today (latest versions of OS are 1.3.10 and 2.8.0) a critical vulnerability is found, it would be fixed as 1.3.11 and 2.8.1 in a timely fashion.

So this proposition is right:

  • a 2.8.1 would be released if a security fix could not wait 2.9.0 (i.e. only the latest version can get updates);

And to complete this, if a non-critical vulnerability is found, the fix will be part of the next release, 2.9.0, according to the schedule for that release (July 18th, 2023 for 2.9.0 according to the OpenSearch Project Roadmap).

@dblock
Copy link

dblock commented Jun 14, 2023

Right on. Want to contribute this explanation to https://github.com/opensearch-project/OpenSearch-build#releases-and-versions? This way the FreeBSD port can reference it?

@smortex
Copy link
Member Author

smortex commented Jun 17, 2023

Right on. Want to contribute this explanation to opensearch-project/OpenSearch-build#releases-and-versions? This way the FreeBSD port can reference it?

@dblock That would be great! I though I could do this before going on holiday but I still have to pack the things 😓 I'll try to give it a shot when I am back after next week.


Regarding the change in the way we manage the ports (this main discussion), I think it makes sense to "announce" it in the FreeBSD Quarterly Status Report for Q2 which ends soon. While this has not yet been discussed, since I think about it, before I an AFK for a week, and in order to avoid being in a hurry to write something at the last moment, I wrote a report that I think match everyone's expectations. I opened a Draft PR here:
freebsd/freebsd-doc#189

The document is in a fork in our GitHub organization, so you can add commits to update the PR, iterate and discuss changes there. You are invited to do so! I went beyond what was discussed here, the idea is not to impose some way to do thing, but start a discussion about how we want to do this.

I will be back on the 26th. When I catch up, it would help if I know you are okay with this. If I see changes, that will be trivial, but if my statements looks good to you and you have nothing to add, please still do something that help me see this has been reviewed in some way (:+1:, PR review, comment). Thanks!

@alonsobsd
Copy link
Member

Hi, I have tested wazuh 4.4.4 with opensearch[-dashboards] 2.8.0 and It is working without problems.

image

I was reading more about opensearch semver and I noted in theory 2.x version will not break anything before of 3.x is released because 2.x releases (2.6.x, 2.7.x, 2.8.x ...) do not add breaking changes. I mean we could update opensearch[-dashboards] safely. Otherwise, in rare case we could add a aditional opensearch* port version

@alonsobsd alonsobsd merged commit 7ed4b41 into main Jun 21, 2023
@alonsobsd
Copy link
Member

Hi, I have committed 2.8.0 to ports tree. @smortex thanks for PR. Take a look at https://cgit.freebsd.org/ports/commit/?id=e9ea52f0fdff54c9299a83fac61b5f3214056199

@smortex smortex deleted the opensearch-2.8.0 branch June 24, 2023 20:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants