Re: What to do with precise charms?

2016-02-19 Thread Stuart Bishop 
On 20 February 2016 at 03:47, José Antonio Rey  wrote:
> Hello,
>
> In approximately two months, Xenial is going to be released. Once that
> happens, we are going to have three supported LTS releases: precise, trusty
> and xenial.
>
> I know that there is some people that have both precise and trusty charms.
> However, if they want to move their charms to xenial, they are going to have
> to maintain not two, but three charms. And if we want to have the latest in
> all charms, then features and software versions would have to be backported
> all the way to precise, which may complicate things a bit more.
>
> I'm wondering, would it be suitable for us to establish a process where a
> charm author decides to no longer maintain a charm in an old but supported
> release and just move that specific series charm to ~unmaintained-charms? I
> think it's better to start thinking on this now, before it gets too close to
> release time.
>
> Happy to hear all your comments/suggestions on this.

I already have charms with deprecated precise branches, used for some
very old legacy installs.

With the 2.0 release and charm store updates, I will also want to
deprecate the trusty branches in favor of a series-independent branch.
I've already started this, moving the PostgreSQL source layer to
launchpad.net/postgresql-charm.The trusty bzr branch will just be a
hindrance when it is no longer needed for ingestion into the charm
store.

It is my understanding that the charm store will accept the series
independent branch and produce cs:trusty/foo series dependent blobs
for older Juju clients. There is still an open bug about allowing Juju
1.25 to deploy series independent branches or local charms without
hacking (https://bugs.launchpad.net/juju-core/+bug/1545686, not a huge
issue since with a local branch you can easily hack metadata.yaml).

-- 
Stuart Bishop 

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

Re: What to do with precise charms?

2016-02-19 Thread Mark Shuttleworth 

The multiple-series-charm support has been added in Juju 2.0
specifically to enable upgrades of services in future. The idea is that
a charm supports a window of series, and operators can upgrade the
underlying hosts smoothly. We don't have quite all the pieces in place
yet but its close.

In general I would say move to charms that support trusty+xenial, or
just xenial.

Mark

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

Re: What to do with precise charms?

2016-02-19 Thread Matt Bruzek 
Hello Jose,

Thanks for bringing this topic up! You make a good point there are going to
be three supported LTS releases available to Juju. I do not think we will
ask any maintainer to support all three releases. Currently each charm
lives in its own release and I would expect the precise charm contains an
older version of a service. It does not make sense to me that someone would
try to port the latest version of a service to the precise (12.04) charm.
If a charm happens to work on multiple releases we are talking about adding
support for that in Juju 2.0.

Our current unmaintained process addresses when an author is not responding
or maintaining the charms. We should come up with a process for "active"
charm developers to deprecate their precise charms. If a charm
developer/maintainer wants to deprecate a charm, I have seen someone
authors replace the entire readme and metadata with a deprecation warning
pointing to the latest version of the charm and get that through the review
process.

Although I don't expect we will have to do this very frequently, we locked
charms to releases so charms would continue to work with the packages that
were available in that release of the operating system. I hope that precise
charms continue to work in precise, and if that is not the case create a
bug and the author can fix the failure or put a depreciated message in the
metadata and readme.

Did I address the question you were talking about? If not please give us
more details.

Thanks!

   - Matt Bruzek 

On Fri, Feb 19, 2016 at 2:47 PM, José Antonio Rey  wrote:

> Hello,
>
> In approximately two months, Xenial is going to be released. Once that
> happens, we are going to have three supported LTS releases: precise, trusty
> and xenial.
>
> I know that there is some people that have both precise and trusty charms.
> However, if they want to move their charms to xenial, they are going to
> have to maintain not two, but three charms. And if we want to have the
> latest in all charms, then features and software versions would have to be
> backported all the way to precise, which may complicate things a bit more.
>
> I'm wondering, would it be suitable for us to establish a process where a
> charm author decides to no longer maintain a charm in an old but supported
> release and just move that specific series charm to ~unmaintained-charms? I
> think it's better to start thinking on this now, before it gets too close
> to release time.
>
> Happy to hear all your comments/suggestions on this.
>
> --
> José Antonio Rey
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

What to do with precise charms?

2016-02-19 Thread José Antonio Rey 

Hello,

In approximately two months, Xenial is going to be released. Once that 
happens, we are going to have three supported LTS releases: precise, 
trusty and xenial.


I know that there is some people that have both precise and trusty 
charms. However, if they want to move their charms to xenial, they are 
going to have to maintain not two, but three charms. And if we want to 
have the latest in all charms, then features and software versions would 
have to be backported all the way to precise, which may complicate 
things a bit more.


I'm wondering, would it be suitable for us to establish a process where 
a charm author decides to no longer maintain a charm in an old but 
supported release and just move that specific series charm to 
~unmaintained-charms? I think it's better to start thinking on this now, 
before it gets too close to release time.


Happy to hear all your comments/suggestions on this.

--
José Antonio Rey

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

Migration of jenkins-charm to upstream repo

2016-02-19 Thread Jorge O. Castro 
Hi everyone,

Just a quick note that the Jenkins charm is now at
https://github.com/jenkinsci/jenkins-charm

Thanks to the Jenkins folks who worked with us to make this happen!
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: charmers + openstack-charmers application

2016-02-19 Thread Billy Olsen 
I'm not a Juju Charmer, but I am an OpenStack Charmer and Ryan's
contributions have been invaluable. A very big +1 from me.

On Fri, Feb 19, 2016 at 8:23 AM, José Antonio Rey  wrote:

> Hey Ryan,
>
> I'm glad to see your application! You've definitely made valuable
> contributions in the past months, and I'm very familiar with all the hard
> work you've put into the charm ecosystem.
>
> I'm more than happy to give you a +1 on my side. Thanks for all the work
> you do!
>
>
> On 02/19/2016 10:14 AM, Ryan Beisner wrote:
>
>> Happy Friday, charmers!
>>
>> Please consider my application for membership to ~charmers and an
>> ~openstack-charmers.
>>
>> Over the past two years, I've contributed to each of the 20+ OpenStack
>> charms (and jenkins, ubuntu, mysql, mongodb).  While most of my work has
>> been in the field of charm testing, I've done a load of reviews, bug
>> triage, bug fixes, charm and charm-helper contributions, partner and
>> feature integration and validation.
>>
>> As a ~charm-contributors member, I've watched the broader charm review
>> queue for the proposals where I have specific domain knowledge, and have
>> taken some of those reviews.
>>
>> One of my babies is the Ubuntu OpenStack Charm Integration test
>> automation system (aka UOSCI).  That system continuously gates our
>> Ubuntu OpenStack development activity, charm and package SRU and release
>> processes.  It has deployed and tested ~14,000+ OpenStack clouds in the
>> past ~1yr, plus all of the accompanying amulet, lint, mojo and unit tests.
>>
>> As Juju core approaches and reaches "proposed" in each dev cycle, we
>> flip some bits and hammer on the proposed Juju version in the UOSCI
>> automation as a pre-release cross-validation effort.  Same for MAAS.
>>
>> I've delivered and participated in remote and in-person customer demos
>> of our tool sets and charms, and have given UOS and Charmer Summit demos
>> and talks.  I've made a point over the past year or so to chip in on
>> AskUbuntu, generally with OpenStack-specific questions.
>>
>>
>> I am:
>>   - https://github.com/ryan-beisner
>>   - https://launchpad.net/~1chb1n
>>   - https://launchpad.net/~1chb1n/+karma
>>   - http://askubuntu.com/users/382225/beisner
>>
>> Bugs:
>>   - https://goo.gl/vUsGXN
>>
>> My alternate bot identities work while I sleep:
>>   - https://github.com/uoscibot
>>   - https://launchpad.net/~uosci-testing-bot
>>
>> Other points of interest:
>>   -
>> https://code.launchpad.net/~ost-maintainers/openstack-charm-testing/trunk
>>   -
>>
>> https://code.launchpad.net/~ost-maintainers/openstack-mojo-specs/mojo-openstack-specs
>>   - https://github.com/openstack-charmers
>>   -
>>
>> http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/files/head:/charmhelpers/contrib/openstack/amulet/
>>   -
>>
>> https://code.launchpad.net/~openstack-charmers/charms/trusty/ceilometer/next
>>   -
>>
>> https://code.launchpad.net/~openstack-charmers/charms/trusty/ceilometer-agent/next
>>   -
>> https://code.launchpad.net/~openstack-charmers/charms/trusty/ceph/next
>>   -
>> https://code.launchpad.net/~openstack-charmers/charms/trusty/ceph-osd/next
>>   -
>>
>> https://code.launchpad.net/~openstack-charmers/charms/trusty/ceph-radosgw/next
>>   -
>> https://code.launchpad.net/~openstack-charmers/charms/trusty/cinder/next
>>   -
>>
>> https://code.launchpad.net/~openstack-charmers/charms/trusty/cinder-ceph/next
>>   -
>> https://code.launchpad.net/~openstack-charmers/charms/trusty/glance/next
>>   -
>> https://code.launchpad.net/~openstack-charmers/charms/trusty/heat/next
>>   -
>> https://code.launchpad.net/~openstack-charmers/charms/trusty/keystone/next
>>   - https://code.launchpad.net/~openstack-charmers/charms/trusty/lxd/next
>>   -
>>
>> https://code.launchpad.net/~openstack-charmers/charms/trusty/neutron-api/next
>>   -
>>
>> https://code.launchpad.net/~openstack-charmers/charms/trusty/neutron-gateway/next
>>   -
>>
>> https://code.launchpad.net/~openstack-charmers/charms/trusty/neutron-openvswitch/next
>>   -
>>
>> https://code.launchpad.net/~openstack-charmers/charms/trusty/nova-cloud-controller/next
>>   -
>>
>> https://code.launchpad.net/~openstack-charmers/charms/trusty/nova-compute/next
>>   -
>>
>> https://code.launchpad.net/~openstack-charmers/charms/trusty/openstack-dashboard/next
>>   -
>>
>> https://code.launchpad.net/~openstack-charmers/charms/trusty/percona-cluster/next
>>   -
>>
>> https://code.launchpad.net/~openstack-charmers/charms/trusty/rabbitmq-server/next
>>   -
>>
>> https://code.launchpad.net/~openstack-charmers/charms/trusty/swift-proxy/next
>>   -
>>
>> https://code.launchpad.net/~openstack-charmers/charms/trusty/swift-storage/next
>>
>>
>> Thanks for all the great tools, and thank you for your consideration.
>>
>> Cheers & happy charming!
>>
>> Ryan Beisner
>>
>>
>>
>>
>
> --
> José Antonio Rey
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
>

Re: charmers + openstack-charmers application

2016-02-19 Thread José Antonio Rey 

Hey Ryan,

I'm glad to see your application! You've definitely made valuable 
contributions in the past months, and I'm very familiar with all the 
hard work you've put into the charm ecosystem.


I'm more than happy to give you a +1 on my side. Thanks for all the work 
you do!


On 02/19/2016 10:14 AM, Ryan Beisner wrote:

Happy Friday, charmers!

Please consider my application for membership to ~charmers and an
~openstack-charmers.

Over the past two years, I've contributed to each of the 20+ OpenStack
charms (and jenkins, ubuntu, mysql, mongodb).  While most of my work has
been in the field of charm testing, I've done a load of reviews, bug
triage, bug fixes, charm and charm-helper contributions, partner and
feature integration and validation.

As a ~charm-contributors member, I've watched the broader charm review
queue for the proposals where I have specific domain knowledge, and have
taken some of those reviews.

One of my babies is the Ubuntu OpenStack Charm Integration test
automation system (aka UOSCI).  That system continuously gates our
Ubuntu OpenStack development activity, charm and package SRU and release
processes.  It has deployed and tested ~14,000+ OpenStack clouds in the
past ~1yr, plus all of the accompanying amulet, lint, mojo and unit tests.

As Juju core approaches and reaches "proposed" in each dev cycle, we
flip some bits and hammer on the proposed Juju version in the UOSCI
automation as a pre-release cross-validation effort.  Same for MAAS.

I've delivered and participated in remote and in-person customer demos
of our tool sets and charms, and have given UOS and Charmer Summit demos
and talks.  I've made a point over the past year or so to chip in on
AskUbuntu, generally with OpenStack-specific questions.


I am:
  - https://github.com/ryan-beisner
  - https://launchpad.net/~1chb1n
  - https://launchpad.net/~1chb1n/+karma
  - http://askubuntu.com/users/382225/beisner

Bugs:
  - https://goo.gl/vUsGXN

My alternate bot identities work while I sleep:
  - https://github.com/uoscibot
  - https://launchpad.net/~uosci-testing-bot

Other points of interest:
  -
https://code.launchpad.net/~ost-maintainers/openstack-charm-testing/trunk
  -
https://code.launchpad.net/~ost-maintainers/openstack-mojo-specs/mojo-openstack-specs
  - https://github.com/openstack-charmers
  -
http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/files/head:/charmhelpers/contrib/openstack/amulet/
  -
https://code.launchpad.net/~openstack-charmers/charms/trusty/ceilometer/next
  -
