Re: Backwards incompatible change to config.changed states

Office Hours will indeed be May 13th this time around, I'll send out a separate EU-friendly time. Merlijn, if you have a specific timeslot in mind just send me a mail offlist and we'll put it where it's most convenient. On Mon, May 2, 2016 at 5:32 PM, Marco Ceppi

Re: Backwards incompatible change to config.changed states

I'll have to check with Jorge Castro, but I imagine either the 13th or 27th of this month. I'll confirm and this will likely be a "Europe" friendly time. Marco On Mon, May 2, 2016 at 5:19 PM Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > Great suggestion, Marco! When would the next

Re: Backwards incompatible change to config.changed states

Great suggestion, Marco! When would the next office hour be? 2016-05-02 23:13 GMT+02:00 Marco Ceppi : > Might I suggest we do a hangout on air so we can record the discussion > while skipping the back and forth on the list? Possibly during an office > hour? > > Also,

Re: Backwards incompatible change to config.changed states

Might I suggest we do a hangout on air so we can record the discussion while skipping the back and forth on the list? Possibly during an office hour? Also, I'm not sure the decision is final and I certainly appreciate your feedback and welcome the continued discussion so we can reach a consensus!

Re: Backwards incompatible change to config.changed states

Merlijn, Apologies for the delayed reply. I realized that I had typed this up but forgotten to actually send it. You're right that there are still cases where the hook-persistent nature of the config.changed states continue to cause problems. However, after some discussion with Ben, I actually

Re: Backwards incompatible change to config.changed states

I'd ask Cory to explore Merlijn's suggestions more deeply before we add another state. Mark On 25/04/16 02:11, James Beedy wrote: > I think this is an excellent idea! The the initial setting of the > config.changed hook has caused contention in charm design and > implementation for me. Not

Re: Backwards incompatible change to config.changed states

On 23 April 2016 at 04:02, Cory Johns wrote: > Is anyone depending on the current behavior? Are there any objections to > this change? I can argue both designs, but think that the most useful one is what you are proposing (config.changed not being set in the first

Re: Backwards incompatible change to config.changed states

I think this is an excellent idea! The the initial setting of the config.changed hook has caused contention in charm design and implementation for me. Not having to account for the config.changed hooks firing, when logically it seems that one shouldn't have to (e.g. no configs have changed yet),

Re: Backwards incompatible change to config.changed states

Hi Cory I think this is another symptom of the deeper issue that the reactive framework treats events like states. 'config.changed' is an event. The following code is something that intuitively seems correct. We want to reinstall when the config has changed while the service is installed.

Re: Backwards incompatible change to config.changed states

We can skip the new state if no one is depending on or finds the existing behavior useful (I suspect that may be true). On Fri, Apr 22, 2016 at 5:37 PM, Mark Shuttleworth wrote: > > I would strongly prefer not to add states lightly. Can we take some time > to see if this is

Re: Backwards incompatible change to config.changed states

I would strongly prefer not to add states lightly. Can we take some time to see if this is avoidable? Mark On 22/04/16 16:02, Cory Johns wrote: > I have proposed https://github.com/juju-solutions/layer-basic/pull/61 as a > slight change to how the config.changed states from the basic layer

Backwards incompatible change to config.changed states

I have proposed https://github.com/juju-solutions/layer-basic/pull/61 as a slight change to how the config.changed states from the basic layer work. Currently, the changed states are set during the first hook invocation, under the assumption that the values were "changed" from "nothing" (not being