[charms.reactive] http relation.available gets called on upgrade-charm hook, gives error.

[Merlijn Sebrechts]

Hi all


I have the following piece of code that reacts to the
httprelation.available hook (called rest2jfed in this case):


@when('rest2jfed.available')
def setup_rest2jfed(rest2jfed):
hostname = rest2jfed.host()
port = rest2jfed.port()
# Do some stuff with hostname and port
hookenv.status_set('active', 'Ready')


This piece of code gets called on the upgrade-charm hook. This throws an
error because there is not a relationship context.

  File "lib/charms/reactive/relations.py", line 88, in __accessor
return self.get_remote(field)
  File "lib/charms/reactive/relations.py", line 308, in get_remote
return self.conversation(scope).get_remote(key, default)
  File "lib/charms/reactive/relations.py", line 255, in conversation
raise ValueError('Unable to determine default scope: no current hook or
global scope')

Am I using this relation wrong or is this a bug?



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

Re: Juju-gui options: read-only and juju-gui-console-enabled

[Merlijn Sebrechts]

Hi Rick, thank you for this! I thought the console was a web-console where
you could execute juju commands. This would be a great feature, I think.

Kind regards
Merlijn

Op maandag 26 oktober 2015 heeft Rick Harding 
het volgende geschreven:
> Howdy Merlijn. The team will look into it. I note you filed the bug here:
https://bugs.launchpad.net/juju-gui/+bug/1509443
> The read-only isn't used much so we'll have test that out. The console
enabled is for the javascript console and debugging support. Were you
looking for that for some reason or were you thinking that 'console' was
something else?
> Rick
> On Sun, Oct 25, 2015 at 1:03 PM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:
>>
>> Hi
>>
>> The read-only and juju-gui-console-enabled options seem like interesting
and usefull options. However, I can't seem to get them to work. Are these
not implemented yet?
>>
>>
>> Kind regards
>> Merlijn Sebrechts
>> --
>> 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: How to make Juju High Availability work properly?

[曾建銘]

Hi Mark & Marco,

Really appreciate your help. I have already provide the logs to Marco.

Hope it could help you to enhance the Juju HA feature.

Sincerely yours,
Leon

On Sat, Oct 24, 2015 at 7:03 AM, Mark Shuttleworth  wrote:

> On 23/10/15 00:54, 曾建銘 wrote:
> > Was the juju doing something for fixing specific problem? I think that
> > service on failed node should only become lost and not interfere services
> > on workings nodes. But it didn't act as I expected.
> >
> > By the way, I used Juju to deploy OpenStack, so I deployed a lot of
> charms
> > on it. Is that matter?
>
> No, the scale of the model you're managing should not affect HA in any way.
>
> The team is trying to reproduce your situation by repeatedly causing
> failover, but I'm told has not seen anything like your symptoms. Can you
> provide copies of logs to Marco?
>
> Mark
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Missing contrib.amulet in charm-helpers-hooks

[James Beedy]

Openstack-Charmers,

I am hitting an error when shared-db-relation-changed executes, where it cannot 
create a logger due to 
https://bugs.launchpad.net/charms/+source/glance/+bug/1509540 
. I found the 
cause of this issue, and is such that contrib.openstack.amulet.utils.py tries 
to import ‘charmhelpers.contrib.amulet.utils.AmuletUtils’ and fails because it 
doesn’t exist, because it hasn’t been pinned in charm-helpers-hooks.yaml.

I have been under the impression (until now) that charm-helpers modules should 
not depend on other charm-helpers modules, until recently when a little bird 
hinted to me that exceptions are being made to this standard so that we can 
override some of the tooling to fit openstack use cases. In the case that this 
exception has been made, and this 
(http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/openstack/amulet/utils.py#L34
 
)
 is a legitimate import, it seems ‘contrib.amulet’  would need to be pinned in 
charm-helpers-hooks.yaml for any charm that pins "contrib.openstack|inc=*” or 
“contrib.openstack.amulet”. In the case that modifying charm-helpers-hooks.yaml 
to include ‘contrib.amulet’ is the correct modification to make, I have created 
MR's for each charm that needs these modifications. Also, I have synced 
charm-helpers and made MR’s on all charms (even those that don’t need 
‘contrib.amulet’ pinned) to ensure they all have consistent charm-helpers libs.

What I’m wondering is:

A. Is 
http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/openstack/amulet/utils.py#L34
 

 legitimate?
B. Is the fix, as well as the way I have applied it, what you would consider to 
be the correct modification, and procedure to be made to fix this issue?

Thanks in advance for your insight,

James


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

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

[Tim Penhey]

On 24/10/15 04:05, Aaron Bentley wrote:
> bzr has a similar feature, but the problem with such a feature is that
> it can break scripts that expect the normal behaviour.  That's why bzr
> provides a --no-aliases option, which all scripts calling bzr should use.
> 
> The same applies to Juju.  If "status" gets defaulted to "status
> --format=tabular", most of our test scripts will break.  This isn't
> likely to happen on our test machines, but could easily happen when
> devs run our test scripts.
> 
> Could you please provide a similar --no-aliases option for juju, so
> that we can ensure people don't break our scripts by specifying
> surprising defaults?

http://reviews.vapour.ws/r/2999/

done

Tim

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

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

[Tim Penhey]

On 24/10/15 00:40, Rick Harding wrote:
> 
> 
> On Fri, Oct 23, 2015 at 12:12 AM Tim Penhey  > wrote:
> 
> Hi folks,
> 
> Firstly, the ability to specify default flags for commands:
>   status = status --format=tabular
> 
> I could never remember the right environment variable to set to get
> tabular by default.
> 
> The second was to allow quicker iteration around playing with new CLI
> structure.  As most people are aware, the 2.0 CLI is going to be
> somewhat different to the current one, and I thought it would be good to
> provide a way in which we could "test drive" the new CLI with the
> existing codebase without having to actually code anything.
> 
> 
> This is very cool Tim. I would like to raise a word of caution though.
> When folks get aliasing too much to work around pain points of the
> experience it makes it easy to hide the pain and not raise it up and
> deal with it.  My one hesitation here is that we need to make sure that
> these are small and that if we find common ones that we bring them up as
> things that should be fixed in the cli vs "just use the following
> aliases" in reply to folks frustrations. 
> 
> In particular, with the 2.0 cli experiments, it'd be helpful if there
> was some method that everyone could be using a shared experience so that
> we were getting real testing of a common plan for a 2.0 cli vs everyone
> building their own 2.0 as they go. 
> 
> Not to be negative on the cool handy feature, but something to think
> about as folks go adding their aliases. 

I agree that we should take care when talking more about aliases.

If we find that there are a set that people generally like using, we
should consider making it more a core part of Juju, and not rely on aliases.

Aliases are useful for some people for some tasks. I don't think they
will be used by everyone, nor or are they supposed to be.

Tim


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

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

[Tim Penhey]

On 23/10/15 21:28, roger peppe wrote:
> On 23 October 2015 at 05:12, Tim Penhey  wrote:
>> Hi folks,
>>
>> I scratched a personal itch yesterday and added the ability for users to
>> specify their own aliases for juju commands.
>>
>> There are two primary use cases that I was trying to address.
>>
>> Firstly, the ability to specify default flags for commands:
>>   status = status --format=tabular
> 
> This sounds useful, thanks. Presumably additional arguments are
> just tacked onto the end?

No... not exactly, an infix replacement.

For example, lets say I had the above status alias. If I really wanted
json output I'd go:

  juju status --format=json

The alias mechanism turns this into:

 juju status --format=tabular --format=json

And the default flag behaviour is for the last to win, so format is set
to json.

>> I could never remember the right environment variable to set to get
>> tabular by default.
>>
>> The second was to allow quicker iteration around playing with new CLI
>> structure.  As most people are aware, the 2.0 CLI is going to be
>> somewhat different to the current one, and I thought it would be good to
>> provide a way in which we could "test drive" the new CLI with the
>> existing codebase without having to actually code anything.
> 
> Unless the new CLI is non-hierarchical I'm thinking that may
> not work unless you can specify multi-level aliases;
> For example:
> 
> model destroy = environment destroy
> 
> which might be a little harder.

Exactly. We tried with hierarchical sub-menus, but the experiment is
considered a successful way to not do it :-)

