charm-tools releases going forward
Hello everyone! tl;dr: there's a new charm command coming for 16.04 which is a combination of charm-tools (current charm command) and the charmstore-client (currently charm2 command) projects. Some commands are being removed and a whole bunch added to make the charming experience more...charming. A follow up [ANN] on the release will be made when available for testing. With the upcoming 16.04/Juju 2.0 release we're legitimizing what started as a collection of example formulas[1] (that's right, the MySQL and WordPress charms were started over 5 years ago![2]) that grew to be a collection of bash scripts[3] and finally the charm command we know today. In Xenial, in the coming weeks, charm-tools will be a supplementary package to the new charm package. This new charm package provides an impressive set of tools for charmers to push charms, resources, and terms to the store faster; iterate and manage charm release processes; and a host of other functions vital to everyday charm workflows. With this new charm command a lot of charm-tool commands are being deprecated[4]. Going forward only the following commands will be available from the current charm command: - add - build - create - layers - proof - test There are new commands being added, but if you're using a charm command today that you don't see in that list please let me know. For those curious `charm compose` & `charm generate` are now `charm build` and `charm inspect` is `charm layers`.There will be a follow up announcement to this list when an RC of the new charm/charm-tools will be available for consumption. For the past few years we've been pretty liberal with a "release whenever" policy for charm-tools. This was great as there would be periods of time of high activity and low activity[0] so as needed we would simply cut releases as we saw fit. However, going forward we'll be adoption a 6 month semantic release process, much like Juju. Patches will be released as needed to address bugs within charm-tools and we'll work to make sure those get into the archive. Minor releases will occur every 6 months and we'll make alpha/beta releases available for early adoption. I'd like to take a moment to thank all the contributors to charm-tools thus far[0], the Juju UI Engineering team for their work on making sure charmstore-client and charm-tools works together effortlessly, and James Page for helping to sort out packaging. [0]: https://github.com/juju/charm-tools/graphs/contributors [1]: https://github.com/juju/charm-tools/tree/b0a46 [2]: https://github.com/juju/charm-tools/compare/b0a46d5...cb5add [3]: https://github.com/juju/charm-tools/tree/b5ee1 [4]: https://github.com/juju/charm-tools/issues/95 Thanks, Marco Ceppi -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Charm Store policy updates and refinement for 2.0
On 23 March 2016 at 06:37, Jorge O. Castro wrote: > Thanks for the feedback Stuart, I've pushed up a new revision. > >> I think the acceptable software sources needs to be expanded. > > I've added your recommendations for this section except for: > >> In addition, any software sources not in the main Ubuntu or CentOS >> archives should be listed in configuration items that can be >> overridden rather than hard coded in the charm > > I've changed this to a MUST as it's not that much work to do this and > the effort seems trivial compared to forcing users to mangle a charm > just to get it to deploy on production systems without egress. Yeah. And fixing it after people are using your charm in production is a pain, which I learned the hard way :) -- Stuart Bishop -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Container Ecosystem Update
Forgot to put the list in cc... This seems very promising, I'll try this out on our Hadoop clusters. PS: With some mailinglists I use, "reply" automatically sends the reply to the mailinglist instead of to the individual person. Isn't there a way to implement this for the Juju mailinglist? Kind regards Merlijn 2016-03-22 18:05 GMT+01:00 Charles Butler : > Great question, > > We're at a point that we have a 3 day old cluster of monitoring data. when > we get the ESDump action completed i'd like to stuff this in a larger > instance to really crunch the metrics over time. > > I haven't noticed any serious slowdown, but i'm also not running this at > full tilt. > > The agent seems to consume about as much memory as the jujud process, so > they're on part with the light weight statement (depending on your > definition of light weight) - and I have to say it churns through a backlog > of ~ 200mb in just under a few seconds (about 15, give or take a few) when > i pointed filebeat at a stale app log. > > Topbeat sits about the same, and its cpu allocation only goes up slightly > the further past 10 in interval you set in config. > > But these are all preliminary tests / results. > > > > On Tue, Mar 22, 2016 at 12:46 PM Merlijn Sebrechts < > merlijn.sebrec...@gmail.com> wrote: > >> - Dashboard Anything in Juju with Elastic Beats and the beats-core >>> bundle! >>> >> >> Awesome! >> >> Just curious; Any idea what the performance is of a beats monitored host >> + beats monitored containers running on top of that host? >> >> >>> - Net code deletion of 1500+ lines in the upstream kubernetes >>> repository - Layers FTW! >>> >> >> Wow! >> > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Charm Store policy updates and refinement for 2.0
Thanks for the feedback Stuart, I've pushed up a new revision. > I think the acceptable software sources needs to be expanded. I've added your recommendations for this section except for: > In addition, any software sources not in the main Ubuntu or CentOS > archives should be listed in configuration items that can be > overridden rather than hard coded in the charm I've changed this to a MUST as it's not that much work to do this and the effort seems trivial compared to forcing users to mangle a charm just to get it to deploy on production systems without egress. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Charm Store policy updates and refinement for 2.0
Hey Stuart! Thats a really good point about SSL on the interfaces service. I saw the bug a few weeks back but it slipped my mind, and it surprised me to discover its been there since 2015. I'll work towards having a resolution on this in the next week or so and will re-ping the list once its been TLS secure'd. Thanks for beating the drum on this one, i've needed some motivation. All the best, On Mon, Mar 21, 2016 at 10:14 PM Stuart Bishop wrote: > On 19 March 2016 at 02:58, Jorge O. Castro wrote: > > > Recommendations from everyone on what we should include here would be > > most welcome, specifically our recommendations around Windows charms > > is non-existent. > > I think the acceptable software sources needs to be expanded. > Launchpad PPAs should be acceptable as signing keys are securely > retrieved when using 'add-apt-repository ppa:foo/bar'. Also, 3rd party > apt repositories should be acceptable if the signing key is embedded > in the charm (PyPi could be checked similarly, but it seems rare to > find signed packages there). > > In addition, any software sources not in the main Ubuntu or CentOS > archives should be listed in configuration items that can be > overridden rather than hard coded in the charm, or else the charm is > useless in network restricted environments (and yes, migrating to > resources may be a better user experience in many cases). > > As examples, the PostgreSQL charm pulls non-default packages from the > upstream PostgreSQL apt repository (PGDG, which is the source which > flows to Debian and Ubuntu). The Cassandra charm pulls a required > driver from a PPA I control. It also installs packages from either the > Apache apt repository or the DataStax apt repository. Cassandra is not > available in the Debian or Ubuntu main archives, probably as it > required the Oracle JVM. Both charms use the > install_sources/install_keys config items parsed by charm-helpers and > the apt layer to make this configurable. > > On a side note, it is somewhat disingenuous to block charms in the > store from pulling dependencies from untrusted sources at run time > when we happily pull dependencies from untrusted sources at build > time. I think the fix here is to do better at build time (Moving the > interfaces web site to https: and ensuring clients use that address, > only allowing https:, git+ssh: and other secure protocols for pulling > branches, and checking GPG signatures of embedded wheels are the > issues here I'm aware of) > > -- > Stuart Bishop > > -- > 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
Container Ecosystem Update
Greetings Everyone o/ There's a full writeup over on the blog space: http://dasroot.net/posts/2016-03-22-containers-update/ I wanted to take some time to shed some light into what the containers team has been up to these last couple weeks. Its been a very exciting time. The highlights are: - Dashboard Anything in Juju with Elastic Beats and the beats-core bundle! - Net code deletion of 1500+ lines in the upstream kubernetes repository - Layers FTW! - New ELK bundle - New Logstash Charm - New Beats charms (4 in total, 2 are 'stable') - New Dashboard loading action in Kibana - Kubernetes Log Aggregation, visualization, and storage (log dump from vis to cold storage is still TODO:) Deploy happy! -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Query on IBM-Installtion Manger Charm Layer
Hi Kevin, Thanks for providing your thoughts on IBM Installation Manager layer ...!! Will work on this and if any doubts will check with you. Regards, Shruthima. From: Kevin Monroe To: Matt Bruzek Cc: Shruthima Almavar/India/IBM@IBMIN, juju Date: 02/11/2016 05:23 AM Subject:Re: Query on IBM-Installtion Manger Charm Layer Hi Shruthima, We came up with what we think an IBM Installation Manager base layer might look like: https://github.com/kwmonroe/layer-ibm-installation-manager This is not a functional layer yet (ie, it needs to do the actual IBM IM installation in ./reactive/ibm-installation-manager.sh), but we think this is a good starting point for a layer that can be extended by other IBM software (eg: WebSphere) that utilizes IBM IM for their install. Check out the README at the above repo to see how we envision other charm layers using this IBM IM base layer. Take a look and let us know if you have any questions or concerns with this approach to providing a common IBM IM layer for others to extend. Thanks, Kevin On Fri, Feb 5, 2016 at 3:18 AM, Matt Bruzek wrote: Hello Shurthima, Thanks for reaching out to the Juju list. The layered approach is the way to write all new charms. We do recommend that you use the basic layer when creating a new base level feature such as IBM Installation Manager. To do that the layer.yaml should look like this: includes: ['layer:basic'] As far as interface, I would have to know more about what services IBM IM can use or interact with. If IBM IM can talk to a database it should have a database relation. If the product has an web interface it should implement the http interface. You as the author knows the product better than I would. Interface layers make it very easy to use juju interfaces. We have some documentation about how to write layered charms, for more information please read: https://jujucharms.com/docs/devel/developer-getting-started Please email the list if you have any more specific questions. Thanks! - Matt Bruzek On Tue, Feb 2, 2016 at 12:34 PM, Shruthima Almavar wrote: Hello Team, I am working on IBM-Installation Manager charm and I will be developing this charm from layers . i have explored on layers and thought to use basic layer which is present in "http://interface.juju.com"; but not sure about it ?? Could you please suggest me which layer and interface i can use for charming IBM-IM product. Thanks. Regards, Shruthima -- 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 -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