https://code.launchpad.net/~openstack-charmers/charms/trusty/ceilometer-agent/next
  - https://code.launchpad.net/~openstack-charmers/charms/trusty/ceph/next
  -
https://code.launchpad.net/~openstack-charmers/charms/trusty/ceph-osd/next
  -
https://code.launchpad.net/~openstack-charmers/charms/trusty/ceph-radosgw/next
  - https://code.launchpad.net/~openstack-charmers/charms/trusty/cinder/next
  -
https://code.launchpad.net/~openstack-charmers/charms/trusty/cinder-ceph/next
  - https://code.launchpad.net/~openstack-charmers/charms/trusty/glance/next
  - https://code.launchpad.net/~openstack-charmers/charms/trusty/heat/next
  -
https://code.launchpad.net/~openstack-charmers/charms/trusty/keystone/next
  - https://code.launchpad.net/~openstack-charmers/charms/trusty/lxd/next
  -
https://code.launchpad.net/~openstack-charmers/charms/trusty/neutron-api/next
  -
https://code.launchpad.net/~openstack-charmers/charms/trusty/neutron-gateway/next
  -
https://code.launchpad.net/~openstack-charmers/charms/trusty/neutron-openvswitch/next
  -
https://code.launchpad.net/~openstack-charmers/charms/trusty/nova-cloud-controller/next
  -
https://code.launchpad.net/~openstack-charmers/charms/trusty/nova-compute/next
  -
https://code.launchpad.net/~openstack-charmers/charms/trusty/openstack-dashboard/next
  -
https://code.launchpad.net/~openstack-charmers/charms/trusty/percona-cluster/next
  -
https://code.launchpad.net/~openstack-charmers/charms/trusty/rabbitmq-server/next
  -
https://code.launchpad.net/~openstack-charmers/charms/trusty/swift-proxy/next
  -
https://code.launchpad.net/~openstack-charmers/charms/trusty/swift-storage/next


Thanks for all the great tools, and thank you for your consideration.

Cheers & happy charming!

Ryan Beisner






--
José Antonio Rey

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

charmers + openstack-charmers application

2016-02-19 Thread Ryan Beisner 
Happy Friday, charmers!

Please consider my application for membership to ~charmers and an
~openstack-charmers.

Over the past two years, I've contributed to each of the 20+ OpenStack
charms (and jenkins, ubuntu, mysql, mongodb).  While most of my work has
been in the field of charm testing, I've done a load of reviews, bug
triage, bug fixes, charm and charm-helper contributions, partner and
feature integration and validation.

As a ~charm-contributors member, I've watched the broader charm review
queue for the proposals where I have specific domain knowledge, and have
taken some of those reviews.

One of my babies is the Ubuntu OpenStack Charm Integration test automation
system (aka UOSCI).  That system continuously gates our Ubuntu OpenStack
development activity, charm and package SRU and release processes.  It has
deployed and tested ~14,000+ OpenStack clouds in the past ~1yr, plus all of
the accompanying amulet, lint, mojo and unit tests.

As Juju core approaches and reaches "proposed" in each dev cycle, we flip
some bits and hammer on the proposed Juju version in the UOSCI automation
as a pre-release cross-validation effort.  Same for MAAS.

I've delivered and participated in remote and in-person customer demos of
our tool sets and charms, and have given UOS and Charmer Summit demos and
talks.  I've made a point over the past year or so to chip in on AskUbuntu,
generally with OpenStack-specific questions.


I am:
 - https://github.com/ryan-beisner
 - https://launchpad.net/~1chb1n
 - https://launchpad.net/~1chb1n/+karma
 - http://askubuntu.com/users/382225/beisner

Bugs:
 - https://goo.gl/vUsGXN

My alternate bot identities work while I sleep:
 - https://github.com/uoscibot
 - https://launchpad.net/~uosci-testing-bot

Other points of interest:
 - https://code.launchpad.net/~ost-maintainers/openstack-charm-testing/trunk
 -
https://code.launchpad.net/~ost-maintainers/openstack-mojo-specs/mojo-openstack-specs
 - https://github.com/openstack-charmers
 -
http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/files/head:/charmhelpers/contrib/openstack/amulet/
 -
https://code.launchpad.net/~openstack-charmers/charms/trusty/ceilometer/next
 -
https://code.launchpad.net/~openstack-charmers/charms/trusty/ceilometer-agent/next
 - https://code.launchpad.net/~openstack-charmers/charms/trusty/ceph/next
 -