Juju 2.0 will transition back to a flat command namespace with a
predictable set of - commands along with another set that
make more sense by themselves, i.e. "deploy", "relate".

Tim

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

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

[Tim Penhey]

Hi Wayne,

While I can see your point of view, I do disagree.

While it may be of no benefit to you, it doesn't mean that others will
not find it useful.

I believe it is useful to have one format to specify aliases, one that
doesn't depend on the shell that you use.

The overhead in complexity isn't really that much, and with the
--no-alias option which is coming, it still provides a way to ensure
vanilla behaviour.


Tim

On 27/10/15 04:03, Wayne Witzel wrote:
> After looking at this and the code more, I find myself very against this
> feature. This adds code to core that is performing a tasks that most
> people already know is handled by their shell. Even our Windows users
> can install PowerShell and have aliases for commands. This adds no
> benefit to core, it adds more complexity, and attempts to perform a task
> that is already well handled by the users shell. If anything, this itch
> could be scratched by adding some contrib documentation about some of
> your favourite and/or most used aliases.
> 
> On Mon, Oct 26, 2015 at 10:51 AM, Wayne Witzel
> > wrote:
> 
> What is the advantage of this over using a standard alias in my
> shell profile?
> 
> On Fri, Oct 23, 2015 at 11:05 AM, Aaron Bentley
> >
> wrote:
> 
> bzr has a similar feature, but the problem with such a feature
> is that
> it can break scripts that expect the normal behaviour.  That's
> why bzr
> provides a --no-aliases option, which all scripts calling bzr
> should use.
> 
> The same applies to Juju.  If "status" gets defaulted to "status
> --format=tabular", most of our test scripts will break.  This isn't
> likely to happen on our test machines, but could easily happen when
> devs run our test scripts.
> 
> Could you please provide a similar --no-aliases option for juju, so
> that we can ensure people don't break our scripts by specifying
> surprising defaults?
> 
> Thanks,
> 
> Aaron
> 
> On 2015-10-23 12:12 AM, Tim Penhey wrote:
> > Hi folks,
> >
> > I scratched a personal itch yesterday and added the ability for
> > users to specify their own aliases for juju commands.
> >
> > There are two primary use cases that I was trying to address.
> >
> > Firstly, the ability to specify default flags for commands: status
> > = status --format=tabular
> >
> > I could never remember the right environment variable to set to
> > get tabular by default.
> >
> > The second was to allow quicker iteration around playing with new
> > CLI structure.  As most people are aware, the 2.0 CLI is going to
> > be somewhat different to the current one, and I thought it
> would be
> > good to provide a way in which we could "test drive" the new CLI
> > with the existing codebase without having to actually code
> > anything.
> >
> > The aliases files lives in JUJU_HOME, and is a simple text file.
> > Each non blank line that doesn't start with a '#' is considered to
> > be an alias. The format is expected to be:
> >
> >  =  [...]
> >
> > So we can do things like:
> >
> > # stat is like two whole letters shorter... stat = status
> > --format=tabular
> >
> > # list tests list-environments = system environments list-users =
> > user list
> >
> > and so on.
> >
> > Tim
> >
> 
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com 
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> 
> 
> 
> 
> -- 
> Wayne Witzel III
> wayne.wit...@canonical.com 
> 
> 
> 
> 
> -- 
> Wayne Witzel III
> wayne.wit...@canonical.com 
> 
> 


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

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

[Wayne Witzel]

What is the advantage of this over using a standard alias in my shell
profile?

On Fri, Oct 23, 2015 at 11:05 AM, Aaron Bentley  wrote:

> bzr has a similar feature, but the problem with such a feature is that
> it can break scripts that expect the normal behaviour.  That's why bzr
> provides a --no-aliases option, which all scripts calling bzr should use.
>
> The same applies to Juju.  If "status" gets defaulted to "status
> --format=tabular", most of our test scripts will break.  This isn't
> likely to happen on our test machines, but could easily happen when
> devs run our test scripts.
>
> Could you please provide a similar --no-aliases option for juju, so
> that we can ensure people don't break our scripts by specifying
> surprising defaults?
>
> Thanks,
>
> Aaron
>
> On 2015-10-23 12:12 AM, Tim Penhey wrote:
> > Hi folks,
> >
> > I scratched a personal itch yesterday and added the ability for
> > users to specify their own aliases for juju commands.
> >
> > There are two primary use cases that I was trying to address.
> >
> > Firstly, the ability to specify default flags for commands: status
> > = status --format=tabular
> >
> > I could never remember the right environment variable to set to
> > get tabular by default.
> >
> > The second was to allow quicker iteration around playing with new
> > CLI structure.  As most people are aware, the 2.0 CLI is going to
> > be somewhat different to the current one, and I thought it would be
> > good to provide a way in which we could "test drive" the new CLI
> > with the existing codebase without having to actually code
> > anything.
> >
> > The aliases files lives in JUJU_HOME, and is a simple text file.
> > Each non blank line that doesn't start with a '#' is considered to
> > be an alias. The format is expected to be:
> >
> >  =  [...]
> >
> > So we can do things like:
> >
> > # stat is like two whole letters shorter... stat = status
> > --format=tabular
> >
> > # list tests list-environments = system environments list-users =
> > user list
> >
> > and so on.
> >
> > Tim
> >
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>



