Re: How to make juju aware of IP address changes?
On 5 December 2013 18:52, Mark Shuttleworth m...@ubuntu.com wrote: On 04/12/13 17:34, Peter Waller wrote: This situation is now resolved with thanks to Roger, Gustavo and others in real time. There is no way we could have resolved it ourselves since there was corruption of the juju database caused by running out of disk space, which was unfortunate. We as a team were not aware that it is necessary to keep a backup of the juju database. Thanks for letting us dive in on it together, Peter. Would it help if Juju could maintain an awareness of the disk situation and gracefully avoid making the problem worse (and avoid corruption) by going read-only when disk is low? That's an interesting idea. It would need careful thought though - how would we make the decision when the database is actually distributed over several machines? I believe that the corruption was caused by the fact that we were not making sure that mongo journal writes are synced to disk before returning from a database operation. If we can avoid corruption by enabling that safety mode, I think that would probably be preferable. The main problem in this case was that one problem caused a cascade of sub-problems (the above corruption occurring quite late in the chain). The principal issue was the fact that log files expanded incredibly rapidly. I think that there are a few things that could help here, most important points first: - We should limit agent restarting in some way (exponential backoff or retry limits or both) - We should rotate log files and compress old ones. - We should have kind of policy for expiring and deleting old log files. - We should have some way of garbage collecting the transaction log. We *could* consider disabling logging when the disk is tending towards full, but I suspect that could make a bad problem worse by losing any possibility of seeing what has actually been going on. An awareness of the disk situation could help towards deciding when some of the above actions might be triggered. cheers, rog. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
[ANN] charmworldlib 0.1.0 released
Hello all, I've released the first version of a Python Library designed to interact with data from charmworld (https://manage.jujucharms.com). Currently this library is used by charm-tools to interact with the available charms and bundles in the ecosystem. This isn't considered a stable API and methods may be changing in the near future. Until a 1.0 release, expect changes to the API. # Installing/Upgrading For Ubuntu users, add ppa:juju/stable if you haven't already and run the following sudo apt-get update sudo apt-get install python-charmworldlib For other users, charmworldlib is available on pypi https://pypi.python.org/pypi/charmworldlib/0.1.0 and via pip: pip install charmworldlib # Features At this time there are charm and bundle imports. charm provides a Charm class which models a Charm, and a Charms object to search and poll the API for charm related data. bundle provides a Bundles class and only a proof endpoint is exposed. More features will be published in the upcoming releases of charmworldlib. # Support Support for charmworldlib is available via bug reporting at https://bugs.launchpad.net/charmworldlib Thanks, Marco Ceppi -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: juju bootstrap fails in Azure (BadRequest - The affinity group name is empty or was not specified.)
Thanks. Filed a report at https://lists.ubuntu.com/archives/juju/2013-December/003323.html max -- max cantor Sent with Airmail On December 9, 2013 at 3:50:55 PM, Robbie Williamson (robbie.william...@canonical.com) wrote: Thanks for the report Max. Would it be possible for you to open a bug in Launchpad for this: https://bugs.launchpad.net/juju-core/+filebug Ask Ubuntu is great, but for issues like this, we can address and track it better via our bug tracking tool. Thanks, Robbie On 12/09/2013 04:37 PM, max cantor wrote: Commmand and results copied below. I'm aware of https://bugs.launchpad.net/juju-core/+bug/1236136 but this is a separate issue as I am using the West US region for everything. This occurs when trying to bootstrap from an Azure VM and from a standalone machine. Also, it seemed to come up in 1.16.3 too. Certificates have been uploaded per instructions. Also, this occurs if I open the --upload-tools argument. dm@prd-juju:~/development/docmunch/ops/juju/juju-config$ rm -f ~/.juju/environments/* juju bootstrap --show-log --upload-tools ... 2013-12-09 19:46:48 ERROR juju supercommand.go:282 POST request failed: BadRequest - The affinity group name is empty or was not specified. (http code 400: Bad Request) The full debug output is on the AU page: http://askubuntu.com/questions/388419/juju-bootstrap-fails-in-azure-badrequest-the-affinity-group-name-is-empty-or -- max cantor Sent with Airmail -- -Robbie Williamson Don't make me angry...you wouldn't like me when I'm angry -Bruce Banner -- 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: juju bootstrap fails in Azure (BadRequest - The affinity group name is empty or was not specified.)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-12-10 4:11, max cantor wrote: Thanks. Filed a report at https://lists.ubuntu.com/archives/juju/2013-December/003323.html max I think that was just a copypaste error, as that is a link to Robbie's email to you. I think you meant https://bugs.launchpad.net/bugs/1259350 Thanks for filing a bug report. John =:- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Cygwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKmxEwACgkQJdeBCYSNAANtcACeNM9zvTLcfI5gDECp9xiNohzL xBIAnjB8oyvWDBmEmzwplhCGHGxZToKn =JuD8 -END PGP SIGNATURE- -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Does juju work with a JavaScript-less mongodb?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ... Did you check the 'mgo' source as well? I thought I remember when you first connect it uses eval to get date stamps to check for clock skew. I think you might be thinking of the state/presence package there, which uses eval for pre-2.4 mongo to do that. I just remember seeing it, not where. :) John =:- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Cygwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKlsAwACgkQJdeBCYSNAAMlQwCgzAGxj5ZJg+M6WAHwFEkO/oao zjcAmweRtDt75EFtxvTln+gR8UrABfcC =6UrD -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Releasing stable, dev, and others
On Tue, Dec 10, 2013 at 5:16 AM, Curtis Hovey-Canonical cur...@canonical.com wrote: Gentlemen. Juju-core 1.16.5 has one bug preventing us from doing a release. CI has blessed lp:juju-core/1.16 r1998. Do we want to defer the destroy-machine --force bug? https://launchpad.net/juju-core/+milestone/1.16.5 Is there any reason not to backport the http close=True fix to stable? Surely this bug affects several customers. https://bugs.launchpad.net/juju-core/+bug/1239558 I have verified we can increment the dependent libs. The patch applies (with some corrections to dependencies.tsv). Juju-core 1.17.0 still has regressions. HP is very broken, AWS has intermittent bootstrap issues. Is it possible to focus effort on these bugs to get a blessed revision? We have a good revision from Nov 4 (2071) but I don't think devs want to release a version that old. https://launchpad.net/juju-core/+milestone/1.17.0 The HP one sounds not too difficult to fix. I'm looking into the other intermittent failures now. I just reproduced it on Azure, so hopefully I'll be able to get to the bottom of it now. These projects have never been released. I want to mark the bugs as Fix Released since users must be using branches to work with the code. I can create release tarballs if we think formal releases are demanded by users. https://bugs.launchpad.net/goyaml/+bugs?search=Searchfield.status=Fix+Committed https://bugs.launchpad.net/gomaasapi/+bugs?search=Searchfield.status=Fix+Committed https://bugs.launchpad.net/goose/+bugs?search=Searchfield.status=Fix+Committed GWACL has a release, I think we want to cut another release to make it's bugs Fix Released. Is anyone using the GWACL release? I suspect the branch is used like most go projects. https://bugs.launchpad.net/gwacl/+bugs?search=Searchfield.status=Fix+Committed -- 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 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
