[ANN] CloudI 1.7.2 Released!

21 views
Skip to first unread message

Michael Truog

unread,
Sep 13, 2017, 4:42:52 PM9/13/17
to cloudi-q...@googlegroups.com
Download 1.7.2 from
http://sourceforge.net/projects/cloudi/files/latest/download

The details for this release are below:
* Service configuration option request_timeout_adjustment was modified
to use Erlang monotonic time so timeout adjustments are not impacted
by any OS time changes (now all CloudI service request
timeout handling is using monotonic time)
* Added CloudI Service API logging_set configuration option
log_time_offset to log when the Erlang VM updates its time-offset
with the time-offset change logged in nanoseconds
(the offset is logged exactly when logging timestamps are changed)
* configure script now accepts environment variables to set release
configuration values: CLOUDI_ARG_NODE_NAME_SHORT,
CLOUDI_ARG_NODE_NAME_LONG, CLOUDI_ARG_NODE_COOKIE, CLOUDI_PID_FILE
(can be used to avoid manual vm.args modifications)
* Many deployment changes to make CloudI use robust:
* The release script is safe for root use
(external environment variables are blocked,
functionality is locked down, manages a pid file correctly, etc.)
* Execution now occurs within the logging directory so any
crash dump output is put there automatically
* cloudi_service_null is an Erlang service added to provide a simple
way of consuming CloudI service requests
(during testing and/or to handle invalid URL service names)
* cloudi_service_request_rate was added to the CloudI release to
provide an easy way of testing max throughput
* cloudi_service_http_cowboy and cloudi_service_http_elli now use an
update_delay argument to apply a change to timeout_async and/or
timeout_sync performed with the CloudI Service API services_update
* Bugs were fixed and other improvements were added
(see the ChangeLog for more detail)

CloudI is a "universal integrator" using an Erlang core to provide
fault-tolerance with efficiency and scalability. The CloudI API
provides a minimal interface to communicate among services so
programming language agnostic and protocol agnostic integration can
occur. CloudI currently integrates with the programming languages:
C/C++, Elixir, Erlang, Go, Haskell, Java, JavaScript/node.js,
OCaml, PHP, Perl, Python, and Ruby, Many reusable services are
included that rely on the CloudI service bus.

Please mention any problems, issues, or ideas!
Thanks,
Michael

SHA256 CHECKSUMS
cloudi-1.7.2.tar.bz2 (12963740 bytes)
987864e6e5a26ff7260a7d47e6a15085cdcef3fc88cc416662723e6c1398b5f0
cloudi-1.7.2.tar.gz (15810122 bytes)
5ffeddb4ddabc9611d02fe356022849d2cbb1d1557311651f3f5b42c37ba3d71

Akro

unread,
Dec 7, 2017, 8:06:30 AM12/7/17
to CloudI Questions
Hello,

I am testing the python3 support, and I'm not able to make it working.
I'm using the python hello_world from cloudi.org.

When the service is called: here's the problem:

2017-12-07T12:55:13.627180Z ERROR (STDERR:3411::<0.1093.0>:cloudi@hcn2)
Traceback (most recent call last):
  File "/home/hcn2/Development/Cloudi-1.7.2/hello_world.py", line 14, in run
    self.__api.poll()
  File "/home/hcn2/Production/Applications/Cloudi/lib/cloudi-1.7.2/api/python/cloudi.py", line 598, in poll
    return self.__poll_request(timeout, True)
  File "/home/hcn2/Production/Applications/Cloudi/lib/cloudi-1.7.2/api/python/cloudi.py", line 495, in __poll_request
    binary_to_term(pid))
  File "/home/hcn2/Production/Applications/Cloudi/lib/cloudi-1.7.2/api/python/cloudi.py", line 372, in __callback
    timeout, trans_id, pid)
  File "/home/hcn2/Production/Applications/Cloudi/lib/cloudi-1.7.2/api/python/cloudi.py", line 232, in return_sync
    OtpErlangBinary(trans_id), pid)))
  File "/home/hcn2/Production/Applications/Cloudi/lib/cloudi-1.7.2/api/python/erlang.py", line 335, in term_to_binary
    data_uncompressed = _term_to_binary(term)
  File "/home/hcn2/Production/Applications/Cloudi/lib/cloudi-1.7.2/api/python/erlang.py", line 593, in _term_to_binary
    return _tuple_to_binary(term)
  File "/home/hcn2/Production/Applications/Cloudi/lib/cloudi-1.7.2/api/python/erlang.py", line 640, in _tuple_to_binary
    b''.join([_term_to_binary(element) for element in term])
  File "/home/hcn2/Production/Applications/Cloudi/lib/cloudi-1.7.2/api/python/erlang.py", line 640, in <listcomp>
    b''.join([_term_to_binary(element) for element in term])
  File "/home/hcn2/Production/Applications/Cloudi/lib/cloudi-1.7.2/api/python/erlang.py", line 607, in _term_to_binary
    return term.binary()
  File "/home/hcn2/Production/Applications/Cloudi/lib/cloudi-1.7.2/api/python/erlang.py", line 142, in binary
    raise OutputException('unknown binary type')
erlang.OutputException: unknown binary type
2017-12-07T12:55:13.634344Z WARN  (cloudi_core_i_services_monitor:453:handle_info/2:<0.1089.0>:cloudi@hcn2)
Service pid <0.1312.0> error: socket_closed

 The configure is using --with-python-version=3, and the config.log shows that the python3 binary is found.

What is the correct way to declare a python3 service ?

[[{prefix, "/python/"},
  {file_path, "/usr/bin/python3"},
  {args, "/home/hcn2/Development/Cloudi-1.7.2/hello_world.py"}]]


file_path should be "python" or "python3" ?

How can I check at run time which version of python is the default version ?

Thanks !



 

Michael Truog

unread,
Dec 7, 2017, 2:25:30 PM12/7/17
to cloudi-q...@googlegroups.com
Hi,

Both python2 and python3 work with the same cloudi and cloudi_c modules.  The quickstart was previously assuming python2 use, but it has now been updated to use python3, with the only difference being the b prefix to the 'Hello World!' string to make it bytes instead of it defaulting to a unicode string in python3 execution.  With that fix, you can have the service configuration use either python2 or python3 as the file_path setting (your configuration is correct).

At runtime, you can use the CloudI Service API function services to get a list of all the services currently running (http://cloudi.org/api.html#2_services).  The service id and the service configuration (using the tuple format) are both provided for each running service, so you will see the python3 executable file path in the file_path value for any python services using python3.

The reasons the configure script needs the --with-python-version parameter is to determine what is used to compile the cloudi_c module and to determine what executable file_path is used for python services with the integration tests configuration.  However, configuring the CloudI installation with python3 won't prevent you from using both python2 and python3 with the installation.  The default for --with-python-version did change to 3 in the 1.7.2 release.

Best Regards,
Michael
--
You received this message because you are subscribed to the Google Groups "CloudI Questions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cloudi-questio...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages