Could someone double check this please
After upgrading from 1.20.12-trusty-amd64 to master (commit 2807fed7fad5619079c98ea105674d8a724d2e66), all unit logs continually spew errors similar to the following: // ~/.juju/local/log/unit-mysql-0.log 2014-11-26 09:09:07 ERROR juju.worker runner.go:219 exited uniter: failed to initialize uniter for unit-mysql-0: cannot initialize hook commands in 1.22-alpha1.1-trusty-amd64: symlink 1.22-alpha1.1-trusty-amd64/jujud 1.22-alpha1.1-trusty-amd64/action-fail: no such file or directory After upgrade, I am unable to destroy a service. Would someone be able to try the following on their box to confirm that I don't have something screwy on mine: # with old juju i.e. /usr/bin/juju juju switch local juju destroy-environment --force --yes local juju bootstrap juju deploy mysql juju deploy mediawiki juju add-relation mysql:db mediawiki:db # wait for env to be ready. Then with juju built from trunk: juju upgrade-juju --upload-tools juju destroy-service mediawiki If I run the upgrade again after I've issued the destroy-service command, the service then gets removed. I imagine the dying service is caught as the watcher has to reassess entities and states when it starts up after the upgrade. It's EOD here, I'll pick up on this in the morning. Thank you in advance. Jess -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: godeps heads up
PS kudos and thanks to Martin Hilton for the godeps fix. On 26 November 2014 at 14:32, roger peppe roger.pe...@canonical.com wrote: TL;DR go get -u launchpad.net/godeps I have just fixed a bug in godeps where it could omit some testing dependencies from its output. The specific issue was that if you did godeps $pkg/... and a package early in the list depended on one later in the list, it would ignore the testing dependencies of the latter. I have also changed the output of godeps for git output so that it also prints the date of the commit. This should make it easier to tell when an update to a dependencies.tsv file is moving dependencies forward or backwards in time. This latter change is backwardly compatible, but I recommend that people update their dependencies.tsv files to take advantage of it. Please let me know if you have any issues arising from the above changes. cheers, rog. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
juju stable 1.20.13 is released
juju-core 1.20.13 A new stable release of Juju, juju-core 1.20.13, is now available. This release replaces stable 1.20.12. Getting Juju juju-core 1.20.13 is available for utopic and backported to earlier series in the following PPA: https://launchpad.net/~juju/+archive/stable Notable Changes This releases addresses stability and performance issues. Resolved issues * 1.20.12 breaks neutron-gateway, since all interfaces are brought up Lp 1395081 Finally We encourage everyone to subscribe the mailing list at juju-...@lists.canonical.com, or join us on #juju-dev on freenode. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Proposal: feature flag implementation for Juju
+1 for feature flags in general and +1 for using environment variables
in upstart to get them to the servers agents.
I think it'd be nice to have an environment variable per flag, with a
common prefix JUJU_FEATURE_. That way, if you need to check one in a
package init(), you don't have to parse the whole list of flags to find
the one you care about -- or depend on a globally initialized parsing of
that list.
env config seems reasonable, but dealing with parsing, errors and then
making that config globally available at init seems complex and not
always feasible.
How about defining them free form in an env config field, which is
then used to emit the env vars as described above to the upstart config
during bootstrap?
-Casey
On 11/25/2014 10:16 PM, Ian Booth wrote:
I like feature flags so am +1 to the overall proposal. I also agree with the
approach to keep them immutable, given the stated goals and complexity
associated with making them not so.
I think the env variable implementation is ok too - this keeps everything very
loosely coupled and avoids polluting a juju environment with an extra config
attribute.
On 26/11/14 08:47, Tim Penhey wrote:
Hi all,
There are often times when we want to hook up features for testing that
we don't want exposed to the general user community.
In the past we have hooked things up in master, then when the release
branch is made, we have had to go and change things there. This is a
terrible way to do it.
Here is my proposal:
http://reviews.vapour.ws/r/531/diff/#
We have an environment variable called JUJU_FEATURE_FLAGS. It contains
comma delimited strings that are used as flags.
The value is read when the program initializes and is not mutable.
Simple checks can be used in the code:
if featureflag.Enabled(foo) {
// do foo like things
}
Thoughts and suggestions appreciated, but I don't want to have the
bike-shedding go on too long.
Tim
signature.asc
Description: OpenPGP digital signature
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
ISSUE with juju 1.21-beta3
During our team's testing with many upgrade scenarios we have found a problem with tools and the jujuc commands on upgrades from 1.20 to 1.21-beta3. We are investigating. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: ISSUE with juju 1.21-beta3
On 27/11/14 10:07, Tim Penhey wrote: During our team's testing with many upgrade scenarios we have found a problem with tools and the jujuc commands on upgrades from 1.20 to 1.21-beta3. We are investigating. Definitely a problem. Critical bug created: https://bugs.launchpad.net/juju-core/+bug/1396792 Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Also found all-machines.log issue with 1.21
The fix for this is merging into master and 1.21 now. The problem was that for local provider based environments, unit and machine agents weren't including the required namespace in their log message tags. rsyslogd on the server was expecting to see the namespace so it filtered out the unexpected messages. I think this regression was probably introduced when we started using a Go syslog client on non-state server machines instead of rsyslogd (so that we can have non-Linux machines). On 27 November 2014 at 14:23, Menno Smits menno.sm...@canonical.com wrote: On 27 November 2014 at 10:52, Tim Penhey tim.pen...@canonical.com wrote: https://bugs.launchpad.net/juju-core/+bug/1396796 Would love other people to check. I don't know if it happens on other providers, just using local right now. I would appreciate it if someone could confirm working or not working on EC2. I've checked on EC2 and the problem doesn't appear to happen there, both when upgrading or starting with fresh install. Seems like this is a local only issue. I've been digging in to this problem with the local provider but don't have an answer yet, just theories. - Menno -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
