Open-source News

Linux 5.18 Features Include Many AMD & Intel Additions, Tesla FSD Chip, Other Changes

Phoronix - Mon, 04/04/2022 - 21:30
With Linux 5.18-rc1 released last night the merge window is now over for feature work on Linux 5.18. So as usual here is my feature overview of all the changes for Linux 5.18 that caught my eye and were interesting for this kernel that is working its way towards the stable debut by late May.

AMD Acquiring Pensando For $1.9B USD

Phoronix - Mon, 04/04/2022 - 20:22
It was just two months ago AMD completed its acquisition of Xilinx and now its newest data center play is entering into a definitive agreement to acquire Pensando...

Gentoo Linux Back To Spinning A Weekly LiveGUI DVD/USB ISO

Phoronix - Mon, 04/04/2022 - 18:56
To complement their minimal install images and various stage archives produced, the Gentoo project has restarted the process to also begin producing a LiveGUI DVD/USB image as a more friendly first encounter with this Linux distribution...

Mesa 22.1 Radeon Vulkan Driver Lands Ray Primitive Culling

Phoronix - Mon, 04/04/2022 - 18:26
Over the past month we have seen more open-source Radeon Vulkan ray-tracing support build up inside Mesa 22.1 with KHR_ray_query support merged, missing stubs that at least allow Doom Eternal to get further along with its ray-tracing code path, and now there is ray primitive culling that has landed...

Fedora Project Leader Calls Out NVIDIA Over Their Proprietary Linux Drivers

Phoronix - Mon, 04/04/2022 - 18:14
Fedora Project Leader Matthew Miller took to Twitter on Sunday with a long series of tweets of his personal opinion going after NVIDIA's proprietary driver stack and encouraging the company to be more like Intel and AMD with regards to open-source driver support...

DDC/CI Linux Driver Continues To Be Worked On For Managing Monitors

Phoronix - Mon, 04/04/2022 - 17:57
A Linux driver for the DDC/CI control protocol for modern displays (well, even many of those going back to ~2005) has been available out-of-tree while finally there has been recent work on getting this driver upstreamed into the kernel...

LLVM Begins Process For Allowing C++17 In Codebase

Phoronix - Mon, 04/04/2022 - 17:38
After LLVM moved from C++11 to allowing C++14 code within the LLVM code-base itself in 2019, LLVM developers are now preparing the transition to C++17...

Extend Kubernetes service discovery with Stork and Quarkus

opensource.com - Mon, 04/04/2022 - 15:00
Extend Kubernetes service discovery with Stork and Quarkus Daniel Oh Mon, 04/04/2022 - 03:00 Up Register or Login to like.

In traditional monolithic architecture, applications already knew where the backend services existed through static hostnames, IP addresses, and ports. The IT operation team maintained the static configurations for service reliability and system stability. This Day 2 operation has significantly changed since microservices began running in distributed networking systems. The change happened because microservices need to communicate with multiple backend services to improve the load balancing and service resiliency.

Explore the open source cloud Free online course: Developing cloud-native applications with microservices eBook: Modernize your IT with managed cloud services Try for 60 days: Red Hat OpenShift Dedicated Free online course: Containers, Kubernetes and Red Hat OpenShift What is Kubernetes? Understanding edge computing Latest articles for IT architects

The microservices topology became much more complex as the service applications were containerized and placed on Kubernetes. Because the application containers can be terminated and recreated anytime by Kubernetes, the applications can't know the static information in advance. The microservices don't need to be configured with the static information of the backend applications because Kubernetes handles service discovery, load balancing, and self-healing dynamically and automatically.

However, Kubernetes doesn't support programmatic service discovery and client-based load balancing through integrated application configurations. Smallrye Stork is an open source project to solve this problem, providing the following benefits and features:

  • Augment service discovery capabilities
  • Support for Consul and Kubernetes
  • Custom client load-balancing features
  • Manageable and programmatic APIs

Nevertheless, Java developers need some time to adapt to the Stork project and integrate it with an existing Java framework. Luckily, Quarkus enables developers to plug Stork's features into Java applications. This article demonstrates how Quarkus allows developers to add Stork's features to Java applications.

Create a new Quarkus project using Quarkus CLI

Using the Quarkus command-line tool (CLI), create a new Maven project. The following command will scaffold a new reactive RESTful API application:

$ quarkus create app quarkus-stork-example -x rest-client-reactive,resteasy-reactive  

The output should look like this:

...
[SUCCESS] ✅  quarkus project has been successfully generated in:
--> /Users/danieloh/Downloads/demo/quarkus-stork-example
...

Open a pom.xml file and add the following Stork dependencies: stork-service-discovery-consul and smallrye-mutiny-vertx-consul-client. Find the solution to this example here.


  io.smallrye.stork
  stork-service-discovery-consul


  io.smallrye.reactive
  smallrye-mutiny-vertx-consul-client
Create new services for the discovery

