Re: Please merge master into your feature branches

[Andrew Wilkins]

On Fri, Feb 19, 2016 at 11:46 AM Nate Finch 
wrote:

> So uh... how are we going to deliver patches to 1.25 if CI can't run it?
>

CI for 1.25 is unaffected. The CI scripts check the juju client version and
do things differently depending on that.

On Thu, Feb 18, 2016 at 9:48 PM Andrew Wilkins 
> wrote:
>
>> On Fri, Feb 19, 2016 at 10:03 AM Ian Booth 
>> wrote:
>>
>>> FYI for folks developing feature branches for juju-core.
>>>
>>> juju-core master has been updated to include the first round of
>>> functionality to
>>> improve the bootstrap experience. The consequence of this is that CI
>>> scripts
>>> needed to be updated to match. This means that any feature branch which
>>> has not
>>> had master commit 294388 or later merged in will not work with CI and so
>>> will
>>> not be blessed for release.
>>>
>>
>> Further to this, please see the draft 2.0 release notes for instructions:
>> http://paste.ubuntu.com/15127859/
>>
>> If there's anything you can't figure out from that and/or command help,
>> please let us know so we can fix the docs.
>>
>> Cheers,
>> Andrew
>>
>>
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Please merge master into your feature branches

[Nate Finch]

So uh... how are we going to deliver patches to 1.25 if CI can't run it?

On Thu, Feb 18, 2016 at 9:48 PM Andrew Wilkins 
wrote:

> On Fri, Feb 19, 2016 at 10:03 AM Ian Booth 
> wrote:
>
>> FYI for folks developing feature branches for juju-core.
>>
>> juju-core master has been updated to include the first round of
>> functionality to
>> improve the bootstrap experience. The consequence of this is that CI
>> scripts
>> needed to be updated to match. This means that any feature branch which
>> has not
>> had master commit 294388 or later merged in will not work with CI and so
>> will
>> not be blessed for release.
>>
>
> Further to this, please see the draft 2.0 release notes for instructions:
> http://paste.ubuntu.com/15127859/
>
> If there's anything you can't figure out from that and/or command help,
> please let us know so we can fix the docs.
>
> Cheers,
> Andrew
>
>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Please merge master into your feature branches

[Ian Booth]

FYI for folks developing feature branches for juju-core.

juju-core master has been updated to include the first round of functionality to
improve the bootstrap experience. The consequence of this is that CI scripts
needed to be updated to match. This means that any feature branch which has not
had master commit 294388 or later merged in will not work with CI and so will
not be blessed for release.



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

Re: EC2 VPC firewall rules

[Ian Booth]

Login was bumped to v3 to prevent accidental logins from older Juju clients
which may appear to connect successfully but then fail later depending on what
operations are performed.

It also allows the "this version is incompatible message". This was done for 1.x
clients logging into Juju 2.0 servers, but the other way around was missed out.
We'll fix that for beta2.