-- 
Wayne Witzel III
wayne.wit...@canonical.com
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

[Wayne Witzel]

After looking at this and the code more, I find myself very against this
feature. This adds code to core that is performing a tasks that most people
already know is handled by their shell. Even our Windows users can install
PowerShell and have aliases for commands. This adds no benefit to core, it
adds more complexity, and attempts to perform a task that is already well
handled by the users shell. If anything, this itch could be scratched by
adding some contrib documentation about some of your favourite and/or most
used aliases.

On Mon, Oct 26, 2015 at 10:51 AM, Wayne Witzel 
wrote:

> What is the advantage of this over using a standard alias in my shell
> profile?
>
> On Fri, Oct 23, 2015 at 11:05 AM, Aaron Bentley <
> aaron.bent...@canonical.com> wrote:
>
>> bzr has a similar feature, but the problem with such a feature is that
>> it can break scripts that expect the normal behaviour.  That's why bzr
>> provides a --no-aliases option, which all scripts calling bzr should use.
>>
>> The same applies to Juju.  If "status" gets defaulted to "status
>> --format=tabular", most of our test scripts will break.  This isn't
>> likely to happen on our test machines, but could easily happen when
>> devs run our test scripts.
>>
>> Could you please provide a similar --no-aliases option for juju, so
>> that we can ensure people don't break our scripts by specifying
>> surprising defaults?
>>
>> Thanks,
>>
>> Aaron
>>
>> On 2015-10-23 12:12 AM, Tim Penhey wrote:
>> > Hi folks,
>> >
>> > I scratched a personal itch yesterday and added the ability for
>> > users to specify their own aliases for juju commands.
>> >
>> > There are two primary use cases that I was trying to address.
>> >
>> > Firstly, the ability to specify default flags for commands: status
>> > = status --format=tabular
>> >
>> > I could never remember the right environment variable to set to
>> > get tabular by default.
>> >
>> > The second was to allow quicker iteration around playing with new
>> > CLI structure.  As most people are aware, the 2.0 CLI is going to
>> > be somewhat different to the current one, and I thought it would be
>> > good to provide a way in which we could "test drive" the new CLI
>> > with the existing codebase without having to actually code
>> > anything.
>> >
>> > The aliases files lives in JUJU_HOME, and is a simple text file.
>> > Each non blank line that doesn't start with a '#' is considered to
>> > be an alias. The format is expected to be:
>> >
>> >  =  [...]
>> >
>> > So we can do things like:
>> >
>> > # stat is like two whole letters shorter... stat = status
>> > --format=tabular
>> >
>> > # list tests list-environments = system environments list-users =
>> > user list
>> >
>> > and so on.
>> >
>> > Tim
>> >
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
>
>
> --
> Wayne Witzel III
> wayne.wit...@canonical.com
>