https://code.launchpad.net/~openstack-charmers/charms/trusty/ceph-osd/next
 -
https://code.launchpad.net/~openstack-charmers/charms/trusty/ceph-radosgw/next
 - https://code.launchpad.net/~openstack-charmers/charms/trusty/cinder/next
 -
https://code.launchpad.net/~openstack-charmers/charms/trusty/cinder-ceph/next
 - https://code.launchpad.net/~openstack-charmers/charms/trusty/glance/next
 - https://code.launchpad.net/~openstack-charmers/charms/trusty/heat/next
 -
https://code.launchpad.net/~openstack-charmers/charms/trusty/keystone/next
 - https://code.launchpad.net/~openstack-charmers/charms/trusty/lxd/next
 -
https://code.launchpad.net/~openstack-charmers/charms/trusty/neutron-api/next
 -
https://code.launchpad.net/~openstack-charmers/charms/trusty/neutron-gateway/next
 -
https://code.launchpad.net/~openstack-charmers/charms/trusty/neutron-openvswitch/next
 -
https://code.launchpad.net/~openstack-charmers/charms/trusty/nova-cloud-controller/next
 -
https://code.launchpad.net/~openstack-charmers/charms/trusty/nova-compute/next
 -
https://code.launchpad.net/~openstack-charmers/charms/trusty/openstack-dashboard/next
 -
https://code.launchpad.net/~openstack-charmers/charms/trusty/percona-cluster/next
 -
https://code.launchpad.net/~openstack-charmers/charms/trusty/rabbitmq-server/next
 -
https://code.launchpad.net/~openstack-charmers/charms/trusty/swift-proxy/next
 -
https://code.launchpad.net/~openstack-charmers/charms/trusty/swift-storage/next


Thanks for all the great tools, and thank you for your consideration.

Cheers & happy charming!

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

Migration of OpenStack Charm development to OpenStack git/gerrit

2016-02-19 Thread James Page 
Hi All

As you may or may not be aware, the OpenStack team have been working
towards migration of the development process around the OpenStack charms to
the OpenStack project.

This means we will be moving away from current the bzr/launchpad workflow
to a git/gerrit workflow inline with most other OpenStack projects.


Bugs will still be managed on launchpad - this just relates to VCS and
associated review process.

Please take time to read the upstream development documentation prior to
the switch over; there are some steps you will need to take to be able to
work with the new tools and workflow including signing up for membership of
the OpenStack Foundation and getting things set-up in gerrit:

 http://docs.openstack.org/infra/manual/developers.html


The scope of the migration can been seen on the github mirror of the
current bzr branches:

 https://github.com/openstack-charmers

In order to de-risk the migration and allow time to migrate all associated
tooling and configurations (such as mojo specs, bundles, amulet tests etc…)
to use git, we’ll be putting in place a mirror process which will sync the
charms once in their new home on git back to the current set of branches in
launchpad; This means that everything that works today should continue to
work!

Once we’ve completed the switch over, lint and unit tests will be executed
on OpenStack infrastructure and amulet tests will continue to be executed
within the OSCI lab at Canonical.

We will be altering the gating process slightly - initially we’ll run a
subset of amulet tests to provide immediate feedback to the
contributor/reviewers; the full set of amulet tests will be executed once a
reviewer has +2’ed the review prior to final landing.

Code will be automatically landed by the OpenStack development process - no
need to complete manual merges any longer!


We’ll still be maintaining separate development and stable charms - you’ll
find the development charm in the master branch in the git repositories,
and the stable charm in the stable branch.

All of this will be documented here:


https://github.com/openstack-charmers/openstack-community/blob/master/README.dev-charms.md

The current target for switch over is Monday the 29th February.

Regards

James

pp OpenStack Engineering team
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: @when('config.changed')

2016-02-19 Thread Stuart Bishop 
On 19 February 2016 at 16:32, Merlijn Sebrechts
 wrote:

> I completely agree with you on point two. The semantics I'm trying to get at
> for point one are a bit different. Events are information that is relevant
> for a single point in time, not until the information is processed. Events
> can be processed by multiple handlers or by none, and in both cases they
> become irrelevant after the single point in time.

> So what I'm getting at is this:
>
>  - Handlers with event decorators may only be queued immediately after the
> event has fired
>  - Events do not get retested in the queue
>  - States work as they do now

Apart from a file changing, what 'events' happen in the middle of a
hook that shouldn't remain set for the remainder of the hook? I can't
come up with any valid use cases, so maybe this all becomes a case of
fixing @when_file_changed rather than adding new stuff.

