[Charm Unpromulgation] Buildbot-Slave and Buildbot-Master
Greetings In accordance with our unmaintained charm workflow https://juju.ubuntu.com/docs/charm-unmaintained-process.html we have 2 items that have expired the maintainer-needed requirement. https://bugs.launchpad.net/charms/+source/buildbot-slave/+bug/1028192 https://bugs.launchpad.net/charms/+source/buildbot-master/+bug/1028191 They have been moved to the ~unmaintained-charms namespace and are still available for use from that branch but are no longer ~charmer recommended charms. https://launchpad.net/~unmaintained-charms/charms/precise/buildbot-slave/trunk https://launchpad.net/~unmaintained-charms/charms/precise/buildbot-master/trunk All the best, Charles -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Charmers Application
Hi everyone, Please consider this my application to join the Charmers team! I've been working in the Juju ecosystem for about 7 months, writing and reviewing charms, contributing to charm-related tools and libraries, and establishing automated-testing for charms and bundles. Here's a non-exhaustive list of my contributions, in no particular order: * Author and maintainer of the Meteor charm [1] * Numerous charm patches and reviews [2] * Contributions to the Amulet testing tool [3] * Author of the plugin system for `charm create` in the charm-tools project [4] * Author of the charmguardian testing tool [5] * Extensive work on automated charm testing [6] * Created documentation for the charm-helpers library [7] * Miscellaneous other contributions to charmworldlib, charm-tools, charm-helpers, bundletester, juju-deployer I've thoroughly enjoyed being a part of the Juju community and I'm excited about the future of Juju! I hope I can further contribute to Juju by becoming a Charmer and helping to maintain the Juju ecosystem in an official capacity. Thanks for your consideration! Tim Van Steenburgh [1] https://jujucharms.com/precise/meteor-2/?text=meteor#readme [2] http://review.juju.solutions/user/tvansteenburgh [3] https://github.com/marcoceppi/amulet/commits?author=tvansteenburgh [4] https://launchpad.net/charm-tools [5] https://github.com/juju-solutions/charmguardian [6] http://blog.juju.solutions/cloud/juju/2014/10/02/charm-testing.html [7] http://pythonhosted.org/charmhelpers/ -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
split charm templates and logic for different os (ubuntu/debian/centos)
Does juju team already have knowledge how the best split hooks and templates to provide support for different OS. AS i google somebody already have patches to deploy into centos. For example now - i want to rewrite wordpress charm to support debian wheezy. -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: split charm templates and logic for different os (ubuntu/debian/centos)
There shouldn't be much in the WordPress charm that's Ubuntu specific and should work fine on Debian. Some charms already have logic to support multiple Ubuntu releases by either coding switches in the hooks or by leveraging a configuration management tool like chef or puppet which abstracts that. Marco On Fri, Oct 10, 2014 at 9:20 AM, Vasiliy Tolstov v.tols...@selfip.ru wrote: Does juju team already have knowledge how the best split hooks and templates to provide support for different OS. AS i google somebody already have patches to deploy into centos. For example now - i want to rewrite wordpress charm to support debian wheezy. -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru -- 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: Using subdocument _id fields for multi-environment support
TL;DR: It has been surprisingly difficult As per what has already been done for the units and services collections, we will continue with the approach of using uuid:id style string ids while also adding separate env-UUID and collection specific identifier fields. Jesse and I have been making the changes to use subdocument ids for the units and services collections this week at the sprint and we've come up against some unexpected issues. We found that one part of the mgo/txn package wasn't happy using struct ids and have been working with Gustavo to fix that. This isn't a show-stopper but has slowed us down. We also found unexpected friction with the implementation of the watchers and entity life. These areas deeply assume that our document ids are strings and fixing them requires wide-ranging and often ugly changes which will take significant time to get right. It's been brick wall after brick wall. We discussed with Tim, Will, John and Ian yesterday and given that it's important that multi-environment support lands soon and given that the watchers are going to completely change in the not too distant future[1], we have abandoned the approach of using subdocument idfs for multi-environment support. The benefits of using subdocuments ids are outweighed by the chan - Menno [1] opening up the possibility of surrogate keys as document ids, where we need application domain fields to exist fields outside of the _id. On 1 October 2014 22:11, Menno Smits menno.sm...@canonical.com wrote: On 2 October 2014 01:31, Kapil Thangavelu kapil.thangav...@canonical.com wrote: it feels a little strange to use a mutable object for an immutable field. that said it does seem functional. although the immutability speaks to the first disadvantage noted for the separate fields namely becoming out of sync, which afaics isn't something that's possible with the current model, ie. a change of name needs to generate a new doc. Names (previous _id) are unique in usage minus the extant bug that unit ids are reused. even without that the benefits to avoiding the duplicate doc data and manual parse on every _id seem like clear wins for subdoc _ids. Just to be really sure, I added a test that exercises the case of one of the _id fields changing. See TestAttemptedIdUpdate in the (just updated) gist. MongoDB stops us from doing anything stupid (as expected). -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
