[Review Queue] ForgeRock OpenAM OpenDJ, and Wildfly (MP)
Today I did a follow-up to Tim's review of the ForgeRock charms for OpenAM and OpenDJ [1]. I noted two items that need to be improved: required config options causing error state instead of simply blocking, and better handling of the requirement of a full domain name as opposed to an IP address. I also reviewed (and approved) a merge proposal to the WildFly charm [2] to fix an error when a relation to the mysql charm is removed and then re-added. [1]: https://bugs.launchpad.net/charms/+bug/1384290 [2]: https://launchpad.net/~jhasaurabh/charms/precise/wildfly/trunk/+merge/237591 -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Another ~charmers application! - Chris Glass
Hi, Any news? It's been a month now, and I see other applications from the same time frame went through. What's wrong? - Chris On Tue, Sep 30, 2014 at 8:47 PM, Charles Butler charles.but...@canonical.com wrote: Greetings Chris, as you have sealed a solid 2 +1's from the ~charmers team we will be in touch shortly to schedule your ~charmer induction covering responsibilities and expectations. Congratulations and welcome aboard! All the best, Charles On Thu, Sep 25, 2014 at 1:51 AM, Chris Glass chris.gl...@canonical.com wrote: Hi all, It's my turn to apply for ~charmers membership. I have been using juju since the pyjuju days, mostly professionally but also for my personal use. Most of my contributions to the charm ecosystem stem from my current work position as a software engineer for Canonical, as part of the Landscape team: 1. Contributing to our own landscape and landscape-client charms (I am a member of ~landscape-charmers) 2. Heavy contributions to the storage subordinate (refactoring and extra features). 3. Working with OpenStack charms daily, and as such had the opportunity to find, trace and fix a variety of bugs in them. (I'm a member of ~openstack-charmers). 4. charm-helpers is of particular interest to me, and I have undertaken to explore, tidy and refactor that code, since it appears to have grown organically in the past, and accumulated a bit of technical debt. From the personal use side, I'm also the author of the ubuntu-mirror charm announced a few days ago, that I use to deploy and maintain an official ubuntu archives mirror. As most programmers I have a few other projects up my sleeve, but all of them might not become public before a bit more time. Outside of charming I'm an Ubuntu member and contributor, dad of one, and world traveler. Python has been my tool of choice these last few years, and before joining Canonical I've used puppet, vCenter Orchestrator, chef, and crowbar quite extensively. The last few items should give a hint as to where my previous professional positions were held :) Thanks for your consideration, time and awesome work, Best, - Chris -- 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: reviewboard - most recent diff by default?
On Mon, Oct 27, 2014 at 9:05 PM, Jesse Meek jesse.m...@canonical.com wrote: Is possible and preferable to show the most recent diff by default? If you mean instead of showing the reviews page by default, ReviewBoard doesn't support that out of the box. Certainly we could customize RB to do so, and for all I know it would be easy. -eric -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: per-database mongodump
On Mon, Oct 27, 2014 at 9:26 PM, John Meinel j...@arbash-meinel.com wrote: What are the tables we're wanting to filter? (charm storage because of its size?) The presence DB and a new one for backups. We actually do want to back up the blobstore DB (charms/tools). Certainly 3 and 4 aren't reasonable if the point is to avoid having 4GB of charm data in the backup. Yeah, I'd rather avoid that if possible. It would also make the restore situation messier. We should be able to avoid including unnecessary (even invalid) data from the backup archive. If we went with (1) for consistency sake, we should really go back to stop the db, dump to a backup. Yep. Alternatively we could lock the databases. Either way it would mean juju would be unresponsive during backup. I suppose when we have a replicaset we could take one member offline to make the backup, but I'd rather avoid that sort of complication. It is also sensitive to us adding a collection and forgetting to include it in the dump. (since it is a whitelist, right?) I've already implemented option 1 (http://reviews.vapour.ws/r/268/). The patch actually uses a blacklist, taking advantage of mgo.Session.DatabaseNames(). I'd really like (2) as a blacklist option, but I don't know how hard that is to do, and how much we expend to dump GB of charm data just to filter them out again. mongodump actually dumps each database to its own directory. If necessary, the trick would be to hack the dumped oplog to remove references to the ignored databases. I just need to verify that mongorestore --oplogReplay will be happy with that, or even if mongorestore offers us any other route. I'll be taking some time today to look into it. Thanks for the feedback. After hearing your thoughts and taking another look with fresh eyes, option 2 seems much more feasible and palatable. My only concern is that it relies on what amount to implementation details of mongodump (and mongorestore). -eric John =:- On Tue, Oct 28, 2014 at 3:07 AM, Eric Snow eric.s...@canonical.com wrote: For backup we currently call mongodump with the --oplog option. This dumps all databases at the same moment in time, which gives us assurances about the consistency of each database. However, we want to exclude some databases. Unfortunately --oplog is not compatible with the --db option. I'm looking for options here. I'm already considering, but am not satisfied with, the following: 1. (mongodump --db ...) Forgo the moment-in-time guarantee of --oplog (seems risky). 2. (mongodump --oplog ...) Manually remove the undesired databases from the dumped data (possible? risky!). 3. (mongodump --oplog ...) Skip the undesired databases when calling mongorestore (possible?). 4. (mongodump --oplog ...) Clear the undesired databases after calling mongorestore. The problem with 3 and 4 is that the backup archive will contain a bunch of erroneous data (the dumps of the databases we want to ignore). -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
how to update dependencies.tsv
We have a few windows dependencies that are not (and in some cases can not be) imported for the linux build. Luckily, the windows dependencies are a strict super set of the linux dependencies, so we can still use godeps to create dependencies.tsv, just by setting GOOS first, thusly (from the root of github.com/juju/juju): GOOS=windows godeps -t ./... dependencies.tsv Please use this command line when updating dependencies.tsv so that is keeps a standard format which will minimize conflicts in the file. -Nate -- 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 update dependencies.tsv
can we please just have make dependencies.tsv do the right thing so we don't have to remember which set of flags and env vars we need to use this time? I'm also not 100% sure that we'll have even downloaded all the windows dependencies if they are a strict superset given that you are running go get on a Linux machine to start with. John =:- On Tue, Oct 28, 2014 at 11:41 PM, Nate Finch nate.fi...@canonical.com wrote: We have a few windows dependencies that are not (and in some cases can not be) imported for the linux build. Luckily, the windows dependencies are a strict super set of the linux dependencies, so we can still use godeps to create dependencies.tsv, just by setting GOOS first, thusly (from the root of github.com/juju/juju): GOOS=windows godeps -t ./... dependencies.tsv Please use this command line when updating dependencies.tsv so that is keeps a standard format which will minimize conflicts in the file. -Nate -- 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