That said, if there are valid use cases, perhaps an @after decorator.
It would work like @when, except it would remain active until the
handler has been run. ie. @when('foo') might get dequeued if the 'foo'
state is removed, but the @after('foo') would remain on the queue even
if the 'foo' state is removed. If a handler was decorated by both
@after('foo') and @when('bar'), it could get queued when 'bar' is set
even if 'foo' has since been removed. It seems easy enough to
implement (just a new decorator - no need to change the reactor), and
the same approach could be used to implement a fixed
@when_file_changed.

(You could even implement @after in your charm or in a layer)

-- 
Stuart Bishop 

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

Re: @when('config.changed')

2016-02-19 Thread Merlijn Sebrechts 
Hi Ben


I completely agree with you on point two. The semantics I'm trying to get
at for point one are a bit different. Events are information that is
relevant for a single point in time, not until the information is
processed. *Events can be processed by multiple handlers or by none, and in
both cases they become irrelevant after the single point in time.*

Take the 'file_changed' event for example. A great use for this is to
restart a service when a file changes. Take the following code:

@file_changed('xyz')
@when(service.started)
def restart():
...

If the service is started at the time the 'file_changed' event fires, this
handler should be queued. While the handler is queued, only the state
should be retested, not the event. If the service stops while this handler
is queued, the handler should be dropped from the queue. Multiple handlers
can react to this event, or none, but in all cases, the event should become
inactive after the initial queuing of handlers (the single point in time).
If the `file_changed` event fires and the service is not started, this
handler should not be queued. If the service starts after the event fires,
this handler should not get executed.

So what I'm getting at is this:

 - Handlers with event decorators may only be queued immediately after the
event has fired
 - Events do not get retested in the queue
 - States work as they do now

One of the problems with 'Information that is relevant till processed.' is
that it is almost impossible for the framework to know when an event is
'processed'. Because of this, the current implementation of `file_changed`
is buggy .
Moreover, it is common for events to not get processed at all. For example
when the file changes while the service is stopped.

I do see the importance of this being fault-tolerant. The reactive
framework is currently not fault tolerant
 and can has
different behavior in case of failure depending on whether a handler is
internal or external. One of the ways we could achieve some level of
fault-tolerant events is by remembering both the queue and the states when
a handler fails. Even without events, *I think remembering the queue on
failure is a good thing to do. I think it would enable a powerful debugging
workflow.*



PS: I'm interested to hear more about making applications model aware!

2016-02-18 18:42 GMT+01:00 Benjamin Saller :

> I really appreciate this kind of thinking, looking for root causes is the
> hallmark of better systems design. That said I'd suggest the difference
> between _event_ and _state_ as you describe them are really only a usage
> convention around the same abstraction.
>
> The semantics you seem to be pointing towards are:
>
>  1. Information that is relevant till processed.
>   2. Information that acts as a fact, persistent knowledge of the
> system.
>
> Point two is how you see states today. Point two states are only
> persistent facts until something changes that makes us re-evaluate them,
> this how ever is also true of point 1. In the case of point 1 processed
> means the state indicated by the system has been included into the
> applications model of the world and no longer needs to be considered. In
> examples like that we set the state and clear it when the expected changes
> have been applied. The lifetime of the state doesn't change its
> abstraction.
>
> Another way of look at these two things with an eye towards unifying them
> in our understanding is to think about how they are handled in the event of
> failure. From programmer error to random entropy (sun spots) when the
> execution stops the "event" or "state" must still be handled in a
> subsequent invocation for the unit to be in a proper state. This alone
> blurs the line between your two ideas. States try to make "Fire and forget"
> work even in the case of failure by saying that code paths impacted by this
> state should continue to trigger until the charm indicates otherwise
> (ending in a later success state).
>
>
> -Ben
>
> PS. As far as treating the reactive system like a daemon and having the
> ability to connect to external event sources, that is interesting and syncs
> well with something I am currently working on, but does so by making
> applications model aware rather than by trying to make the charms of today
> more deeply integrated into the applications they manage.
>
>
> On Thu, Feb 18, 2016 at 2:06 AM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> I sort of agree that it feels wrong to lump configuration change events
>> into states. That said, adding another primitive doesn't seem like a good
>> idea. The primitive doesn't nearly cover all cases. I think the problem
>> with `x.changed` states is just a symptom, and we should address the root
>> cause, not the symptoms.
>>
>> *The root cause seems to me that there is no