charms.reactive 0.6.1

Dmitrii Shcherbakov dmitrii.shcherbakov at canonical.com
Thu Feb 22 10:16:21 UTC 2018


Hi Merlijn,

Glancing at the documentation for Endpoints I can see how this can save a
lot of time on writing and testing the same code all over again.

Another idea related to endpoints is URL modeling (
https://tools.ietf.org/html/rfc3986#page-17): I don't think it's a rare
case where units have to exchange relation data that contains information
for socket 5-tuples or even URLs with some out of band metadata to be used
for making requests (e.g. connection parameters that can't be negotiated)

scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]

Writing code to set and retrieve that in every charm is isn't great so an
extension API (to create objects from JSONUnitDataView) would be good - all
to have a common way to exchange transport endpoint data (up to L4) and,
potentially, L7 endpoint data with path components. In my view, as of now,
when you have to write charm integration code, you need to think too much
about utility functionality including endpoint exchange for service
discovery.

This is very useful, thank you.

Best Regards,
Dmitrii Shcherbakov

Field Software Engineer
IRC (freenode): Dmitrii-Sh

On Thu, Feb 22, 2018 at 11:56 AM, Merlijn Sebrechts <
merlijn.sebrechts at gmail.com> wrote:

> Hi all
>
>
> Sending this email because I really like the new Endpoints pattern and
> because Cory is underselling the changes of this release. 😉
>
> This version adds the `all_departed_units
> <https://charmsreactive.readthedocs.io/en/latest/charms.reactive.relations.html#charms.reactive.endpoints.Endpoint.all_departed_units>`
> collection: a list of all units that have departed. The list is persistent
> and mutable, so a handler can use this list to keep track of which departed
> units still have to be cleaned up. Each time a unit is cleaned up, the
> handler removes that unit from `all_departed_units`, and this removal will
> be persisted.
>
>
> An example: you need to run a command each time a unit departs the
> relation.
>
> @when('endpoint.{endpoint_name}.departed')
> def handle_departed_unit(self):
> for name, unit in self.departed_units.items():
> # run the command to remove `unit` from the cluster
> # ..
> self.departed_units.clear()
> clear_flag(self.expand_name('departed'))
>
>
> This is how the flags relate
>
> [image: Inline afbeelding 1]
>
> Basically, the "joined" flag represents the state of the relationship and
> will be automatically cleared when all units are gone. "changed" and
> "departed" represents relationship events and have to be cleared manually
> by the handler
>
> This is a good example of why we switched from "state" to "flag":
> 'changed' and 'departed' make no sense as a state, they are events that
> need to be handled.
>
>
>
> Regards
> Merlijn
>
>
> 2018-02-20 22:21 GMT+01:00 Cory Johns <cory.johns at canonical.com>:
>
>> Greetings,
>>
>> Today we released version 0.6.1 of charms.reactive.  The full changelog
>> can be found at https://charmsreactive.readthedocs.io/en/latest/changelog
>> .html with the changes from this release being:
>>
>> * Separate departed units from joined in Endpoint (#153)
>> * Add deprecated placeholder for RelationBase.from_state (#148)
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20180222/b4879533/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 100562 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/juju/attachments/20180222/b4879533/attachment.png>


More information about the Juju mailing list