These finally release work that has been merged to the master and v3-0.0-rc branches for some time, and fix a few dependency issues that have cropped up since the last stable releases.
Thanks and apologies to the contributors that have made these.
It is still recommended to use the RC Nameko 3.0.0 branch even though the published docs reflect v2.x. At this point the 3.0.0 RCs have been stable and in use for a long time.
The official release has been waiting for accompanying documentation, but at this point I’m wondering whether it would be better to release v3 even without updated docs and iterate from there. If anyone has an opinion on that I would welcome it.
Hi. I love nameko, thanks for all the hard work.
Im currently using Nameko v2.x in production at work and you recommend to use version v3, are there any breaking changes if I just bump up mu current version to v3?, Is it safe to just migrate.
Thanks for the update. Personally I have been using 3.0.0rc8 for quite some time. All this time if something was not working as described on the docs, I have had a look at the code. Not the optimal especially when it comes to a library but honestly It wasn’t big deal, on the contrary it was a good opportunity to get more familiar with nameko’s codebase. In the end of the day I think it’s a matter on how you (and the rest of core contributors) prefer to release it depending on the next steps you have in mind.
I ran into an issue with 2.13.0 with the Exchange declaration where it removed the auto_delete flag. To work around this, I’m pinned to 2.12.0. Can you provide any insight into this change? Thanks!
The biggest changes are configuration improvements (there’s now a global object you can reference at any time) and a refactor of the AMQP extension internals.
The AMQP changes are backwards compatible as far as I recall. The config changes are mostly backwards compatible and will break up loudly at test or service start time otherwise.
I’m running into issues during upgrades. There are other services connected to that exchange, so when my Nameko service attempts to connect with mis-matched exchange parameters, it gets rejected by the RabbitMQ server.
You will run into this situation whenever the definition of a queue or exchange changes and they have already been declared. Unfortunately they are not mutable, so the only remedy is to remove the existing exchange and let it be redeclared with the new definition.
To make matters worse, if you delete the exchange while older versions of the services are still running, the older versions will either declare it with the old definition, or complain with the same error if the new service managed to redeclare first.
If you can tolerate downtime, you can stop all existing services, delete the exchange, and then roll out upgraded versions.
If not, you have to prevent the new services from trying to redeclare the event exchange. There is no good hook for this unfortunately, but you can do so by patching the get_event_exchange function:
from nameko.events import event_handler
from unittest.mock import patch
def get_event_exchange(service_name):
from nameko.constants import PERSISTENT
from kombu import Exchange
exchange_name = "{}.events".format(service_name)
exchange = Exchange(
exchange_name,
type="topic",
durable=False,
delivery_mode=PERSISTENT,
no_declare=True,
)
return exchange
patch("nameko.events.get_event_exchange", new=get_event_exchange).start()
class Service:
name = "service"
@event_handler("foo", "bar")
def handle(self, evt):
pass
This is ugly but would allow you to release services using the latest version.
Once there’s no service automatically redeclaring the event exchange, you will be able to delete and redeclare it manually (with the correct policies) with little or no downtime.
First, great work, it’s quite pleasant to work with a framework with such a straightforward use.
I’m about to use it in my company. I’m quite interested in using the latest version as the global config would make things even easier. But I’m afraid as long as it’s a release candidate version, it would be more difficult to justify this choice. So from my perspective, release officially the v3 would prevent from being stuck with the version 2. I’m not sure an outdated documentation is that a big deal if the nameko community keeps growing. To do so, I think nameko must not be “stuck” for too long.
Just my two cents still.
Great job anyway.
