Re: JUJU_UNIT_NAME no longer set in env

[Ian Booth]

FWIW, Juju itself still sets JUJU_UNIT_NAME

https://github.com/juju/juju/blob/develop/worker/uniter/runner/context/context.go#L582

On 23/05/17 05:59, James Beedy wrote:
> Juju 2.1.2
> 
> I'm getting this "JUJU_UNIT_NAME not in env" error on legacy-non-reactive
> xenial charm using service_name() from hookenv.
> 
> http://paste.ubuntu.com/24626263/
> 
> Did we remove this?
> 
> ~James
> 
> 
> 

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

GUI Props

[James Beedy]

The latest Juju GUI release is a huge step in the right direction! Amongst
the great improvements, the account page is really the start to something
great! Massive props and many thanks to all who have put in hard work and
long hours to bring the GUI to where it is today.

Looking forward, I'm wondering if the account page would be a good place to
manage ssh keys too?

Either way, nice work here!
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

JUJU_UNIT_NAME no longer set in env

[James Beedy]

Juju 2.1.2

I'm getting this "JUJU_UNIT_NAME not in env" error on legacy-non-reactive
xenial charm using service_name() from hookenv.

http://paste.ubuntu.com/24626263/

Did we remove this?

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

Re: Python-Django

[James Beedy]

The python-Django charm is largely outdated in many respects. I have been 
meaning to do a deep dive on it and turn it into something usable (there have 
been a few attempts at this over the years we can also look at). I can apply 
some of the goodies I've developed for my rails-layer in the Django charm too, 
see https://github.com/jamesbeedy/layer-rails-base.

@Lonroth I'll create a new layer for Django and share it when I get something 
up there. Should be sometime this week.

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

Re: PROPOSAL: stop recording 'executing update-status hook'

[Alex Kavanagh]

>From a 'principle of least surprise', I think that this proposal is
probably a bad idea.  The main driver is to (I guess) reduce the volume of
'chat' between the controller and 100's or 1000's of charms, and the effect
this has on the status log.  However, my 'guess' is also probably wrong as
it would continue to live in the debug log, which implies it is still being
sent/received.

I think it would be 'odd' for a status to be running, but not show up in
the status or status log - this would be unexpected.

My counter proposal is to have a toggle to disable 'update status' on a
model and/or application level, and/or have the ability to reduce the
frequency of the updates.

However, the downside of reducing/eliminating update-status is that (I
suspect) several charms rely on it to recover from errors (particularly)
racy ones.  Perhaps, this can be offset (during install) by usage of 'juju
run ...' and the fixing the charms with the bugs?

Another 'worry' is that if update-status is not reflected in 'juju-status'
will the workload status be updated (i.e. showing problems, fixing
problems, etc.)?

Alex.

On Mon, May 22, 2017 at 9:56 AM, Stuart Bishop 
wrote:

> On 22 May 2017 at 14:36, Tim Penhey  wrote:
> > On 20/05/17 19:48, Merlijn Sebrechts wrote:
> >>
> >> On May 20, 2017 09:05, "John Meinel"  >> > wrote:
> >>
> >> I would actually prefer if it shows up in 'juju status' but that we
> >> suppress it from 'juju status-log' by default.
> >>
> >>
> >> This is still very strange behavior. Why should this be default? Just
> pipe
> >> the output of juju status through grep and exclude update-status if
> that is
> >> really what you want.
> >>
> >> However, I would even argue that this isn't what you want in most
> >> use-cases.  "update-status" isn't seen as a special hook in
> charms.reactive.
> >> Anything can happen in that hook if the conditions are right. Ignoring
> >> update-status will have unforeseen consequences...
> >
> >
> > Hmm... there are (at least) two problems here.
> >
> > Firstly, update-status *should* be a special case hook, and it shouldn't
> > take long.
> >
> > The purpose of the update-status hook was to provide a regular beat for
> the
> > charm to report on the workload status. Really it shouldn't be doing
> other
> > things.
> >
> > The fact that it is a periodic execution rather than being executed in
> > response to model changes is the reason it isn't fitting so well into the
> > regular status and status history updates.
> >
> > The changes to the workload status would still be shown in the history of
> > the workload status, and the workload status is shown in the status
> output.
> >
> > One way to limit the execution of the update-status hook call would be to
> > put a hard timeout on it enforced by the agent.
> >
> > Thoughts?
>
> Unfortunately update-status got wired into charms.reactive like all
> the other standard hooks, and just means 'do whatever still needs to
> be done'. I think its too late to add timeouts or restrictions. But I
> do think special casing it in the status history is needed. Anything
> important will still end up in there due to workload status changes.
>
> --
> Stuart Bishop 
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>



-- 
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: PROPOSAL: stop recording 'executing update-status hook'

[Stuart Bishop]

