Re: Application for Juju Charmer Status
Hi Jose! Thank you so much for your submission to be a charmer. Not only have you been a huge asset helping community members but have done quite a lot of work in the audit and in patching charms. That said, I've noticed a large delta in your reviews of things which were missed and covered later by another reviewer. Typically we want to see a much shorter delta of missed items in review for a charmer application. While you don't have a vote from me, I'm simply going to abstain my vote in either direction as I really don't wish to diminish the amazing work you've done so far and continue to do but simply wish to highlight some concerns I have and think maybe re-applying again after some more time might be better. Marco On Thu, Aug 21, 2014 at 11:19 AM, Matt Bruzek matthew.bru...@canonical.com wrote: A big +1 from me! José has been an outstanding Juju community member for quite some time now. In addition to what he listed in his application, José helps out on IRC in #juju quite a bit. José is a community member, helping with the audit! I have worked closely with José on several of the charm submissions he listed there and I know he is committed to doing what is right for Juju and Ubuntu. José has earned my respect and I endorse his application. - Matt Bruzek matthew.bru...@canonical.com On Wed, Aug 20, 2014 at 3:36 PM, José Antonio Rey j...@ubuntu.com wrote: Hello, Juju-ers! So I believe it's the time. After a while, I'm now applying for charmer status. For those who don't know me, I am not a Canonical employee, but instead have been contributing to Juju as what I am - a community contributor. My contributions to the Juju Charm Ecosystem include various things, such as writing, adopting, improving and reviewing charms. I am the author for: * postfix - https://jujucharms.com/precise/postfix/ * mailman - https://jujucharms.com/precise/mailman/ * chamilo - https://jujucharms.com/precise/chamilo/ * seafile - https://jujucharms.com/precise/seafile/ * pubphoto (still on the RevQ) - https://code.launchpad.net/~jose/charms/precise/pubphoto/trunk I have, as well, taken maintainership of the ownCloud charm (https://jujucharms.com/precise/owncloud/). In terms of charm improvements, I recognize that quality is one of the most important things. That is why I have taken some charms and refactored them as they were not working, or fixed some bitesize bugs. Examples of the refactoring can be seen in the ownCloud charm, as well as in the Tracks charm (https://jujucharms.com/precise/tracks/, see MP at https://code.launchpad.net/~jose/charms/precise/tracks/fixes). More of the work I have been doing in terms of bitesize bugs can be found at https://code.launchpad.net/~jose. I also see bugs as a vital part of the ecosystem, letting us know what's going on with charms. Here are some of the bugs I have fixed: * Wordpress bug #1309980 Relationship to memcache seems incomplete - https://bugs.launchpad.net/charms/+source/wordpress/+bug/1309980 * ownCloud bug #1310164 Support SSL Connections - https://bugs.launchpad.net/charms/+source/owncloud/+bug/1310164 * ownCloud bug #1315091 juju remove-relation mysql owncloud does not work. - https://bugs.launchpad.net/charms/+source/owncloud/+bug/1315091 I have, as well, filed bugs and fixed them for proof errors that were currently on the store. Some examples are distcc (https://code.launchpad.net/~jose/charms/precise/distcc/fix-various), chef-server ( https://code.launchpad.net/~jose/charms/precise/chef-server/add-icon-categories-fix-readme ), nyancat ( https://code.launchpad.net/~jose/charms/precise/nyancat/add-categories-fix-readme ) and jenkins-slave ( https://code.launchpad.net/~jose/charms/precise/jenkins-slave/1297601-fix ) On the other hand, I have been listed as deputy reviewer one week, and have (apart from that) done in-depth new submission and MP reviews. I have blocked charms into the Charm Store when they are not yet ready or do not meet a policy, and celebrated the efforts of the author(s) if they are. Some examples of that are: * Bug #993483 Charm Needed: CakePHP - https://bugs.launchpad.net/charms/+bug/993483 * Bug #803538 Charm Needed: Diaspora - https://bugs.launchpad.net/charms/+bug/803538 * MP #222358, adding tests to Ceph - https://code.launchpad.net/~mbruzek/charms/precise/ceph/trunk/+merge/222358 * Bug #1314699 New charm - Apache Allura - https://bugs.launchpad.net/charms/+bug/1314699 And fixed one bitesize bug in juju-core (https://bugs.launchpad.net/juju-core/+bug/1309805). I am also working on advocacy and outreach, which is why I already have two Charm Schools scheduled, one for September in Orlando, FL, and one for October, at University of Lima, Peru. And I helped host some of the Charm Schools held at Ubuntu on Air! Finally, I understand the Charm Audit that is currently taking place and that tests are an important feature we want in charms.
Re: The tests now run godeps
On 21 August 2014 03:47, Nate Finch nate.fi...@canonical.com wrote: We've figured out that using godeps to print dependencies fails if you've installed Go from the PPA rather than from source, so that's why we're getting different results (Tim Ian have the PPA, I have the source). I'm sorry this is the case. I have now pushed a change to godeps that should fix the problem. Please run go get -u launchpad.net/godeps to update. cheers, rog. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Fwd: The tests now run godeps
On 21 August 2014 03:47, Nate Finch nate.fi...@canonical.com wrote: We've figured out that using godeps to print dependencies fails if you've installed Go from the PPA rather than from source, so that's why we're getting different results (Tim Ian have the PPA, I have the source). I'm sorry this is the case. I have now pushed a change to godeps that should fix the problem. Please run go get -u launchpad.net/godeps to update. cheers, rog. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: The tests now run godeps
I have toyed with the idea of adding a git hook that runs godeps whenever I switch branches. I haven't gotten around to trying it out, but would that possibly be another helpful thing for developers to do? On Thu, Aug 21, 2014 at 5:14 AM, roger peppe roger.pe...@canonical.com wrote: On 21 August 2014 03:47, Nate Finch nate.fi...@canonical.com wrote: We've figured out that using godeps to print dependencies fails if you've installed Go from the PPA rather than from source, so that's why we're getting different results (Tim Ian have the PPA, I have the source). I'm sorry this is the case. I have now pushed a change to godeps that should fix the problem. Please run go get -u launchpad.net/godeps to update. 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-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
changing the simplestreams filename format
Simplestreams generates files with names like this: http://maas.ubuntu.com/images/ephemeral-v2/daily/streams/v1/com.ubuntu.maas:daily:v2:download.sjson Unfortunately, the colons in the filename are illegal on Windows, which complicates getting tests running on Juju, and getting a fully-functional juju on Windows. I brought this up with Scott Moser, and it sounds like it might not be the end of the world to change the delimiter that is used to be something Windows-friendly. I wanted to bring this up on juju-dev in case there are juju-specific concerns about the proposed change to the filenames. I'm new to simplestreams, so I'm sure there are nuances I don't understand, which is why I'm posting it here. -Nate -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: changing the simplestreams filename format
Juju doesn't care whether there are colons or not. So any change made to what delimter is used can easily be accommodated. Juju would need to be modified to update its metadata generation plugins. Also, the internal content ids would need to remain the same (ie containing colons). On 22/08/14 06:37, Nate Finch wrote: Simplestreams generates files with names like this: http://maas.ubuntu.com/images/ephemeral-v2/daily/streams/v1/com.ubuntu.maas:daily:v2:download.sjson Unfortunately, the colons in the filename are illegal on Windows, which complicates getting tests running on Juju, and getting a fully-functional juju on Windows. I brought this up with Scott Moser, and it sounds like it might not be the end of the world to change the delimiter that is used to be something Windows-friendly. I wanted to bring this up on juju-dev in case there are juju-specific concerns about the proposed change to the filenames. I'm new to simplestreams, so I'm sure there are nuances I don't understand, which is why I'm posting it here. -Nate -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: changing the simplestreams filename format
On Fri, Aug 22, 2014 at 4:37 AM, Nate Finch nate.fi...@canonical.com wrote: Simplestreams generates files with names like this: http://maas.ubuntu.com/images/ephemeral-v2/daily/streams/v1/com.ubuntu.maas:daily:v2:download.sjson Unfortunately, the colons in the filename are illegal on Windows, which complicates getting tests running on Juju, and getting a fully-functional juju on Windows. Dumb question: when/where do we care? A URL is not a filesystem path, and we don't store simplestreams metadata on disk other than in provider storage as far as I'm aware. Provider storage is only on-disk for manual/local bootstrap nodes (for now). I brought this up with Scott Moser, and it sounds like it might not be the end of the world to change the delimiter that is used to be something Windows-friendly. I wanted to bring this up on juju-dev in case there are juju-specific concerns about the proposed change to the filenames. I'm new to simplestreams, so I'm sure there are nuances I don't understand, which is why I'm posting it here. -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
Triggering Server Restarts
Horacio had an interesting question on IRC and I wanted to bring it up to more people to get input. Specifically, juju restore has some properties that are pretty similar to juju upgrade-juju in that we really want the API server to restart after the action has completed. In the case of upgrade-juju the command only schedules an upgrade, and the actual upgrade happens asynchronously. When it completes, the worker/Upgrader raises UpgradeReadyError which is special cased at the top level Runner to realize this is a die and restart sort of error. I think Horacio is desiging juju restore to be a bit more synchronous. So rather than have a worker/Restorer running in the background, noticing that a restore needs to be done and triggering it, he has the API call itself do the work. I think this is sensible for restore as it has been written. I think the problem is that to trigger a restart, the worker itself (in this case APIServer) should be raising the error, which isn't really accessible in the context of the API call. (you want the API call to return successfully, an 'error' in this context is handed to the user, not up the Worker stack.) And the state/apiserver/client.Client object just has a direct reference to State, it doesn't have a reference to state/apiserver.Server to be able to trigger that sort of error in the apiserver.Server.tomb object. One possibility might be to have a worker/Restarter that watches for something (listens on a channel, something), and then triggers an exit with an error like UpgradeReadyError. My personal thought on how juju restore should work, is that it wouldn't actually be an API call, but instead of doing all the steps of juju bootstrap it would do all of them except the final jujud bootstrap-state, and substitute in a jujud restore-state. So we would still have everything running the restoration from server-side code, but we would be triggering it before we have created a running state server. This would have been more of a problem when we were triggering jujud bootstrap-state from cloud-init, but I'm pretty sure we are just directly sshing in and doing the work ourselves now. I guess it depends if this is an API we *ever* want to trigger at any other time than just at the beginning. Maybe we want to have the API so you call rollback even if it has been running for a while? John =:- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
