Showing posts with label python – RHD Blog. Show all posts
Showing posts with label python – RHD Blog. Show all posts

Tuesday, December 11, 2018

Processing CloudEvents with Eclipse Vert.x

Our connected world is full of events that are triggered or received by different software services. One of the big issues is that event publishers tend to describe events differently and in ways that are mostly incompatible with each other.

To address this, the Serverless Working Group from the Cloud Native Computing Foundation (CNCF) recently announced version 0.2 of the CloudEvents specification. The specification aims to describe event data in a common, standardized way. To some degree, a CloudEvent is an abstract envelope with some specified attributes that describe a concrete event and its data.

Working with CloudEvents is simple. This article shows how to use the powerful JVM toolkit provided by Vert.x to either generate or receive and process CloudEvents.

SDKs for working with CloudEvents

In addition to the specification, the CloudEvents team from the Serverless Working Group is working on different SDKs for various platforms, such as JavaScriptGolangC SharpJava, and Python. This article will give a quick overview of the Java SDK and how it can be used inside an application built with Eclipse Vert.x.

The API is very simple and contains a generic CloudEvent class as well as a builder to create an instance of a CloudEvent:

final CloudEvent<MyCustomEvent> cloudEvent = new CloudEventBuilder<MyCustomEvent>()
    .data(new MyCustomEvent(...))
    .type("My.Cloud.Event.Type")
    .id(UUID.randomUUID().toString();)
    .source(URI.create("/trigger");)
    .build();

Above, we use the CloudEventBuilder to create a very simple CloudEvent instance. However, in isolation, the API does not show its strength.

Eclipse Vert.x

Eclipse Vert.x is a toolkit for building reactive applications on the JVM. It is event-driven and nonblocking, which means applications can handle a lot of concurrency using a small number of kernel threads. See the resources below for more info on Vert.x. Fortun

Fortunately, support for Eclipse Vert.x is included in the CloudEvents Java SDK:

<dependency>
    <groupId>io.cloudevents</groupId>
    <artifactId>http-vertx</artifactId>
    <version>0.2.0</version>
</dependency>

Sending a CloudEvent to a remote service

Now that we have our CloudEvent object, capturing our event data, we want to send it to a remote cloud service, which will then process it:

final HttpClientRequest request = vertx.createHttpClient().post(8080, "localhost", "/");

// add a client response handler
request.handler(resp -> {
    // react on the server response
});

// write the CloudEvent to the given HTTP Post request object
VertxCloudEvents.create().writeToHttpClientRequest(cloudEvent, request);
request.end();

After creating an HTTP Post request, we set up an async handler to deal with the future response of the server. Finally, the writeToHttpClientRequest of our VertxCloudEvents utility is used to serialize the actual CloudEvent object to the given HttpClientRequest.

Receiving CloudEvents with Vert.x

The VertxCloudEvents utility also contains a different function to receive a CloudEvent inside an Eclipse Vert.x HTTP server application:

import io.cloudevents.http.reactivex.vertx.VertxCloudEvents;
import io.vertx.core.http.HttpHeaders;
import io.vertx.reactivex.core.AbstractVerticle;

public class CloudEventVerticle extends AbstractVerticle {

  public void start() {

    vertx.createHttpServer()
      .requestHandler(req -> VertxCloudEvents.create().rxReadFromRequest(req)
      .subscribe((receivedEvent, throwable) -> {
        if (receivedEvent != null) {
          // I got a CloudEvent object:
          System.out.println("The event type: " + receivedEvent.getType())
        }
      }))
      .rxListen(8080)
      .subscribe(server -> {
        System.out.println("Server running!");
    });
  }
}

Above, we start a simple HTTPServer, using the Vert.x API for RxJava 2. Inside the reactive request handler, we invoke the rxReadFromRequest() method and subscribe to the CloudEvents it returns for further processing. Now we can work with the CloudEvent object inside our own server-side framework!

Conclusion and Outlook

Working with CloudEvents is simple and Vert.x provides a powerful JVM toolkit to either generate or receive and process CloudEvents in our system. CloudEvents are being adopted by more and more tools and frameworks such as Knative, which uses CloudEvents to exchange data between different components and services in a standardized format.

The CloudEvent specification is in its early stages with its current 0.2 version. However, even in such infancy, it is generating traction and proving an increasingly useful specification to allow interoperability between applications.

Additonal Resources

 

Share

The post Processing CloudEvents with Eclipse Vert.x appeared first on RHD Blog.



from python – RHD Blog
read more

Tuesday, November 27, 2018

What, No Python in RHEL 8 Beta?

TL;DR Of course we have Python! You just need to specify if you want Python 3 or 2 as we didn’t want to set a default. Give yum install python3 or yum install python2 a try. Or, if you want to see what we recommend you install yum install @python36 or yum install @python27. Read on for why.

For prior versions of Red Hat Enterprise Linux, and most Linux Distributions, users have been locked to the system version of Python unless they got away from the system package manager. While this can be true for a lot of tools (ruby: rvm; node: nvm) the Python use case is worse because so many Linux tools (like yum) rely on Python.

In order to improve this experience for RHEL8 users, we have moved the Python used by the system “off to the side”. In RHEL 8 we also introduced Modularity. As a result, in combination with Python’s ability to be parallel installed, we can now make multiple versions of Python available and installable, from the standard repositories, installing to the standard locations. Now, users can choose what version of Python they want to run in any given userspace and it simply works. For more info, see my article, Introducing Application Streams in RHEL 8.

To be honest, the system maintainers also get some advantages of not being locked to an aging version of Python for our system tools. With users not relying on a particular version of Python coming with the system installation, we have the freedom to take advantage of new language features, performance improvements, and all the other goodness a developer gets when tracking near the upstream version.

However, this has resulted in a dilemma. When a user sits down at a fresh installation of RHEL8 they will naturally expect that /usr/bin/python will run some version of Python. If you follow the recommendation in Python Enhancement Proposal (PEP) 394, that will be Python 2. However, at some point, a new PEP will likely want to change that recommendation to Python 3, probably during, the typically *10* year, life of RHEL 8!

So, what do we do? Well, if we follow the current recommendation, we make some present day users happy. However, when the Python Community shifts to recommending Python 3 as the default, we will make new users unhappy.

As a result, we came to the tough conclusion, don’t provide bare Python at all. Instead, ask our users from the beginning to choose which version of Python they actually want. So, yum install python results in a 404.

However, we do try to make it as easy as possible to get Python 2 or 3 (or both) on to your system. We recommend using yum install @python36 or yum install @python27 to take advantage of the recommended set of packages to install. If you really want *just* the Python binary, you can use yum install python3 or yum install python2.

We have also setup the alternatives infrastructure so that when you install either (or both) you can easily make /usr/bin/python point to the right place using alternatives --config python. However, as we explained above, and aligned with the Python PEP, we don’t recommend relying on /usr/bin/python being the correct python for your application.

To conclude, yes, Python is included in RHEL 8! And, it will be even better than in the past! If you want more details on anything in this post, please see the How To Guide on Red Hat Developers.

Oh and if you haven’t downloaded RHEL 8 yet—go to developers.redhat.com/rhel8 now.

Additional Information

 

 

Share

The post What, No Python in RHEL 8 Beta? appeared first on RHD Blog.



from python – RHD Blog
read more

TestDriven.io: Working with Static and Media Files in Django

This article looks at how to work with static and media files in a Django project, locally and in production. from Planet Python via read...