On 18/02/16 20:51, John Meinel wrote:
> Shouldn't we at least be giving a "juju 2.0 cannot operate with a juju 1.X
> API server, please install juju-1.25 if you want to use this system", or
> something along tohse lines. Admin(3).Login is not implemented sounds like
> a poor way for them to discover that.
> 
> John
> =:->
> 
> 
> On Thu, Feb 18, 2016 at 2:49 PM, John Meinel  wrote:
> 
>> Looks like the changes to Login broke compatibility. We are adding a Login
>> v3, but it looks like the new code will refuse to try to Login to v2. I'm a
>> bit surprised, but it means you'll need to bootstrap again if you want to
>> test it out with current trunk.
>>
>> John
>> =:->
>>
>>
>> On Thu, Feb 18, 2016 at 2:47 PM, Tom Barber 
>> wrote:
>>
>>> Hey Dimiter,
>>>
>>> Thanks for that. As am running trunk I wanted to make sure I was fully up
>>> to date before progressing further. I pulled trunk locally and ran juju
>>> upgrade-juju --upload-tools
>>>
>>> That gives me:
>>>
>>> WARNING no addresses found in space "default"
>>> WARNING using all API addresses (cannot pick by space "default"):
>>> [public:52.30.224.20 local-cloud:172.31.2.38]
>>> WARNING discarding API open error: no such request - method
>>> Admin(3).Login is not implemented (not implemented)
>>> ERROR no such request - method Admin(3).Login is not implemented (not
>>> implemented)
>>>
>>>
>>> I assume the ERROR portion is pretty critical. So here's a slightly off
>>> topic question, which I suspect has a very simple yes/no answer. Can I
>>> either a) force a bootstrapped environment upgrade b) manually upgrade an
>>> environment by passing the error but making the bootstrap node up to date
>>> c) export the existing nodes it manages and import them back into a new
>>> bootstrap node without having to recreate them as well?
>>>
>>> Thanks
>>>
>>> Tom
>>>
>>> --
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> 
>>> goal, but you can always help by sponsoring the project
>>> )
>>>
>>> On 18 February 2016 at 10:42, Dimiter Naydenov <
>>> dimiter.nayde...@canonical.com> wrote:
>>>
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 18.02.2016 12:01, Tom Barber wrote:
> Hello folks
>
> I'm not sure if my tinkering has broken something, the fact I'm
> running trunk has broken something or I just don't understand
> something.
>
> Until last week we've been running EC2 classic, but we have now
> switched to EC2-VPC and have launched a few machines.
>
> juju ssh to these machines works fine and I've been configuring
> them to suit our needs.
>
> Then I came to look at external access, `juju expose mysqldb` for
> example, I would then expect to be able to access it from the
> outside world, but can't unless go into my VPC settings and open
> the port in one of the juju security groups, at which point
> external access works fine.
>
> Am I missing something?
>
> Thanks
>
> Tom
>
>
 Hey Tom,

 What you're describing sounds like a bug, as "juju expose "
 should trigger the firewaller worker to open the ports the service has
 declared (with open-ports within the charm) using the security group
 assigned to the host machine for all units of that service.

 Have you changed the "firewall-mode" setting by any chance?
 Can you provide some logs from /var/log/juju/*.log on the bootstrap
 instance (machine 0)?

 Cheers,
 - --
 Dimiter Naydenov 
 Juju Core Sapphire team 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQEcBAEBAgAGBQJWxaAXAAoJENzxV2TbLzHwGgEIAIuj0sPzh7S/4jvTQ6aA/dwP
 i7WkSZ586JkNbEFeCBjDavO6oZFOwIAEW+EpGuy1C0O8BJr5Y2YJBMR96pdf3Rj/
 Y6xS4Byt0HrwCWixt7ut6zu7BsT+nv6YFO7fNQvNYLyroufzpqUKaALJp5xwedkJ
 JIx1iyLnAZ4ZC1/0VkoBM/UjbZN7xQIteNvChBCZSSk8RvbqXCKhbXZKuUKMAw5g
 R+D3wIwLEyZHb5SATcSSdE6nidv4A0F2waac1/3lOvFebeOsnapnRKkIDp3Y9v19
 /zDiDLWSJJvMDau8iIzSQ4STK/sLEmA78iRNkfDRWRifv0z1KkY6ppnhaS+jrj4=
 =kPA7
 -END PGP SIGNATURE-

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

>>>
>>>
>>> --
>>> Juju mailing list

Requesting membership to join the charmers group

[chris holcombe]

Hey Juju Charmers!

I believe at this point I'm ready to join the charmers group.

Thanks,
Chris

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

Charmers membership

[Chris MacNaughton]

I would like to request that I become a member of ~charmers.

I participate in the review queue as a community member already as well as 
assisting new users in #juju on freenode. I am responsible for changes to the 
storage related Open Stack charms already and have fixed critical bugs in 
charms.

Thanks!
Chris MacnNaughton


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

PostgreSQL charm move

[Stuart Bishop]

Hi.

The PostgreSQL charm that I maintain has moved to git, the Reactive
Framework, and a series independent spot in Launchpad.

The new home is https://launchpad.net/postgresql-charm.

Bug reports go to https://bugs.launchpad.net/postgresql-charm. I will
keep monitoring bugs in the charms/trusty/postgresql namespace for
now.

Latest tested, stable and deployable version is in the built branch at
git+ssh://git.launchpad.net/postgresql-charm:

mkdir trusty
git clone -b built \
https://git.launchpad.net/postgresql-charm trusty/postgresql
JUJU_REPOSITORY=. juju deploy local:postgresql

The main source layer is in the master branch at
git+ssh://git.launchpad.net/postgresql-charm. Merge proposals should
be made against this branch. This is the branch used to build the
deployable built branch.


-- 
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')

[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 distinction between `states`
> and `events`.* A state such as `package.installed` is a fact. It will
> stay true until something manually removes the state. `config.changed` is
> not a state but an event. An event is only relevant at a single point in
> time, after that timepoint, the event gets removed. `file_changed` and
> `config_changed` are events that are only relevant in a single point of
> time.
>
> The reason that the `config_changed` event is relevant during an entire
> hook run is because hooks do not run in "real external time" but in an
> external timepoint. When an outside event happens during a hook run, the
> events get queued, and the next event is handled after the hook run is
> complete. A simple example is the stop hook; this can be seen as a
> `stop.requested` event. When a `config-changed` hook is running and an
> administrator destroys the service, the `stop` hook will only run after the
> `config-changed` hook is complete.
>
> Some advantages of introducing the concept of events:
>
> - It will be a lot clearer for devs that events get removed after a
> certain period of time and that states stay in the knowledgebase. Currently
> certain layers remove certain states at the start of a hook run; I think
> this can become very confusing for devs.
>
> - It would give us a clear 'logic' that tells us how to implement things
> like the 'file_changed' decorator. There are currently some issues with
> this: https://github.com/juju-solutions/charms.reactive/issues/44
>
> - The connection between the reactive framework and the lifecycle(hooks)
> would be a lot clearer. Each hook is an external event; external events
> aren't processed in real-time; ...
>
> - This would pave the way for Charms to react to other events such as
> systemd dbus events as mgmt does:
> https://ttboj.wordpress.com/2016/01/18/next-generation-configuration-mgmt/.
> Imagine being able to run a hook when a systemd service crashes or when
> files change outside of a hook run!
>
>
> So, what do you think? This is hard to explain in a single email and I
> left a lot of the details out, so feel free to ask for more clarification!
>
>
>
> 2016-02-17 23:55 GMT+01:00 Matt Bruzek :
>
>> I hate to go against the love-in here. While I desperately want a
>> configuration changed feature for the reactive framework. I disagree with
>> the way it was implemented. I brought up issues with this implementation in
>> the pull request:  https://github.com/juju-solutions/layer-basic/pull/36
>>
>> It feels wrong to lump configuration change events in to states. There
>> 

Re: EC2 VPC firewall rules

[Tom Barber]

Yeah, just a brain fade, at least I helped discover the authentication
warning issue! ;)

Ta Chaps.

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 18 February 2016 at 12:48, Marco Ceppi  wrote:

> On Thu, Feb 18, 2016 at 7:05 AM Tom Barber 
> wrote:
>
>> https://bugs.launchpad.net/charms/+source/mysql/+bug/1248812 Clearly
>> not! Dunno what I was doing last time, local deployment or something. Fork
>> o'clock.
>>
>
> Local deployments don't have a firewaller which is probably what you saw.
> Not sure why MySQL doesn't have open-port but I've just patched this.
> There's work on a new layerized version of MySQL which will also address
> this.
>
> Marco
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: EC2 VPC firewall rules

[Marco Ceppi]

On Thu, Feb 18, 2016 at 7:05 AM Tom Barber  wrote:

> https://bugs.launchpad.net/charms/+source/mysql/+bug/1248812 Clearly not!
> Dunno what I was doing last time, local deployment or something. Fork
> o'clock.
>

Local deployments don't have a firewaller which is probably what you saw.
Not sure why MySQL doesn't have open-port but I've just patched this.
There's work on a new layerized version of MySQL which will also address
this.

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

Re: EC2 VPC firewall rules

[Andrew Wilkins]

On Thu, Feb 18, 2016 at 6:51 PM John Meinel  wrote:

> Shouldn't we at least be giving a "juju 2.0 cannot operate with a juju 1.X
> API server, please install juju-1.25 if you want to use this system", or
> something along tohse lines. Admin(3).Login is not implemented sounds like
> a poor way for them to discover that.
>

It's *meant* to be providing an informative message, but it looks like it's
not quite working. Relevant code:
https://github.com/juju/juju/blob/master/apiserver/root.go#L267


John
> =:->
>
>
> On Thu, Feb 18, 2016 at 2:49 PM, John Meinel 
> wrote:
>
>> Looks like the changes to Login broke compatibility. We are adding a
>> Login v3, but it looks like the new code will refuse to try to Login to v2.
>> I'm a bit surprised, but it means you'll need to bootstrap again if you
>> want to test it out with current trunk.
>>
>> John
>> =:->
>>
>>
>> On Thu, Feb 18, 2016 at 2:47 PM, Tom Barber 
>> wrote:
>>
>>> Hey Dimiter,
>>>
>>> Thanks for that. As am running trunk I wanted to make sure I was fully
>>> up to date before progressing further. I pulled trunk locally and ran juju
>>> upgrade-juju --upload-tools
>>>
>>> That gives me:
>>>
>>> WARNING no addresses found in space "default"
>>> WARNING using all API addresses (cannot pick by space "default"):
>>> [public:52.30.224.20 local-cloud:172.31.2.38]
>>> WARNING discarding API open error: no such request - method
>>> Admin(3).Login is not implemented (not implemented)
>>> ERROR no such request - method Admin(3).Login is not implemented (not
>>> implemented)
>>>
>>>
>>> I assume the ERROR portion is pretty critical. So here's a slightly off
>>> topic question, which I suspect has a very simple yes/no answer. Can I
>>> either a) force a bootstrapped environment upgrade b) manually upgrade an
>>> environment by passing the error but making the bootstrap node up to date
>>> c) export the existing nodes it manages and import them back into a new
>>> bootstrap node without having to recreate them as well?
>>>
>>> Thanks
>>>
>>> Tom
>>>
>>> --
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> 
>>> goal, but you can always help by sponsoring the project
>>> )
>>>
>>> On 18 February 2016 at 10:42, Dimiter Naydenov <
>>> dimiter.nayde...@canonical.com> wrote:
>>>
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 18.02.2016 12:01, Tom Barber wrote:
 > Hello folks
 >
 > I'm not sure if my tinkering has broken something, the fact I'm
 > running trunk has broken something or I just don't understand
 > something.
 >
 > Until last week we've been running EC2 classic, but we have now
 > switched to EC2-VPC and have launched a few machines.
 >
 > juju ssh to these machines works fine and I've been configuring
 > them to suit our needs.
 >
 > Then I came to look at external access, `juju expose mysqldb` for
 > example, I would then expect to be able to access it from the
 > outside world, but can't unless go into my VPC settings and open
 > the port in one of the juju security groups, at which point
 > external access works fine.
 >
 > Am I missing something?
 >
 > Thanks
 >
 > Tom
 >
 >
 Hey Tom,

 What you're describing sounds like a bug, as "juju expose "
 should trigger the firewaller worker to open the ports the service has
 declared (with open-ports within the charm) using the security group
 assigned to the host machine for all units of that service.

 Have you changed the "firewall-mode" setting by any chance?
 Can you provide some logs from /var/log/juju/*.log on the bootstrap
 instance (machine 0)?

 Cheers,
 - --
 Dimiter Naydenov 
 Juju Core Sapphire team 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQEcBAEBAgAGBQJWxaAXAAoJENzxV2TbLzHwGgEIAIuj0sPzh7S/4jvTQ6aA/dwP
 i7WkSZ586JkNbEFeCBjDavO6oZFOwIAEW+EpGuy1C0O8BJr5Y2YJBMR96pdf3Rj/
 Y6xS4Byt0HrwCWixt7ut6zu7BsT+nv6YFO7fNQvNYLyroufzpqUKaALJp5xwedkJ
 JIx1iyLnAZ4ZC1/0VkoBM/UjbZN7xQIteNvChBCZSSk8RvbqXCKhbXZKuUKMAw5g
 R+D3wIwLEyZHb5SATcSSdE6nidv4A0F2waac1/3lOvFebeOsnapnRKkIDp3Y9v19
 /zDiDLWSJJvMDau8iIzSQ4STK/sLEmA78iRNkfDRWRifv0z1KkY6ppnhaS+jrj4=
 =kPA7
 -END PGP SIGNATURE-

 --
 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
>>>
>>>
>>
>

Re: EC2 VPC firewall rules

[Tom Barber]

https://bugs.launchpad.net/charms/+source/mysql/+bug/1248812 Clearly not!
Dunno what I was doing last time, local deployment or something. Fork
o'clock.

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 18 February 2016 at 12:00, Tom Barber  wrote:

> Okay, maybe I'm having a senior moment. Can you not expose 3306 in the
> mysql charm to the outside world?
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 18 February 2016 at 11:28, Tom Barber  wrote:
>
>> Okay back to the EC2-VPC question.
>>
>> I have updated trunk and I have bootstrapped a new environment.
>>
>> juju service tells me that my mysql charm is running 2.0-beta1.1 and is
>> exposed.
>>
>> On the bootstrap node I see:
>>
>> https://gist.github.com/buggtb/6b10fa695ea150ea3489
>>
>> The actual box itself tells me 22 and 17070 are open for business. Again
>> though, if I add a firewall rule manually I can log straight in.
>>
>> Tom
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>> On 18 February 2016 at 10:42, Dimiter Naydenov <
>> dimiter.nayde...@canonical.com> wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> On 18.02.2016 12:01, Tom Barber wrote:
>>> > Hello folks
>>> >
>>> > I'm not sure if my tinkering has broken something, the fact I'm
>>> > running trunk has broken something or I just don't understand
>>> > something.
>>> >
>>> > Until last week we've been running EC2 classic, but we have now
>>> > switched to EC2-VPC and have launched a few machines.
>>> >
>>> > juju ssh to these machines works fine and I've been configuring
>>> > them to suit our needs.
>>> >
>>> > Then I came to look at external access, `juju expose mysqldb` for
>>> > example, I would then expect to be able to access it from the
>>> > outside world, but can't unless go into my VPC settings and open
>>> > the port in one of the juju security groups, at which point
>>> > external access works fine.
>>> >
>>> > Am I missing something?
>>> >
>>> > Thanks
>>> >
>>> > Tom
>>> >
>>> >
>>> Hey Tom,
>>>
>>> What you're describing sounds like a bug, as "juju expose "
>>> should trigger the firewaller worker to open the ports the service has
>>> declared (with open-ports within the charm) using the security group
>>> assigned to the host machine for all units of that service.
>>>
>>> Have you changed the "firewall-mode" setting by any chance?
>>> Can you provide some logs from /var/log/juju/*.log on the bootstrap
>>> instance (machine 0)?
>>>
>>> Cheers,
>>> - --
>>> Dimiter Naydenov 
>>> Juju Core Sapphire team 
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v1
>>>
>>> iQEcBAEBAgAGBQJWxaAXAAoJENzxV2TbLzHwGgEIAIuj0sPzh7S/4jvTQ6aA/dwP
>>> i7WkSZ586JkNbEFeCBjDavO6oZFOwIAEW+EpGuy1C0O8BJr5Y2YJBMR96pdf3Rj/
>>> Y6xS4Byt0HrwCWixt7ut6zu7BsT+nv6YFO7fNQvNYLyroufzpqUKaALJp5xwedkJ
>>> JIx1iyLnAZ4ZC1/0VkoBM/UjbZN7xQIteNvChBCZSSk8RvbqXCKhbXZKuUKMAw5g
>>> R+D3wIwLEyZHb5SATcSSdE6nidv4A0F2waac1/3lOvFebeOsnapnRKkIDp3Y9v19
>>> /zDiDLWSJJvMDau8iIzSQ4STK/sLEmA78iRNkfDRWRifv0z1KkY6ppnhaS+jrj4=
>>> =kPA7
>>> -END PGP SIGNATURE-
>>>
>>> --
>>> 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

Re: EC2 VPC firewall rules

[Tom Barber]

Okay, maybe I'm having a senior moment. Can you not expose 3306 in the
mysql charm to the outside world?

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 18 February 2016 at 11:28, Tom Barber  wrote:

> Okay back to the EC2-VPC question.
>
> I have updated trunk and I have bootstrapped a new environment.
>
> juju service tells me that my mysql charm is running 2.0-beta1.1 and is
> exposed.
>
> On the bootstrap node I see:
>
> https://gist.github.com/buggtb/6b10fa695ea150ea3489
>
> The actual box itself tells me 22 and 17070 are open for business. Again
> though, if I add a firewall rule manually I can log straight in.
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 18 February 2016 at 10:42, Dimiter Naydenov <
> dimiter.nayde...@canonical.com> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 18.02.2016 12:01, Tom Barber wrote:
>> > Hello folks
>> >
>> > I'm not sure if my tinkering has broken something, the fact I'm
>> > running trunk has broken something or I just don't understand
>> > something.
>> >
>> > Until last week we've been running EC2 classic, but we have now
>> > switched to EC2-VPC and have launched a few machines.
>> >
>> > juju ssh to these machines works fine and I've been configuring
>> > them to suit our needs.
>> >
>> > Then I came to look at external access, `juju expose mysqldb` for
>> > example, I would then expect to be able to access it from the
>> > outside world, but can't unless go into my VPC settings and open
>> > the port in one of the juju security groups, at which point
>> > external access works fine.
>> >
>> > Am I missing something?
>> >
>> > Thanks
>> >
>> > Tom
>> >
>> >
>> Hey Tom,
>>
>> What you're describing sounds like a bug, as "juju expose "
>> should trigger the firewaller worker to open the ports the service has
>> declared (with open-ports within the charm) using the security group
>> assigned to the host machine for all units of that service.
>>
>> Have you changed the "firewall-mode" setting by any chance?
>> Can you provide some logs from /var/log/juju/*.log on the bootstrap
>> instance (machine 0)?
>>
>> Cheers,
>> - --
>> Dimiter Naydenov 
>> Juju Core Sapphire team 
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJWxaAXAAoJENzxV2TbLzHwGgEIAIuj0sPzh7S/4jvTQ6aA/dwP
>> i7WkSZ586JkNbEFeCBjDavO6oZFOwIAEW+EpGuy1C0O8BJr5Y2YJBMR96pdf3Rj/
>> Y6xS4Byt0HrwCWixt7ut6zu7BsT+nv6YFO7fNQvNYLyroufzpqUKaALJp5xwedkJ
>> JIx1iyLnAZ4ZC1/0VkoBM/UjbZN7xQIteNvChBCZSSk8RvbqXCKhbXZKuUKMAw5g
>> R+D3wIwLEyZHb5SATcSSdE6nidv4A0F2waac1/3lOvFebeOsnapnRKkIDp3Y9v19
>> /zDiDLWSJJvMDau8iIzSQ4STK/sLEmA78iRNkfDRWRifv0z1KkY6ppnhaS+jrj4=
>> =kPA7
>> -END PGP SIGNATURE-
>>
>> --
>> 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

Re: EC2 VPC firewall rules

[Tom Barber]

Okay back to the EC2-VPC question.

I have updated trunk and I have bootstrapped a new environment.

juju service tells me that my mysql charm is running 2.0-beta1.1 and is
exposed.

On the bootstrap node I see:

https://gist.github.com/buggtb/6b10fa695ea150ea3489

The actual box itself tells me 22 and 17070 are open for business. Again
though, if I add a firewall rule manually I can log straight in.

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 18 February 2016 at 10:42, Dimiter Naydenov <
dimiter.nayde...@canonical.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 18.02.2016 12:01, Tom Barber wrote:
> > Hello folks
> >
> > I'm not sure if my tinkering has broken something, the fact I'm
> > running trunk has broken something or I just don't understand
> > something.
> >
> > Until last week we've been running EC2 classic, but we have now
> > switched to EC2-VPC and have launched a few machines.
> >
> > juju ssh to these machines works fine and I've been configuring
> > them to suit our needs.
> >
> > Then I came to look at external access, `juju expose mysqldb` for
> > example, I would then expect to be able to access it from the
> > outside world, but can't unless go into my VPC settings and open
> > the port in one of the juju security groups, at which point
> > external access works fine.
> >
> > Am I missing something?
> >
> > Thanks
> >
> > Tom
> >
> >
> Hey Tom,
>
> What you're describing sounds like a bug, as "juju expose "
> should trigger the firewaller worker to open the ports the service has
> declared (with open-ports within the charm) using the security group
> assigned to the host machine for all units of that service.
>
> Have you changed the "firewall-mode" setting by any chance?
> Can you provide some logs from /var/log/juju/*.log on the bootstrap
> instance (machine 0)?
>
> Cheers,
> - --
> Dimiter Naydenov 
> Juju Core Sapphire team 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJWxaAXAAoJENzxV2TbLzHwGgEIAIuj0sPzh7S/4jvTQ6aA/dwP
> i7WkSZ586JkNbEFeCBjDavO6oZFOwIAEW+EpGuy1C0O8BJr5Y2YJBMR96pdf3Rj/
> Y6xS4Byt0HrwCWixt7ut6zu7BsT+nv6YFO7fNQvNYLyroufzpqUKaALJp5xwedkJ
> JIx1iyLnAZ4ZC1/0VkoBM/UjbZN7xQIteNvChBCZSSk8RvbqXCKhbXZKuUKMAw5g
> R+D3wIwLEyZHb5SATcSSdE6nidv4A0F2waac1/3lOvFebeOsnapnRKkIDp3Y9v19
> /zDiDLWSJJvMDau8iIzSQ4STK/sLEmA78iRNkfDRWRifv0z1KkY6ppnhaS+jrj4=
> =kPA7
> -END PGP SIGNATURE-
>
> --
> 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

Re: EC2 VPC firewall rules

[Tom Barber]

Booo! Okay I'll tear it all down and start anew.

Thanks

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 18 February 2016 at 10:51, John Meinel  wrote:

> Shouldn't we at least be giving a "juju 2.0 cannot operate with a juju 1.X
> API server, please install juju-1.25 if you want to use this system", or
> something along tohse lines. Admin(3).Login is not implemented sounds like
> a poor way for them to discover that.
>
> John
> =:->
>
>
> On Thu, Feb 18, 2016 at 2:49 PM, John Meinel 
> wrote:
>
>> Looks like the changes to Login broke compatibility. We are adding a
>> Login v3, but it looks like the new code will refuse to try to Login to v2.
>> I'm a bit surprised, but it means you'll need to bootstrap again if you
>> want to test it out with current trunk.
>>
>> John
>> =:->
>>
>>
>> On Thu, Feb 18, 2016 at 2:47 PM, Tom Barber 
>> wrote:
>>
>>> Hey Dimiter,
>>>
>>> Thanks for that. As am running trunk I wanted to make sure I was fully
>>> up to date before progressing further. I pulled trunk locally and ran juju
>>> upgrade-juju --upload-tools
>>>
>>> That gives me:
>>>
>>> WARNING no addresses found in space "default"
>>> WARNING using all API addresses (cannot pick by space "default"):
>>> [public:52.30.224.20 local-cloud:172.31.2.38]
>>> WARNING discarding API open error: no such request - method
>>> Admin(3).Login is not implemented (not implemented)
>>> ERROR no such request - method Admin(3).Login is not implemented (not
>>> implemented)
>>>
>>>
>>> I assume the ERROR portion is pretty critical. So here's a slightly off
>>> topic question, which I suspect has a very simple yes/no answer. Can I
>>> either a) force a bootstrapped environment upgrade b) manually upgrade an
>>> environment by passing the error but making the bootstrap node up to date
>>> c) export the existing nodes it manages and import them back into a new
>>> bootstrap node without having to recreate them as well?
>>>
>>> Thanks
>>>
>>> Tom
>>>
>>> --
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> 
>>> goal, but you can always help by sponsoring the project
>>> )
>>>
>>> On 18 February 2016 at 10:42, Dimiter Naydenov <
>>> dimiter.nayde...@canonical.com> wrote:
>>>
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 18.02.2016 12:01, Tom Barber wrote:
 > Hello folks
 >
 > I'm not sure if my tinkering has broken something, the fact I'm
 > running trunk has broken something or I just don't understand
 > something.
 >
 > Until last week we've been running EC2 classic, but we have now
 > switched to EC2-VPC and have launched a few machines.
 >
 > juju ssh to these machines works fine and I've been configuring
 > them to suit our needs.
 >
 > Then I came to look at external access, `juju expose mysqldb` for
 > example, I would then expect to be able to access it from the
 > outside world, but can't unless go into my VPC settings and open
 > the port in one of the juju security groups, at which point
 > external access works fine.
 >
 > Am I missing something?
 >
 > Thanks
 >
 > Tom
 >
 >
 Hey Tom,

 What you're describing sounds like a bug, as "juju expose "
 should trigger the firewaller worker to open the ports the service has
 declared (with open-ports within the charm) using the security group
 assigned to the host machine for all units of that service.

 Have you changed the "firewall-mode" setting by any chance?
 Can you provide some logs from /var/log/juju/*.log on the bootstrap
 instance (machine 0)?

 Cheers,
 - --
 Dimiter Naydenov 
 Juju Core Sapphire team 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQEcBAEBAgAGBQJWxaAXAAoJENzxV2TbLzHwGgEIAIuj0sPzh7S/4jvTQ6aA/dwP
 i7WkSZ586JkNbEFeCBjDavO6oZFOwIAEW+EpGuy1C0O8BJr5Y2YJBMR96pdf3Rj/
 Y6xS4Byt0HrwCWixt7ut6zu7BsT+nv6YFO7fNQvNYLyroufzpqUKaALJp5xwedkJ
 JIx1iyLnAZ4ZC1/0VkoBM/UjbZN7xQIteNvChBCZSSk8RvbqXCKhbXZKuUKMAw5g
 R+D3wIwLEyZHb5SATcSSdE6nidv4A0F2waac1/3lOvFebeOsnapnRKkIDp3Y9v19
 /zDiDLWSJJvMDau8iIzSQ4STK/sLEmA78iRNkfDRWRifv0z1KkY6ppnhaS+jrj4=
 =kPA7
 -END PGP SIGNATURE-

 --
 Juju mailing list
 Juju@lists.ubuntu.com
 Modify settings or unsubscribe at:

Re: Dynamically registering reactive handlers at runtime

[Alex Kavanagh]

Hi Merlijn

On Thu, Feb 18, 2016 at 10:15 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

>
> Thank you for your response, we did not realize this was the case, this
> might come in handy!
>
> Now to get some clarification: If we have the following code:
>
> if some-condition:
> @when(...)
> def some_function(...):
> ...
>
> and `some-condition` changes after the initial registration of handlers.
> Will `some_function` be registered, or will this only happen during the
> next hook run?
>

A new process is invoked for each 'run' of a hook, and so from the
perspective of the Python script/program it is starting anew each time for
each hook invocation (i.e. there is no 'server' handling hooks).  Thus the
@when(...) are registered every time a hook is called.

So, if you register them dynamically, then they could be different during
each hook invocation.  Whether this is a good idea is debatable as the
hooks registered would be determined by the state of the system as a whole
which might make it tricky to debug, test, and reason about.


>
> The possible values for package-names are not known during build time. We
> do know that _all_ queued packages have to be installed. Would it be
> possible to have an `apt.installed.all` state?
>

Well, your own script sets the states, so yes; but I don't know enough
about your use case to advise on that - I was more commenting on what's
possible in Python.

Cheers
Alex.


-- 
Alex Kavanagh - Software Engineer
Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: EC2 VPC firewall rules

[John Meinel]

Looks like the changes to Login broke compatibility. We are adding a Login
v3, but it looks like the new code will refuse to try to Login to v2. I'm a
bit surprised, but it means you'll need to bootstrap again if you want to
test it out with current trunk.

John
=:->


On Thu, Feb 18, 2016 at 2:47 PM, Tom Barber  wrote:

> Hey Dimiter,
>
> Thanks for that. As am running trunk I wanted to make sure I was fully up
> to date before progressing further. I pulled trunk locally and ran juju
> upgrade-juju --upload-tools
>
> That gives me:
>
> WARNING no addresses found in space "default"
> WARNING using all API addresses (cannot pick by space "default"):
> [public:52.30.224.20 local-cloud:172.31.2.38]
> WARNING discarding API open error: no such request - method Admin(3).Login
> is not implemented (not implemented)
> ERROR no such request - method Admin(3).Login is not implemented (not
> implemented)
>
>
> I assume the ERROR portion is pretty critical. So here's a slightly off
> topic question, which I suspect has a very simple yes/no answer. Can I
> either a) force a bootstrapped environment upgrade b) manually upgrade an
> environment by passing the error but making the bootstrap node up to date
> c) export the existing nodes it manages and import them back into a new
> bootstrap node without having to recreate them as well?
>
> Thanks
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 18 February 2016 at 10:42, Dimiter Naydenov <
> dimiter.nayde...@canonical.com> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 18.02.2016 12:01, Tom Barber wrote:
>> > Hello folks
>> >
>> > I'm not sure if my tinkering has broken something, the fact I'm
>> > running trunk has broken something or I just don't understand
>> > something.
>> >
>> > Until last week we've been running EC2 classic, but we have now
>> > switched to EC2-VPC and have launched a few machines.
>> >
>> > juju ssh to these machines works fine and I've been configuring
>> > them to suit our needs.
>> >
>> > Then I came to look at external access, `juju expose mysqldb` for
>> > example, I would then expect to be able to access it from the
>> > outside world, but can't unless go into my VPC settings and open
>> > the port in one of the juju security groups, at which point
>> > external access works fine.
>> >
>> > Am I missing something?
>> >
>> > Thanks
>> >
>> > Tom
>> >
>> >
>> Hey Tom,
>>
>> What you're describing sounds like a bug, as "juju expose "
>> should trigger the firewaller worker to open the ports the service has
>> declared (with open-ports within the charm) using the security group
>> assigned to the host machine for all units of that service.
>>
>> Have you changed the "firewall-mode" setting by any chance?
>> Can you provide some logs from /var/log/juju/*.log on the bootstrap
>> instance (machine 0)?
>>
>> Cheers,
>> - --
>> Dimiter Naydenov 
>> Juju Core Sapphire team 
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJWxaAXAAoJENzxV2TbLzHwGgEIAIuj0sPzh7S/4jvTQ6aA/dwP
>> i7WkSZ586JkNbEFeCBjDavO6oZFOwIAEW+EpGuy1C0O8BJr5Y2YJBMR96pdf3Rj/
>> Y6xS4Byt0HrwCWixt7ut6zu7BsT+nv6YFO7fNQvNYLyroufzpqUKaALJp5xwedkJ
>> JIx1iyLnAZ4ZC1/0VkoBM/UjbZN7xQIteNvChBCZSSk8RvbqXCKhbXZKuUKMAw5g
>> R+D3wIwLEyZHb5SATcSSdE6nidv4A0F2waac1/3lOvFebeOsnapnRKkIDp3Y9v19
>> /zDiDLWSJJvMDau8iIzSQ4STK/sLEmA78iRNkfDRWRifv0z1KkY6ppnhaS+jrj4=
>> =kPA7
>> -END PGP SIGNATURE-
>>
>> --
>> 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
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: EC2 VPC firewall rules

[Dimiter Naydenov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 18.02.2016 12:01, Tom Barber wrote:
> Hello folks
> 
> I'm not sure if my tinkering has broken something, the fact I'm
> running trunk has broken something or I just don't understand
> something.
> 
> Until last week we've been running EC2 classic, but we have now
> switched to EC2-VPC and have launched a few machines.
> 
> juju ssh to these machines works fine and I've been configuring
> them to suit our needs.
> 
> Then I came to look at external access, `juju expose mysqldb` for 
> example, I would then expect to be able to access it from the
> outside world, but can't unless go into my VPC settings and open
> the port in one of the juju security groups, at which point
> external access works fine.
> 
> Am I missing something?
> 
> Thanks
> 
> Tom
> 
> 
Hey Tom,

What you're describing sounds like a bug, as "juju expose "
should trigger the firewaller worker to open the ports the service has
declared (with open-ports within the charm) using the security group
assigned to the host machine for all units of that service.

Have you changed the "firewall-mode" setting by any chance?
Can you provide some logs from /var/log/juju/*.log on the bootstrap
instance (machine 0)?

Cheers,
- -- 
Dimiter Naydenov 
Juju Core Sapphire team 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJWxaAXAAoJENzxV2TbLzHwGgEIAIuj0sPzh7S/4jvTQ6aA/dwP
i7WkSZ586JkNbEFeCBjDavO6oZFOwIAEW+EpGuy1C0O8BJr5Y2YJBMR96pdf3Rj/
Y6xS4Byt0HrwCWixt7ut6zu7BsT+nv6YFO7fNQvNYLyroufzpqUKaALJp5xwedkJ
JIx1iyLnAZ4ZC1/0VkoBM/UjbZN7xQIteNvChBCZSSk8RvbqXCKhbXZKuUKMAw5g
R+D3wIwLEyZHb5SATcSSdE6nidv4A0F2waac1/3lOvFebeOsnapnRKkIDp3Y9v19
/zDiDLWSJJvMDau8iIzSQ4STK/sLEmA78iRNkfDRWRifv0z1KkY6ppnhaS+jrj4=
=kPA7
-END PGP SIGNATURE-

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

EC2 VPC firewall rules

[Tom Barber]

Hello folks

I'm not sure if my tinkering has broken something, the fact I'm running
trunk has broken something or I just don't understand something.

Until last week we've been running EC2 classic, but we have now switched to
EC2-VPC and have launched a few machines.

juju ssh to these machines works fine and I've been configuring them to
suit our needs.

Then I came to look at external access, `juju expose mysqldb` for example,
I would then expect to be able to access it from the outside world, but
can't unless go into my VPC settings and open the port in one of the juju
security groups, at which point external access works fine.

Am I missing something?

Thanks

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

Re: Dynamically registering reactive handlers at runtime

[Alex Kavanagh]

On Thu, Feb 18, 2016 at 7:23 AM, Stuart Bishop 
wrote:

> On 12 February 2016 at 22:55, Merlijn Sebrechts
>  wrote:
> > Hi all
> >
> >
> > We have a layer that can install a number of different packages. It
> decides
> > at runtime which packages will be installed. This layer uses the `apt`
> layer
> > which sets a state `apt.installed.`.
> >
> > We want to react to this installed state, but we don't know what the
> > packagename will be beforehand. This gets decided at runtime. Therefore,
> we
> > can't put it in a @when() decorator.
> >
> > Is there a way to dynamically register handlers at runtime?
>

>From a Python perspective, there's nothing stopping you, at the top level
in the file, or in a function, doing:

if some-condition:
@when(...)
def some_function(...):
...

i.e. decorators don't have to be at the top level in a module/file - they
are essentially 'just' syntactic sugar for a function call on the defined
function.

@when(...)
def something():


is conceptually equivalent to:

def something():
...

when(...)(something)

However, I'd caution against dynamically defining the handlers, as it might
make the program/script less easy to reason about, test and debug.

I'm guessing that the possible values for packagename are known at build
time, so could you not just either list them all with their appropriate
handlers, or bundle them all into a single @when(...) if they share a
common handler?

e.g.

@when('apt.installed.packagename1')
def ...

@when('apt.installed.packagename2')
def ...

and/or

@when('apt.installed.packagename1', 'apt.installed.packagename2', ...)
def ...

Explicit tends to be more helpful than implicit.  Hope this is useful
and/or helpful!
Alex.

-- 
Alex Kavanagh - Software Engineer
Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju