Weekly meeting
by Vittorio Rigamonti
Hi team,
I won't be able to be in the today's weekly meeting.
Here's my log for the last week:
HRCPP-379 Add ArchiveArtifacts plugins to Jenkinsfile
worked on the jenkins pipeline that allows to build releases. This took me
some time mainly because I spent lot of time in running the build to test
my devs.
Then I've released the 8.1.1 clients. Annouced here:
http://blog.infinispan.org/2017/05/hotrod-clients-cc-811final-released.html
I'm also working on these:
HRCPP-376 SASL (PLAIN,MD5) implementation for Windows
rebasing the related PR
HRCPP-377 Expose SASL configuration to .NET
I think it would take me some of this week's time, because I need to
implement a mechanism to share a .NET callback function to the C++ core.
This I'm sure will get me a lot of fun with SWIG.
--
Vittorio Rigamonti
Senior Software Engineer
Red Hat
<https://www.redhat.com>
Milan, Italy
vrigamon(a)redhat.com
irc: rigazilla
<https://red.ht/sig>
6 years, 11 months
Status 2017-05-29
by Sebastian Laskawiec
Hey!
Unfortunately I won't be able to attend today's status meeting, so here are
tasks I was looking at last week:
- I released KUBE_PING 9.3 and merged some downstream fixes into it.
- I release Spring Boot Starters 1.0.0.Final and added some more
documentation
- I added Infinispan Spring Boot Starters to Spring Initializr (
https://start.spring.io/)
- PR: https://github.com/spring-io/initializr/pull/434
- Unfortunately it was rejected (see comments in PR). The main
argument against it is that Spring Boot Developers are not in favor of
adding another caching library. I'm trying to convince them that
it will be
beneficial to do so. Please chime into the discussion if you wish.
- I worked on accessing Infinispan cluster hosted in Kubernetes from the
outside world. I have very good results in:
- https://github.com/slaskawi/external-ip-proxy
-
https://github.com/slaskawi/infinispan/tree/ISPN-7793/map_internal_extern...
- I'm doing benchmarks at the moment and will post some more
information soon.
- I've been doing most of the tests on Google Container Engine and I
must say, the user experience is really good.
- I created OpenShift templates for bootstrapping Infinispan:
https://github.com/infinispan/infinispan-openshift-templates
- I also participated in lots and lots of discussion around Infinispan
and Kubernetes.
This week I plan:
- Finish exposing cluster hosted in Kube to the outside world and
publish benchmark results.
- Look briefly at Istio (sidecar approach)
- Start looking at ALPN and HTTP/2 support
Thanks,
Sebastian
--
SEBASTIAN ŁASKAWIEC
INFINISPAN DEVELOPER
Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig>
6 years, 11 months
REST Refactoring - breaking changes
by Sebastian Laskawiec
Hey guys!
I'm working on REST Server refactoring and I changed some of the previous
behavior. Having in mind that we are implementing this in a minor release,
I tried to make those changes really cosmetic:
- RestEASY as well as Servlet API have been removed from modules and
BOM. If your app relied on it, you'll need to specify them separately in
your pom.
- Previous implementation picked application/text as a default content
type. I replaced it with text/plain with charset which is more precise and
seems to be more widely adopted.
- Putting an entry without any TTL nor Idle Time made it living forever
(which was BTW aligned with the docs). I switched to server configured
defaults in this case. If you want to have an entry that lives forever,
just specify 0 or -1 there.
- Requesting an entry with wrong mime type (imagine it was stored using
application/octet-stream and now you're requesting text/plain) cased Bad
Request. Now I switched it to Not Acceptable which was designed specially
to cover this type of use case.
- In compatibility mode the server often tried to "guess" the mimetype
(the decision was often between text/plain and application/octet-stream). I
honestly think it was a wrong move and made the server side code very hard
to read and predict what would be the result. Now the server always returns
text/plain by default. If you want to get a byte stream back, just add
`Accept: application/octet-stream`.
- The server can be started with port 0. This way you are 100% sure that
it will start using a unique port without colliding with any other service.
- The REST server hosts HTML page if queried using GET on default
context. I think it was a bug that it didn't work correctly before.
- UTF-8 charset is now the default. You may always ask the server to
return different encoding using Accept header. The charset is not returned
with binary mime types.
- If a HEAD request results in an error, a message will be returned to
the client. Even though this behavior breaks Commons HTTP Client (HEAD
requests are handled slightly differently and causes the client to hang if
a payload is returned), I think it's beneficial to tell the user what went
wrong. It's worth to mention that Jetty/Netty HTTP clients work correctly.
- RestServer doesn't implement Lifecycle now. The protocol server
doesn't support start() method without any arguments. You always need to
specify configuration + Embedded Cache Manager.
Even though it's a long list, I think all those changes were worth it.
Please let me know if you don't agree.
Thanks,
Sebastian
--
SEBASTIAN ŁASKAWIEC
INFINISPAN DEVELOPER
Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig>
6 years, 11 months
Exposing cluster deployed in the cloud
by Sebastian Laskawiec
Hey guys!
A while ago I started working on exposing Infinispan Cluster which is
hosted in Kubernetes to the outside world:
[image: pasted1]
I'm currently struggling to get solution like this into the platform [1]
but in the meantime I created a very simple POC and I'm testing it locally
[2].
There are two main problems with the scenario described above:
1. Infinispan server announces internal addresses (172.17.x.x) to the
client. The client needs to remap them into external ones (172.29.x.x).
2. A custom Consistent Hash needs to be supplied to the Hot Rod client.
When accessing cache, the Hot Rod Client needs to calculate server id for
internal address and then map it to the external one.
If there will be no strong opinions regarding to this, I plan to implement
this shortly. There will be additional method in Hot Rod Client
configuration (ConfigurationBuilder#addServerMapping(String mappingClass))
which will be responsible for mapping external addresses to internal and
vice-versa.
Thoughts?
Thanks,
Sebastian
[1] https://github.com/kubernetes/community/pull/446
[2] https://github.com/slaskawi/external-ip-proxy
6 years, 11 months
Cache migration (rolling upgrades, dump/restore, etc)
by Tristan Tarrant
Hey all,
Infinispan has historically had two ways of performing live migration
between two clusters, via Hot Rod and via REST. We do not currently
provide an offline migration, although we do have a cache store
migration tool.
Gustavo has recently made several changes to the Hot Rod implementation
which have improved it greatly. The REST implementation is still not
robust enough, but I think we can abandon it and just focus on the Hot
Rod one ever for servers using REST.
The following is a list of stuff, mostly compiled by Gustavo, that needs
to be done to make everything smooth and robust:
1) Need a way to automate client redirection to the new cluster. I've
often referred to this as L4 client intelligence, which can also be used
for server-assisted cross-site failover.
2) Need a way to "rollback" the process in case of failures during the
migration: redirecting the clients back to the original cluster without
data loss. This would use the above L4 strategy.
3) Expose metrics and progress
4) Expose a way to cancel the process
5) Expose a container-wide migration process which can be applied to all
caches instead of one cache at a time.
6) The migration process should also take care of automatically
configuring the endpoints / remote cache stores at the beginning of the
process and removing any changes at the end.
6) Provide a future-proof format for the entries
7) Implement dump and restore capabilities which can export the contents
of a cluster to a file (compressed, encrypted, etc) or a collection of
files (one per cache).
Anything else ?
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
6 years, 11 months
