charms.reactive 0.6.1

Discussion:

Cory Johns

2018-02-20 21:21:30 UTC

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)

Merlijn Sebrechts

2018-02-22 08:56:37 UTC

Permalink

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

Post by Cory Johns
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
* Separate departed units from joined in Endpoint (#153)
* Add deprecated placeholder for RelationBase.from_state (#148)
--
Juju mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
an/listinfo/juju

Dmitrii Shcherbakov

2018-02-22 10:16:21 UTC

Permalink

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 <

Post by Merlijn Sebrechts
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')
# 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
'changed' and 'departed' make no sense as a state, they are events that
need to be handled.
Regards
Merlijn

--
Juju mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/
mailman/listinfo/juju