Create two services (hero and villain) that the Stork load balancer will discover. Create a new services directory in src/main/java/org/acme. Then create a new HeroService.java file in src/main/java/org/acme/services.

Add the following code to the HeroService.java file that creates a new HTTP server based on the Vert.x reactive engine:

@ApplicationScoped
public class HeroService {

    @ConfigProperty(name = "hero-service-port", defaultValue = "9000") int port;

    public void init(@Observes StartupEvent ev, Vertx vertx) {
        vertx.createHttpServer()
                .requestHandler(req -> req.response().endAndForget("Super Hero!"))
                .listenAndAwait(port);
    }
   
}

Next, create another service by creating a VillainService.java file. The only difference is that you need to set a different name, port, and return message in the init() method as below:

@ConfigProperty(name = "villain-service-port", defaultValue = "9001") int port;

public void init(@Observes StartupEvent ev, Vertx vertx) {
        vertx.createHttpServer()
                .requestHandler(req -> req.response().endAndForget("Super Villain!"))
                .listenAndAwait(port);
}Register the services to Consul

As I mentioned earlier, Stork allows you to use Consul based on Vert.x Consul Client for the service registration. Create a new ConsulRegistration.java file to register two services with the same name (my-rest-service) in src/main/java/org/acme/services. Finally, add the following ConfigProperty and init() method:

@ApplicationScoped
public class ConsulRegistration {

    @ConfigProperty(name = "consul.host") String host;
    @ConfigProperty(name = "consul.port") int port;

    @ConfigProperty(name = "hero-service-port", defaultValue = "9000") int hero;
    @ConfigProperty(name = "villain-service-port", defaultValue = "9001") int villain;

    public void init(@Observes StartupEvent ev, Vertx vertx) {
        ConsulClient client = ConsulClient.create(vertx, new ConsulClientOptions().setHost(host).setPort(port));

        client.registerServiceAndAwait(
                new ServiceOptions().setPort(hero).setAddress("localhost").setName("my-rest-service").setId("hero"));
        client.registerServiceAndAwait(
                new ServiceOptions().setPort(villain).setAddress("localhost").setName("my-rest-service").setId("villain"));

    }

}Delegate the reactive REST client to Stork

The hero and villain services are normal reactive RESTful services that can be accessed directly by exposable APIs. You need to delegate those services to Stork for service discovery, selection, and calling.

Create a new interface MyRestClient.java file in the src/main/java directory. Then add the following code:

@RegisterRestClient(baseUri = "stork://my-rest-service")
public interface MyRestClient {

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    String get();
}

The baseUri that starts with stork:// enables Stork to discover the services and select one based on load balancing type. Next, modify the existing resource file or create a new resource file (MyRestClientResource) to inject the RestClient (MyRestClient) along with the endpoint (/api) as seen below:

@Path("/api")
public class MyRestClientResource {
   
    @RestClient MyRestClient myRestClient;

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String invoke() {
        return myRestClient.get();
    }

}

Before you run the application, configure Stork to use the Consul server in the application.properties as shown below:

consul.host=localhost
consul.port=8500

stork.my-rest-service.service-discovery=consul
stork.my-rest-service.service-discovery.consul-host=localhost
stork.my-rest-service.service-discovery.consul-port=8500
stork.my-rest-service.load-balancer=round-robinTest your application

You have several ways to run a local Consul server. For this example, run the server using a container. This approach is probably simpler than installating or referring to an external server. Find more information here.

$ docker run --rm --name consul -p 8500:8500 -p 8501:8501 consul:1.7 agent -dev -ui -client=0.0.0.0 -bind=0.0.0.0 --https-port=8501

Run your Quarkus application using Dev mode:

$ cd quarkus-stork-example
$ quarkus dev

The output looks like this:

...
INFO  [io.quarkus] (Quarkus Main Thread) Profile dev activated. Live Coding activated.
INFO  [io.quarkus] (Quarkus Main Thread) Installed features: [cdi, jaxrs-client-reactive, rest-client-reactive, resteasy-reactive, smallrye-context-propagation, vertx]

--
Tests paused
Press [r] to resume testing, [o] Toggle test output, [:] for the terminal, [h] for more options>

Access the RESTful API (/api) to retrieve available services based on the round-robin load balancing mechanism. Execute the following curl command-line in your local terminal:

& while true; do curl localhost:8080/api ; echo ''; sleep 1; done

The output should look like this:

Super Villain!
Super Hero!
Super Villain!
Super Hero!
Super Villain!
...Wrap up

You learned how Quarkus enables developers to integrate client-based load balancing programming using Stork and Consul for reactive Java applications. Developers can also have better developer experiences using live coding while they keep developing the reactive programming in Quarkus. For more information about Quarkus, visit the Quarkus guides and practices.

Quarkus enables developers to integrate client-based load balancing programming using Stork and Consul for reactive Java applications.

Java Cloud Kubernetes What to read next This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

Pages