On 22 May 2017 at 14:36, Tim Penhey  wrote:
> On 20/05/17 19:48, Merlijn Sebrechts wrote:
>>
>> On May 20, 2017 09:05, "John Meinel" > > wrote:
>>
>> I would actually prefer if it shows up in 'juju status' but that we
>> suppress it from 'juju status-log' by default.
>>
>>
>> This is still very strange behavior. Why should this be default? Just pipe
>> the output of juju status through grep and exclude update-status if that is
>> really what you want.
>>
>> However, I would even argue that this isn't what you want in most
>> use-cases.  "update-status" isn't seen as a special hook in charms.reactive.
>> Anything can happen in that hook if the conditions are right. Ignoring
>> update-status will have unforeseen consequences...
>
>
> Hmm... there are (at least) two problems here.
>
> Firstly, update-status *should* be a special case hook, and it shouldn't
> take long.
>
> The purpose of the update-status hook was to provide a regular beat for the
> charm to report on the workload status. Really it shouldn't be doing other
> things.
>
> The fact that it is a periodic execution rather than being executed in
> response to model changes is the reason it isn't fitting so well into the
> regular status and status history updates.
>
> The changes to the workload status would still be shown in the history of
> the workload status, and the workload status is shown in the status output.
>
> One way to limit the execution of the update-status hook call would be to
> put a hard timeout on it enforced by the agent.
>
> Thoughts?

Unfortunately update-status got wired into charms.reactive like all
the other standard hooks, and just means 'do whatever still needs to
be done'. I think its too late to add timeouts or restrictions. But I
do think special casing it in the status history is needed. Anything
important will still end up in there due to workload status changes.

-- 
Stuart Bishop 

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

Re: django charm broken or am I just doing it wrong?

[Erik Lönroth]

Hello Tim!

Thanx for interacting on the subject.

Would you be able to assist me in be able to deploy my website/django with
juju and/or improve the docs for the charm?

I am not an expert but love to help.

/Erik

Den 22 maj 2017 9:15 fm skrev "Tim Penhey" :

> Hmm.. I kinda do, but haven't touched it for a long time.
>
> I also use the subordinate charm method of delivering the webapp to the
> charm.
>
> I found that to use the charm properly you had to have the settings for
> the django project be a directory rather than a simple .py file.
>
> Tim
>
> On 22/05/17 04:15, John Meinel wrote:
>
>> I believe Tim Penhey makes active use of the python-django charm, but
>> it's possible he uses it in a different fashion.
>>
>> John
>> =:->
>>
>> On May 21, 2017 14:25, "Erik Lönroth" > erik.lonr...@gmail.com>> wrote:
>>
>> Hello!
>>
>> I'm trying out the django charm to deploy a django website I was
>> going to try to create with juju.
>>
>> * I followed the instructions here:
>> https://jujucharms.com/python-django/
>> 
>>
>> * My website repo is here: https://github.com/erik78se/dsite
>> 
>>
>> It has installed the website from github but there is an error:
>>
>> unit-dsite-1: 12:22:13 INFO unit.dsite/1.pgsql-relation-changed 0
>> upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>> unit-dsite-1: 12:22:14 DEBUG unit.dsite/1.juju-log pgsql:2: found
>> django admin: /usr/bin/django-admin
>> unit-dsite-1: 12:22:14 DEBUG unit.dsite/1.juju-log pgsql:2:
>> PYTHONPATH=/srv/dsite/../ /usr/bin/django-admin syncdb --noinput
>> --settings=dsite.settings
>> unit-dsite-1: 12:22:14 ERROR unit.dsite/1.juju-log pgsql:2:
>> status=1, output=Traceback (most recent call last):
>>File "/usr/bin/django-admin", line 5, in 
>>  management.execute_from_command_line()
>>File
>> "/usr/lib/python2.7/dist-packages/django/core/management/__
>> init__.py",
>> line 399, in execute_from_command_line
>>  utility.execute()
>>File
>> "/usr/lib/python2.7/dist-packages/django/core/management/__
>> init__.py",
>> line 392, in execute
>>  self.fetch_command(subcommand).run_from_argv(self.argv)
>>File
>> "/usr/lib/python2.7/dist-packages/django/core/management/__
>> init__.py",
>> line 261, in fetch_command
>>  commands = get_commands()
>>File
>> "/usr/lib/python2.7/dist-packages/django/core/management/__
>> init__.py",
>> line 107, in get_commands
>>  apps = settings.INSTALLED_APPS
>>File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py",
>> line 54, in __getattr__
>>  self._setup(name)
>>File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py",
>> line 49, in _setup
>>  self._wrapped = Settings(settings_module)
>>File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py",
>> line 132, in __init__
>>  % (self.SETTINGS_MODULE, e)
>> ImportError: Could not import settings 'dsite.settings' (Is it on
>> sys.path? Is there an import error in the settings file?): No module
>> named dsite.settings
>>
>> unit-dsite-1: 12:22:14 ERROR juju.worker.uniter.operation hook
>> "pgsql-relation-changed" failed: exit status 1
>> unit-dsite-1: 12:22:14 INFO juju.worker.uniter awaiting error
>> resolution for "relation-changed" hook
>>
>> As I'm not sure if I'm doing anything wrong or the charm is broken,
>> I wonder what your suggestion is in how to resolve this issue or if
>> I'm just doing it wrong.
>>
>> /Erik Lönroth
>>
>> --
>> 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: PROPOSAL: stop recording 'executing update-status hook'

