smallrye / smallrye Goto Github PK

SmallRye repo to handle cross projects work

License: Apache License 2.0

smallrye's Introduction

Contributing

Want to contribute? Great! We try to make it easy, and all contributions, even the smaller ones, are greatly welcome. This includes bug reports, fixes, documentation.

All SmallRye projects use GitHub Issues to manage issues. Open an issue directly in GitHub within the appropriate SmallRye project repository.

Becoming a Project Committer

Through continued contributions to SmallRye projects, other committers on the project can nominate you to become a committer too!

Check out the nomination process for full details.

Legal

All original contributions to SmallRye projects are licensed under the ASL - Apache License, version 2.0 or later, or, if another license is specified as governing the file or directory being modified, such other license.

All contributions are subject to the Developer Certificate of Origin (DCO). The DCO text is also included verbatim in the dco.txt file in the root directory of each repository.

Before you Contribute

To contribute, use GitHub Pull Requests, from your own fork.

Code Reviews

All submissions, including submissions by project members, need to be reviewed before they are merged.

Continuous Integration

We’re all human, so SmallRye projects use continuous integration to ensure consistency, particularly as most SmallRye projects need to pass the applicable MicroProfile TCK for that specification. Each pull request triggers a full build of the project. Please make sure to monitor the output of the build and act accordingly.

Tests and Documentation are not optional

Don’t forget to include tests in your pull requests. Also, don’t forget the documentation (Javadoc).

Setup

If you have not done so on your machine, you need to:

Install Git and configure your GitHub access
Install Java SDK (OpenJDK recommended)
Install Maven

IDE Config and Code Style

SmallRye projects have a strictly enforced code style. Code formatting is done by the Eclipse code formatter, using the config files found in Code Rules. By default when you run mvn install the code will be formatted automatically. When submitting a pull request the CI build will fail if running the formatter results in any code changes, so it is recommended that you always run a full Maven build before submitting a pull request.

Eclipse Setup

Open the Preferences window, and then navigate to Java → Code Style → Formatter. Click Import and then select the eclipse-format.xml file in the coderules directory.

Next navigate to Java → Code Style → Organize Imports. Click Import and select the eclipse.importorder file.

IDEA Setup

Open the Preferences window, navigate to Plugins and install the [Eclipse Code Formatter Plugin](https://plugins.jetbrains.com/plugin/6546-eclipse-code-formatter).

Restart your IDE, open the Preferences window again and navigate to Other Settings → Eclipse Code Formatter.

Select Use the Eclipse Code Formatter, then change the Eclipse Java Formatter Config File to point to the eclipse-format.xml file in the coderules directory. Make sure the Optimize Imports box is ticked, and select the eclipse.importorder file as the import order config file.

Signing Commits

Signing commits is required to make sure that the contributor matches the author. To be able to sign commits, use the following instructions: https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits

The small print

This project is an open source project, please act responsibly, be nice, polite, and enjoy!

smallrye's People

Contributors

Stargazers

Watchers

Forkers

isabella232

smallrye's Issues

Update to MP Health 3.0

Update to MP JWT 1.2

Kubernetes Lifecycle API

Integrate with https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/ to provide a lifecycle hook for the events, possibly CDI Event, but ideally async.

Might fit into SmallRye Health, but might also fit as a separate lifecycle type thing. MicroProfile doesn't define any lifecycle or events associated with one, which could be beneficial in terms of allowing different specifications to do different things at different phases

Multiple deployments in MicroProfile

Though MicroProfile as a whole has shied away from openly supporting multiple deployments on a single runtime, some specifications have defined "recommended behavior" around it.

Start a discussion as to whether there should be more formal verbiage around the explicit desire not to support multiple deployments at a high level, but also allow each specification to provide guidance on how it could be achieved on a spec by spec basis

Work on MP Config 2.0

Update to MP Config 2.0

High Level Overview for MP Config 2.0 from https://github.com/eclipse/microprofile-config/issues?q=is%3Aissue+milestone%3A%22MP+Config+2.0%22

Expose Conversion in Config API - eclipse/microprofile-config#492
Configuration Profiles - eclipse/microprofile-config#418
External Configuration Files - eclipse/microprofile-config#422
Config Value Metadata - eclipse/microprofile-config#43
Variable Replacement - - eclipse/microprofile-config#118

Operator modules for common behavior

Design proposal

Library of modules that can be utilized by Operators of other projects to provide common features to all Operators.

Description

Possible modules would be for things such as:

Informing Prometheus about Metrics endpoints, using a Service Monitor definition
Verifying Kubernetes Liveness and Readiness probes are properly defined for Health
Adjusting Fault Tolerance configuration based on observed behavior. Such as scaling instances up if the load is not being handled

It would not be limited to these modules only. As needs arise additional modules would be added when it makes sense for the functionality to be shared.

WildFly has an Operator that might cover some of this, now or in the future. Would be preferable to have these modules usable by WildFly Operator, https://github.com/smallrye/smallrye-parent/issues/126, or any other Java runtime operator.

One decision to make is around language. Would these modules be in GoLang, or Java (using Quarkus to build to native)?

Dates

Proposal submitted: 2020-09-24
Bake time end: 2020-09-29 (2 working days)

Reviewers
All

Tracking SmallRye project versions downstream

We need a means of tracking which versions of each SmallRye project is used by the various downstream projects (Thorntail, WildFly, Quarkus, EAP) so that we know what is using which bits.

Maybe interrogating pom files is an option?

Update to MP Fault Tolerance 3.0

Monitoring Dashboard

Offer a dashboard for visualizing tracing, metrics, fault tolerance all in one place.

Might be possible to define a dashboard as a Kubernetes Resource that can be used with Kiali

Work on MP REST Client 2.0

Measure TCK Performance

The idea is to catch performance issues with new PR's, by measuring the TCK run performance. If we see some degradation on the TCK run, it may mean that something was added to the implementation that is affecting performance.

This will help to identify possible performance issues before being reported by users or caught on application benchmarks.

Add a Dedicated Runner
Record and compare TCK runs
Microbenchmarks for selected features (retrieve a config, validate a JWT, etc).

Cloud Service API

Many cloud providers have their own custom services for storage, etc
Provide a developer centric API wrapper over specific cloud implementations
Akin to “OpenShift management across Clouds”, but for developers
Initial thought is an S3 wrapper:
- S3 has become a “de-facto” standard for cloud providers
- Amazon SDK for S3 is difficult to use, and specific to Amazon authentication
- Better Java wrapper around S3 APIs
  - Pluggable authentication for different cloud providers

There are some similarities with https://jclouds.apache.org. However, it appears that those APIs are only synchronous and heavily rely on cloud provider information in the code, as opposed to just dependencies.

Also, check out https://github.com/noobaa/noobaa-core which is S3 abstraction

MP TCKs utilizing WAR deployment type

Currently, a large (all?) number of specifications utilize the WAR deployment package type in the TCKs.

As MicroProfile doesn't define distinctions between deployment types, requiring a WAR deployment type can impact new implementations that don't offer WAR packaging.

Open a discussion to consider mandating all TCK tests use JAR deployment type or some alternative means of the TCKs being executed.

Discussion on defining Container/Cloud Immutability for MicroProfile

It's generally agreed that containers translate to immutability.

However, MicroProfile doesn't have any definitions around whether it's Immutable or not, and the implications that bring.

For example, MP Config explicitly leaves the door open to dynamic changes, which may not make sense in an immutable environment.

An architectural discussion needs to be started to determine whether there's interest in defining this, and then what that definition should be.

OpenTelemetry

We need to do some investigation around OpenTelemetry and implement something akin to what OpenTracing does today.

As OpenTelemetry goes beyond what OpenTracing does, we need to take into account the changes around tracing and whether Metrics are impacted with this.

Kubernetes Operator for SmallRye

Create a Kubernetes Operator that can be used for things such as:

Informing Prometheus about Metrics endpoints, using a Service Monitor definition
Verifying Kubernetes Liveness and Readiness probes are properly defined for Health
Adjusting Fault Tolerance configuration based on observed behavior. Such as scaling instances up if the load is not being handled

WildFly has an Operator that might cover some of this, now or in the future. Ideally, we have the code doing the work in a separate artifact so that a SmallRye Operator and WildFly Operator, and maybe a Quarkus Operator, can all use the same underlying code.

Publish Antora UI by pushing it into a branch

The current process requires than when someone updates the UI, they have to include the newly built UI zip bundle in the pull request. This is error prone and does not scale well, especially should there be multiple pull requests active at one point in the future, in which case after merging one, the other(s) will always need rebasing and rebuilding of the bundle.
A bit better approach would be to use GH actions to build the ZIP and push it to a separate branch automatically after every change to master.

Rename master to main in all SmallRye Repositores

Config
...

A consistent container used for all MP TCK testing.

Currently, it's a mix of WildFly, Weld SE, and possibly others

Work on MP Metrics 3.0

Universal Type Safe Client

Homogeneous Type Safe API for REST, SSE, and Websocket

@GET
@Path("/persons")
@ContentType("application/x-json-array-stream")
Publisher<Person> getPersons();

@POST
@Path("upload-a-stream")
CompletionStage<Void> upload(Publisher<Person> stream);

@WebSocket
@Path("/chat/{username})
Session socket(@PathParam String username);

Converters

Work on MP Metrics 4.0

"SmallRye" user in JIRA

Investigate creation of a SmallRye user in JIRA that can then be mentioned in issues and comments, instead of specific people. Particularly beneficial as we have multiple downstream consumers of the projects and use GH for issues.

Maybe needs a mailing list for it?

Separate productization process

The product builds of SmallRye are currently performed as part of Thorntail product work.

We need to separate it into its own set of builds so that we can spin new versions at any time for Thorntail, EAP, or Quarkus.

We also need to document the process for everyone

Migrate the build of smallrye.github.io site to GH Actions

Router

Router for not just HTTP and Request -> Response
- Topics, messages, etc
- HTTP/3 (Quic)
Offers:
- Fluent API
- Reverse router
- Sub-router
- Parameter matching (predicates)
- Static content, default last route, error management, stream support
- Ability to layer runtime routes over build time based ones (Quarkus)
Not a replacement for JAX-RS, but a functional alternative

Logging and i18n for all implementations

Update to MP OpenAPI 2.0

Update to MP REST Client 2.0

Update to MP Metrics 3.0

Work on MP JWT 1.2

Incorporate AsyncAPI into Quarkus

Depends on smallrye/smallrye-async-api#1

Discussion of "grey areas" in MP

Would be good to explicitly define any "grey areas" within MicroProfile that are not explicitly defined or identified in specifications.

For example, it's accepted that MicroProfile doesn't have the context of sessions, making @SessionScoped beans meaningless. However, that's not defined anywhere so it could be expected that implementations support it.

This may be tangentially related to the CDI Lite discussions, but maybe this is an approach that could feed that discussion with ideas.

See https://github.com/smallrye/smallrye-parent/issues/121 for idea on separate Architecture spec

Updating of config for monitoring

Though containers are immutable, it can be beneficial to update configuration in a running container to assist in diagnosing possible issues. Changing configuration and restarting the container often means the problem is fixed.

Some things that could be beneficial to do:

Setting log levels
Thread/Heap dumps. Mounting a temporary volume to store the dump
Enable specific metrics
Adjusting Fault Tolerance settings

One solution is that config is still immutable, in the sense that it's not updated and published through a change event of any kind. Instead, SmallRye implementations read configuration values on every usage, meaning that a ConfigMap with a changed value will be picked up without restart.

Might need to be discussed as to whether this would have knock-on implications for https://github.com/smallrye/smallrye-parent/issues/117

Define MP TCK Challenge process

Informally it's understood and accepted that an implementation can still claim it passes the TCK while excluding a number of tests that are currently being challenged through issues in the specification.

It would be good to formally define the TCK challenge process and the implications around compatibility.

Work on MP OpenAPI 2.0

Discuss creating an MP Architecture, or Platform, spec

Start a discussion on whether MP should have an Architecture, or Platform, specification.

It would only be a specification document, no associated APIs or TCKs present.

Architecture specification might be better suited, as then it can apply to the platform and standalone specifications equally.

It can then define items across specifications, and maybe how specifications should coordinate when they interact.

Work on MP Fault Tolerance 3.0

Testing Alternative

Arquillian was great for traditional WAR/EAR deployments that were very large, where testing a single piece of an application was beneficial. With microservices there's less of a piecemeal concern for testing.
Simplify test construction
Way to register dependent services, ala JWT

Health check for Fault Tolerance

Create a Health Check that applications/runtimes can use for utilizing the Fault Tolerance metrics to determine whether an application should be "unhealthy" based on the frequency with which a circuit is open. Or other possible measures.

Maybe, like ConfigSource, we offer artifacts with "common" Health Checks that can be added and used?

Updated website

Currently, https://smallrye.io/ is very basic.

We need an appropriate way to represent the versions of each project that are released, and the MP versions it relates to.

Also, links to documentation, may be hosted at docs.smallrye.io?

MicroProfile 4.0 Status

Spec	Implementation	Passing TCK
Config 2.0	https://github.com/smallrye/smallrye-config/tree/mpconfig20	✅
JWT 1.2	https://github.com/smallrye/smallrye-jwt/tree/mpjwt12	✅
Health 3.0	https://githhttps://github.com/smallrye/smallrye-health/tree/health30	✅
Fault Tolerance 3.0	https://github.com/smallrye/smallrye-fault-tolerance/tree/next	✅
Metrics 3.0	https://github.com/smallrye/smallrye-metrics/tree/master	✅
REST Client 2.0	https://github.com/resteasy/Resteasy/tree/mp-rest-client-20	✅
OpenAPI 2.0	https://github.com/smallrye/smallrye-open-api/tree/master	✅
OpenTracing 2.0	https://github.com/smallrye/smallrye-opentracing/tree/master	✅

Feature Flags

I'm thinking about creating a new SmallRye projects for feature flags / switches / toggles. Here's a couple of initial thoughts.

The most important use cases:

define typed features in code: boolean flags (on/off) would have special treatment, but other types of features must also be possible (perhaps String would be the lowest common denominator, and if there's a converter for it in SmallRye Converters, then it's a supported type)
access a value of any particular feature for "current" user

Note that the above doesn't include "setting values of features", "performing gradual rollouts", "conducting multivariate tests" or "dashboards" or anything like that. That's because we first need to decide whether this will only be "embedded" library, or whether this will be an abstraction over external systems for feature managements (e.g. Unleash or Flagsmith, but there are other solutions too), or whether it can be both. All choices would be interesting and make sense, but each leads to a somewhat different direction.

Some implementation ideas:

intuitive user facing API, probably based on CDI
non-blocking implementation
- note that these 2 requirements lead to an interesting API design problem (if (features.isEnabled(MY_FEATURE)) { ... } is intuitive for sure, but also necessarily blocking), so I expect we'll have to be creative here
feature definitions as Java enums, String constants just don't cut it
if we do the "embedded" mode, then we should be able to get feature values from multiple sources: constant, random (for given percentage of users, only makes sense for boolean flags?), custom claim in a JWT token, in a database, more?
figuring out "current user" is gonna be interesting, will probably need an SPI to be implemented by an integrator
- should probably provide a way to semi-identify a "guest" user (hash code of a tuple <remote IP address, day, month, year>, or hash code of a session identifier if there's one, something like that)

How I'd like to proceed:

spend a day or two building a prototype, to better understand the scope
internal approvals if necessary
create proper SmallRye project

WDYT?