-- 
Wayne Witzel III
wayne.wit...@canonical.com
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: How to make Juju High Availability work properly?

[Mark Ramm-Christensen (Canonical.com)]

Thanks for following up!

We will take a look at the logs and get back to you soon.

--Mark Ramm

On Mon, Oct 26, 2015 at 4:41 AM, 曾建銘  wrote:

> Hi Mark & Marco,
>
> Really appreciate your help. I have already provide the logs to Marco.
>
> Hope it could help you to enhance the Juju HA feature.
>
> Sincerely yours,
> Leon
>
> On Sat, Oct 24, 2015 at 7:03 AM, Mark Shuttleworth 
> wrote:
>
>> On 23/10/15 00:54, 曾建銘 wrote:
>> > Was the juju doing something for fixing specific problem? I think that
>> > service on failed node should only become lost and not interfere
>> services
>> > on workings nodes. But it didn't act as I expected.
>> >
>> > By the way, I used Juju to deploy OpenStack, so I deployed a lot of
>> charms
>> > on it. Is that matter?
>>
>> No, the scale of the model you're managing should not affect HA in any
>> way.
>>
>> The team is trying to reproduce your situation by repeatedly causing
>> failover, but I'm told has not seen anything like your symptoms. Can you
>> provide copies of logs to Marco?
>>
>> Mark
>>
>
>
> --
> 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 sessions for next week's Ubuntu summit

[Jorge O. Castro]

Hello everyone!

Ubuntu is having an online summit next week and I've scheduled some
sessions for us:

http://summit.ubuntu.com/uos-1511/track/cloud/

Basically Wednesday will be our heavy day, with a day's worth of
content, and then an office hours the day after to catch up any loose
ends.

All these sessions are free to attend and will be recorded, when I
have all the recordings I'll got ahead and announce their location
here. Thanks and hope to see you there!

-- 
Jorge Castro
Canonical Ltd.
http://jujucharms.com/ - Automate your Cloud Infrastructure

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

[ANN] charm-tools 1.8.0

[Marco Ceppi]

Hello everyone!

I'm happy to announce another charm-tools release today, this is the 1.8.0
which succeeds 1.7.1 as the latest release of charm-tools. As always, you
can verify the version you are running by executing: `charm version`

# Changes

ca0f40c [Benjamin Saller] fix issue with multiple includes of layer or
interface
951da9c [Benjamin Saller] help tests pass again
3830317 [Benjamin Saller] enable simple metics collections to help
visualize charm ecosystem
1fbb059 [Matt Bruzek] Updating readme with github and removing old info.
4a6bdf7 [Matt Bruzek] Replacing "sould" with "should".
8a236cb [Benjamin Saller] segregate deps by namespace (layer/interface)
cd66b45 [Benjamin Saller] reworked pypi installer (again). This does more
complex path mapping but properly gets /bin/* scripts and such
8aea18e [Benjamin Saller] attempt to clean up deprecation warning, make
delete_path safer
6fbb036 [Benjamin Saller] finish rename
a30876a [Benjamin Saller] rename composer to build
566b1e9 [Cory Johns] Move LPGitFetcher upstream and add missing rename
(fixes #14)
2a99239 [Cory Johns] Handle empty metadata.yaml (fixes #15)
bf563b9 [Marco Ceppi] Remove py3 testing
4d48eab [Marco Ceppi] Remove need to download deps from bzr archive
343555d [Marco Ceppi] Add support for travis ci
024852e [Marco Ceppi] Ignore pyc files
67983c4 [Marco Ceppi] converted bzrignore to gitignore

In this release compose, generate, and refresh were renamed to 'build' and
composer.yaml was renamed to layer.yaml. While we will maintain backwards
compat until 2.0, using these outdated terminologies will lead to problems
in the future.

# Install
Charm Tools is available to users either via the juju/stable PPA, Homebrew,
or pip

## PPA

sudo add-apt-repository ppa:juju/stable
sudo apt-get update
sudo apt-get install charm-tools

## Homebrew

brew install charm-tools

## PIP

pip install -U charm-tools

# Summary

We have completed our move to github, all issues and pull requests should
be made against https://github.com/juju/charm-tools going forward.

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