[Tim Penhey]

On 20/05/17 19:48, Merlijn Sebrechts wrote:
On May 20, 2017 09:05, "John Meinel" > wrote:


I would actually prefer if it shows up in 'juju status' but that we
suppress it from 'juju status-log' by default.


This is still very strange behavior. Why should this be default? Just 
pipe the output of juju status through grep and exclude update-status if 
that is really what you want.


However, I would even argue that this isn't what you want in most 
use-cases.  "update-status" isn't seen as a special hook in 
charms.reactive. Anything can happen in that hook if the conditions are 
right. Ignoring update-status will have unforeseen consequences...


Hmm... there are (at least) two problems here.

Firstly, update-status *should* be a special case hook, and it shouldn't 
take long.


The purpose of the update-status hook was to provide a regular beat for 
the charm to report on the workload status. Really it shouldn't be doing 
other things.


The fact that it is a periodic execution rather than being executed in 
response to model changes is the reason it isn't fitting so well into 
the regular status and status history updates.


The changes to the workload status would still be shown in the history 
of the workload status, and the workload status is shown in the status 
output.


One way to limit the execution of the update-status hook call would be 
to put a hard timeout on it enforced by the agent.


Thoughts?

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

Re: PROPOSAL: stop recording 'executing update-status hook'

[Tim Penhey]

On 19/05/17 19:21, roger peppe wrote:

On 19 May 2017 at 03:13, Tim Penhey  wrote:

Hi folks,

Currently juju will update the status of any hook execution for any unit to
show that it is busy doing things. This was all well and good until we do
things based on time.

Every five minutes (or so) each unit will have the update-status hook
executed to allow the unit to set or update the workload status based on
what is currently going on with that unit.

Since all hook executions are stored, this means that the show-status-log
will show the unit jumping from executing update-status to ready and back
every five minutes.

The proposal is to special case the update-status hook and show in status
(or the status-log) that the hook is being executed. debug-log will continue
to show the hook executing if you are looking.


Presumably you mean *not* show in status here?


Yes. Sorry.

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

Re: django charm broken or am I just doing it wrong?

[Tim Penhey]

Hmm.. I kinda do, but haven't touched it for a long time.

I also use the subordinate charm method of delivering the webapp to the 
charm.


I found that to use the charm properly you had to have the settings for 
the django project be a directory rather than a simple .py file.


Tim

On 22/05/17 04:15, John Meinel wrote:
I believe Tim Penhey makes active use of the python-django charm, but 
it's possible he uses it in a different fashion.


John
=:->

On May 21, 2017 14:25, "Erik Lönroth" > wrote:


Hello!

I'm trying out the django charm to deploy a django website I was
going to try to create with juju.

* I followed the instructions here:
https://jujucharms.com/python-django/


* My website repo is here: https://github.com/erik78se/dsite


It has installed the website from github but there is an error:

unit-dsite-1: 12:22:13 INFO unit.dsite/1.pgsql-relation-changed 0
upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
unit-dsite-1: 12:22:14 DEBUG unit.dsite/1.juju-log pgsql:2: found
django admin: /usr/bin/django-admin
unit-dsite-1: 12:22:14 DEBUG unit.dsite/1.juju-log pgsql:2:
PYTHONPATH=/srv/dsite/../ /usr/bin/django-admin syncdb --noinput
--settings=dsite.settings
unit-dsite-1: 12:22:14 ERROR unit.dsite/1.juju-log pgsql:2:
status=1, output=Traceback (most recent call last):
   File "/usr/bin/django-admin", line 5, in 
 management.execute_from_command_line()
   File
"/usr/lib/python2.7/dist-packages/django/core/management/__init__.py",
line 399, in execute_from_command_line
 utility.execute()
   File
"/usr/lib/python2.7/dist-packages/django/core/management/__init__.py",
line 392, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File
"/usr/lib/python2.7/dist-packages/django/core/management/__init__.py",
line 261, in fetch_command
 commands = get_commands()
   File
"/usr/lib/python2.7/dist-packages/django/core/management/__init__.py",
line 107, in get_commands
 apps = settings.INSTALLED_APPS
   File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py",
line 54, in __getattr__
 self._setup(name)
   File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py",
line 49, in _setup
 self._wrapped = Settings(settings_module)
   File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py",
line 132, in __init__
 % (self.SETTINGS_MODULE, e)
ImportError: Could not import settings 'dsite.settings' (Is it on
sys.path? Is there an import error in the settings file?): No module
named dsite.settings

unit-dsite-1: 12:22:14 ERROR juju.worker.uniter.operation hook
"pgsql-relation-changed" failed: exit status 1
unit-dsite-1: 12:22:14 INFO juju.worker.uniter awaiting error
resolution for "relation-changed" hook

As I'm not sure if I'm doing anything wrong or the charm is broken,
I wonder what your suggestion is in how to resolve this issue or if
I'm just doing it wrong.

/Erik Lönroth

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