Re: Goodbye Opsworks

[Antonio Rosales]

On Mar 31, 2017 7:06 PM, "James Beedy"  wrote:

The day has finally come for me to turn down the last of our Opsworks
instances for our PRM application. This marks the completion of one of many
Opsworks -> Juju conversion projects I've taken on. Thanks everyone for
your help along the way!

Goodbye Opsworks - http://imgur.com/a/4pkgP

Hello Juju PRM!

Staging - http://paste.ubuntu.com/24291143/
Demo - http://paste.ubuntu.com/24291156/
Production - http://paste.ubuntu.com/24291133/
Walmart - http://paste.ubuntu.com/24291173/


Congrats on your new environment!

-Antonio


W00T!

--
Juju-dev mailing list
juju-...@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/
mailman/listinfo/juju-dev
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Goodbye Opsworks

[Antonio Rosales]

On Mar 31, 2017 7:06 PM, "James Beedy"  wrote:

The day has finally come for me to turn down the last of our Opsworks
instances for our PRM application. This marks the completion of one of many
Opsworks -> Juju conversion projects I've taken on. Thanks everyone for
your help along the way!

Goodbye Opsworks - http://imgur.com/a/4pkgP

Hello Juju PRM!

Staging - http://paste.ubuntu.com/24291143/
Demo - http://paste.ubuntu.com/24291156/
Production - http://paste.ubuntu.com/24291133/
Walmart - http://paste.ubuntu.com/24291173/


Congrats on your new environment!

-Antonio


W00T!

--
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

Re: giraph charm approved

[Antonio Rosales]

resenting a paper on operating it efficiently with charms?
>>
>> Mark
>>
>> On 03/03/17 09:25, Panagiotis Liakos wrote:
>>> Yesterday the giraph charm I've been working on the last weeks was
>>> promulgated to:
>>> https://jujucharms.com/giraph/
>>>
>>> I would just like to express my gratitude towards Konstantinos, Kevin,
>>> and Merlijn for their extremely valuable help!
>>>
>>> I hope that the charm is useful to many juju enthusiasts and I will do
>>> my best to make it better with time!
>>>
>>> Thank you!!!
>>
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/juju



-- 
Antonio Rosales
Ecosystem Engineering
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [Review Queue]: websphere liberty, canonical-livepatch, ganglia-node, gluster, openvpn

[Antonio Rosales]

On Sat, Feb 4, 2017 at 9:48 AM, Merlijn Sebrechts
 wrote:
> Thanks Cory and team!
>
>
> I didn't test my Charm on a public cloud, which meant I had a code path that
> wasn't executed before. I fixed it and used my Charm Developer Program
> Credentials® verify on AWS. Mentioning it because those are very useful! :)
>
> I uploaded the next version to the Charm Store; do I need to do anything
> else to get a re-review?

Nope, post your update the status updated to "Needs Review" and you
can see the revisions of your charm inline in the reivew at:
https://review.jujucharms.com/reviews/58. Tim is addressing the Elrond
errors :-)

It will get picked up by the next folks who do reviews.

Thanks for the work on openvpn charm.

-Antonio

>
>
>
> Regards
> M
>
> 2017-02-03 16:56 GMT+01:00 Cory Johns :
>>
>> Greetings!
>>
>> Kevin, Konstantinos, Pete, and I worked on the queue yesterday.  Got a new
>> promulgation, and some feedback.  Thanks to the charming community!
>>
>> Feb 2, 2017:  Cory, Kevin, Kostas, Pete
>>
>> Websphere Liberty
>>
>> https://review.jujucharms.com/reviews/48
>>
>> Deployment looks good; tests pass.
>>
>> +1, promulgated:
>>
>> https://jujucharms.com/websphere-liberty/
>>
>> Canonical-Livepatch
>>
>> https://review.jujucharms.com/reviews/46
>>
>> Good, modulo linter errors.
>>
>> ganglia-node
>>
>> https://review.jujucharms.com/reviews/51
>>
>> The test.yaml appears to be missing a python-packages declaration, which
>> means that the amulet tests are missing required python packages.
>>
>> gluster
>>
>> https://review.jujucharms.com/reviews/43
>>
>> There were a couple of issues we found during review.
>>
>> No tests
>>
>> Readme needs updates
>>
>> We will have to wait for the author’s input for this.
>>
>> openvpn
>>
>> https://review.jujucharms.com/reviews/58
>>
>> Charm itself looks great, but has install hook and test timeout failures
>>
>>
>>
>> --
>> 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

Re: Create Juju Charms from your browser!

[Antonio Rosales]

On Feb 3, 2017 7:08 PM, "Junaid Ali"  wrote:

Great. Thanks Merlijn for sharing.


+1 and juju deployable to give it a quick spin too, nice work.

-Antonio


-- Junaid

--
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: Removing the single point of failure

[Antonio Rosales]

 central, those of us with bandwidth could mirror
>>>> resources that are vital for smooth running of Juju operations.
>>>>
>>>> True, mirroring would be huge, but shouldn't be a solution . We
>>>> should deploy the site across multiple az/regions if you ask me :-)
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>



-- 
Antonio Rosales
Ecosystem Engineering
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Request to join ~charmers

[Antonio Rosales]

Congrats on your charmer-hood Pete!

-Antonio

On Mon, Jan 30, 2017 at 7:16 AM, Tom Barber <t...@spicule.co.uk> wrote:
> N not Pete, you'll take him away from being ultra useful and pool him
> with the rest of you lot! ;)
>
>
> On 30 Jan 2017 14:13, "Charles Butler" <charles.but...@canonical.com> wrote:
>>
>> +1 for Pete :)
>>
>> Welcome aboard my man!
>>
>>
>> Charles Butler <charles.but...@canonical.com> - Juju Charmer
>> Come see the future of modeling your datacenter: http://jujucharms.com
>> Conjure up Kubernetes: `conjure-up canonical-kubernetes` on any ubuntu
>> install with Conjure and Juju.
>>
>> On Thu, Jan 26, 2017 at 10:01 AM, Pete Vander Giessen
>> <pete.vandergies...@canonical.com> wrote:
>>>
>>> Hi All,
>>>
>>> I've been working with the Big Data team since May 2016, and have written
>>> or contributed to our charms (see https://github.com/juju-solutions/bigtop),
>>> and layers (e.g.
>>> https://github.com/juju-solutions/layer-apache-bigtop-base), as well as to
>>> the matrix testing tool and cloud weather report. I also take a trip through
>>> the review queue with the team once a week, and would like to be able to
>>> finish up my positive reviews with a push to the charm store, when
>>> appropriate.
>>>
>>> Thank you for considering me,
>>> ~ PeteVG
>>>
>>>
>>>
>>> --
>>> 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
>



-- 
Antonio Rosales
Ecosystem Engineering
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: The docs around charm and bundle testing need some love

[Antonio Rosales]

On Tue, Jan 17, 2017 at 9:54 AM, Merlijn Sebrechts
 wrote:
> Hi all
>
>
> The testing docs need some love. The whole Charm testing ecosystem is very
> complex. The docs should focus on guiding users to a best-practice workflow.
> There is just too much choice to let the user figure it out himself.
>
> We want charmers to write Charm and Bundle tests that are compatible with
>
> a) `bundletester` + (LXD | a cloud)
> b) the review queue
>
> c) the cwr-ci bundle
>
>
> The docs should provide two best-practice workflows; one for testing charms
> and one for testing bundles. Each workflow needs a working example.
>
> The example includes a `tests.yaml` file that is compatible with a,b and c,
> and it should include commands to deploy the tests locally. The example
> should hide as much advanced config as possible. It's nice that you can
> specify a custom glob pattern for the test files, but this is something for
> advanced uses.
>
> Some questions that the docs should answer:
>
> - What tools should I use? (Bundletester + Amulet. cwr-ci if you want a ci
> pipeline.)
> - What's the best way to deploy a Charm/Bundle using amulet?
> (`deployment.add` for a Charm and `find_bundle` for a bundle)
> - Which options should I use in tests.yaml?
> - Reset the environment or not? Let bundletester do cleanup, or clean it up
> using Amulet?
> - Deploy bundle by bundletester or by amulet?
> - Where can I find Charms/Bundles that have working best-practice tests?
>
> I think we need some discussion around what the best-practice workflows for
> testing are, and then we need to standardize everything around these
> workflows. An example of a choice that needs to be discussed is whether
> bundle tests should first execute the individual Charm tests.
>
> - The default behavior is to do this, so that implies "yes, bundle tests
> should first execute charm tests"
> - Charms and bundles are promulgated independently, and cwr-ci bundle is
> also going this approach. This implies that the Charms are already tested
> (either by cwr-ci or the review queue). This implies "no, it's useless to
> first execute charm tests because we know they've succeeded".
>


Thanks for bringing up the points, and the areas we should be sure we
should cover in our testing docs. I agree we should make some best
practice recommendations and examples for developers to leverage when
getting started.

With cwr-ci we wanted to be sure and include the goal of charms which
is a solution context or bundles. Thus, we developed the tooling
around charms being part of a bundle and even having a reference
bundle that testing can occur around. There is also the introduction
of Matrix to improve the operational testing of the applications in a
distributed manner. A lot of good info to be documented.

Ideally we take the documentation at:
https://jujucharms.com/docs/stable/developer-testing

Along with your key points we update it to reflect the readme at:
https://jujucharms.com/u/juju-solutions/cwr-ci/

Expanding on key tools such as
- CWR
- Bundletester
- Matrix
- Libjuju

Be also nice to have some recommended workflows.

I'll have a draft ready by the Charmer Summit that I will send to the
list here and invite you and any others interested in charm/bundle
testing. Perhaps if folks are able to attend the summit in person we
can discuss further face-to-face.

Thoughts?

-Antonio

>
> Kind regards
> Merlijn
>

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

The Juju Show #4: Today, Wed Jan 18 @ 2pm EST/19:00 GMT

[Antonio Rosales]

Just a reminder today we will have a Juju Show Hangout today Wed Jan
18 @ 2pm EST/19:00 GMT.

Join us in #juju@freenode if you would like to participate in the
hangout or watch at https://www.youtube.com/watch?v=Lsbo7f7yMxY

-thanks,
Antonio

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju Show #2 Wed Dec 14th

[Antonio Rosales]

On Tue, Dec 13, 2016 at 1:47 PM, Rick Harding
 wrote:
> Come join us as we host the next Juju Show live stream tomorrow. We'll be
> going over the latest in community news, demoing the new developments in
> tools for charming, and getting a demonstration of the new model migration
> feature coming in Juju 2.1.
>
> When: Nov 30th, at 19:00 GMT, 2:00pm EST
> Where: https://www.youtube.com/watch?v=FwLEMa7XE64
> How to participate: Hang out in the #juju Freenode IRC channel
>
> Join us in the IRC channel to ask questions, get a link to the hangout to
> join the live stream, or just to listen in on the latest news.
>
> Make sure to subscribe to the Juju Youtube channel so you never miss any of
> the happenings in and around Juju!
>
> https://www.youtube.com/channel/UCSsoSZBAZ3Ivlbt_fxyjIkw

Also if you want an easier link to remember for the Juju Channel try:
https://www.youtube.com/jujucharms

Also some folks have asked what hashtag to use for Juju. We have been
trying to use #jujucharms (https://twitter.com/hashtag/jujucharms).
So, if you have some interesting bits to tweet out please include the
#jujucharms hashtag.

-thanks,
Antonio

>
> See you there!
>
> Rick
> Juju Engineering
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Updated Charm Developer Workflow for Juju Charm Store

[Antonio Rosales]

To follow on Tim's email for the updated Review Queue:
https://lists.ubuntu.com/archives/juju/2016-December/008287.html
There are new tasks and workflows for both maintainers and
contributors that folks should take note of.

If you are a current charm maintainer, we recommend the following actions:
- Ensure your charm is in your preferred SCM, e.g. Launchpad or Github.
- Create a team in Launchpad, e.g. -team
(https://launchpad.net/people/+newteam).  This spreads maintenance
tasks to team members who can push charm updates to the team’s name
space in the charm store.
- Ensure you set the charm/bundle home page and bug link URL using
‘charm set’ (https://jujucharms.com/docs/stable/tools-charm-tools).
This helps users know where they can find more information about your
application and where bugs/issues should be raised.
- Release the latest revision of your charm into the team’s name space
(https://jujucharms.com/docs/stable/authors-charm-store).
- Submit a new charm revision for review @
http://review.jujucharms.com to have it promulgated to the recommended
name space. Remember to release new revisions of the charm when
updates are made in the upstream repo or when appropriate in the
application release process.

If you would like to make a contribution to a charm and you are not
currently the maintainer, find the charm detail page at
http://jujucharms.com.  You should be able to find links to the
project homepage and bug tracker where you can contribute charm
changes.

I'll be working on https://github.com/juju/docs/issues/1563 to get
this updated in jujucharms.com/docs. If folks have any questions feel
free to reply here or or at https://github.com/juju/docs/issues/1563

thanks,
-- 
Antonio Rosales
Ecosystem Engineering
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: conjure-up Canonical Kubernetes in LXD

[Antonio Rosales]

On Thu, Nov 17, 2016 at 5:02 PM, Charles Butler
<charles.but...@canonical.com> wrote:
> This deserves a ton of fanfare. Let's celebrate this win by circulating this
> like crazy.
>
> I've already retweeted this evening and plan on following up again tomorrow
> during normal business hours.  Great work Stokes on completing this
> herculean task. The ~containers team, appreciates the effort that went into
> this, and the collaboration across our teams.

Indeed, OpenStack, Kubernetes, or Hadoop-Spark Cluster . . . on your
laptop. . . in machine containers . . . multi-node . . . same as in
the cloud. . . Developers Rejoice!

-Antonio


>
> Go team!
>
>
>
> Charles Butler <charles.but...@canonical.com> - Juju Charmer
> Come see the future of modeling your datacenter: http://jujucharms.com
>
> On Thu, Nov 17, 2016 at 5:51 PM, Adam Stokes <adam.sto...@canonical.com>
> wrote:
>>
>> Just pulled in changes to support deploying The Canonical Distribution of
>> Kubernetes on the localhost cloud type.
>>
>> I've blogged about it here:
>>
>> http://blog.astokes.org/conjure-up-canonical-kubernetes-under-lxd-today/
>>
>> Please give it a shot deploy some workloads on it and let us know how it
>> goes.
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>



-- 
Antonio Rosales
Ecosystem Engineering
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Removing the single point of failure

[Antonio Rosales]

As an update http://interfaces.juju.solutions/ is back up.

-thanks
Antonio

On Saturday, November 12, 2016, Tom Barber  wrote:

> Thanks for the update Marco.
>
> just to make sure people understand is inference in emails is awful. I'm
> not freaking out or complaining about the outage this stuff happens, more
> just offering mirror support etc should it be seen as a good course of
> minimising outage.
>
> Tom
>
> On 12 Nov 2016 17:19, "Marco Ceppi"  > wrote:
>
>> Hey everyone,
>>
>> We're aware of the outage and working to bring the service back online.
>> This is unfortunate, but we're in the process of getting the
>> interfaces.juju.solutions site, folded into the charm store properly. This
>> service has done it's job in providing the initial indexing but as we see
>> today it's become integral to the operation of charm authorship and should
>> be as robust as the charm store itself.
>>
>> To address concerns about "what if". Juju, the interfaces site, the charm
>> layers, are all open source projects. While some items aren't directly
>> configurable if we ever did enter a period where Canonical wasn't directly
>> maintaining infrastructure for Juju and Charms the community could uphold
>> these projects and elect to run them directly. Juju is a key platform to
>> Canonical just as it is to you all. While outages like this may occur, we
>> are iterating quickly to make sure projects like the interfaces site are
>> folded into jujucharms.com and served with the same level SLA and HA as
>> you've come to expect.
>>
>> Marco
>>
>> On Sat, Nov 12, 2016 at 10:44 AM Tom Barber > > wrote:
>>
>>> I don't really think Mark is going to do one, my point is that for
>>> platforms like this to survive if they depend on central services for
>>> build/running etc, the services shouldn't just be maintained by a single
>>> entity.
>>>
>>> HA sure will solve some issues but I also think that distributing
>>> ownership also mitigates risk.
>>>
>>> On 12 Nov 2016 16:39, "James Beedy" >> > wrote:
>>>
 Here's something thats been troubling me for a while, Canonical are the
 single point of failure with juju. For example, this morning
 interfaces.juju.solutions appears to be offline, thats not the end of
 the
 world but of course I can't download layers from it.

 I entirely second this. Interfaces.juju.solutions needs to have some
 kind of uptime guarantee, and probably need each component deployed in
 HA/federated to ensure the uptime.

 Companies/people are building infrastructure around the charm store,
 interfaces.juju.solutions, and juju itself, what happens when 100 entities
 realize that their CI (or any critical infrastructure) has been down for an
 amount of time? For many, this could stunt development and increase budget
 expenditures.


 Similarly, if Mark for whatever reason decided he couldn't be bothered
 with
 Juju any more and went and did something else, the users would be
 without
 resource that is vital to people building stuff.


 I have to disagree with you here. Mark is an amazing driver for these
 technologies and technology communities, but they exist outside of, and
 disparate of Mark and Canonical. While the world (as well as these
 technologies) would undoubtedly not be same if not for Mark's
 contribution(s), I think the idea here is that the majority of the software
 in Canonical stack has enough wind under it to survive in the wild.

 Does mirroring capabilities exist for other people to mirror
 interfaces.juju.solutions and can you tell juju to use another portal?
 That
 way, much like maven central, those of us with bandwidth could mirror
 resources that are vital for smooth running of Juju operations.

 True, mirroring would be huge, but shouldn't be a solution . We
 should deploy the site across multiple az/regions if you ask me :-)




 --
 Juju mailing list
 Juju@lists.ubuntu.com
 
 Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
 an/listinfo/juju

>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> 
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>

-- 
-Thanks
Antonio
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.0 is here!

[Antonio Rosales]

Congrats on the 2.0 GA release!

-Antonio

On Thursday, October 13, 2016, Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:

> Juju 2.0 is here! This release has been a year in the making. We’d like to
> thank everyone for their feedback, testing, and adoption of juju 2.0
> throughout its development process! Juju brings refinements in ease of use,
> while adding support for new clouds and features.
>
> ## New to juju 2?
>
> https://jujucharms.com/docs/2.0/getting-started
>
> ## Need to install it?
>
> If you are running Ubuntu, you can get it from the juju stable ppa:
>
> sudo add-apt-repository ppa:juju/stable
> sudo apt update; sudo apt install juju-2.0
>
> Or install it from the snap store
>
> snap install juju --beta --devmode
>
> Windows, Centos, and MacOS users can get a corresponding installer at:
>
> https://launchpad.net/juju/+milestone/2.0.0
>
> ## Want to upgrade to GA?
>
> Those of you running an RC version of juju 2 can upgrade to this release
> by running:
>
> juju upgrade-juju
>
> ## Feedback Appreciated!
>
> We encourage everyone to subscribe the mailing list at
> juju@lists.ubuntu.com and join us on #juju on freenode. We would love to
> hear
> your feedback and usage of juju.
>
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju-dev
>


-- 
-Thanks
Antonio
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Juju 2.0 Beta9 and Juju GUI

[Antonio Rosales]

fyi for your early adopter and testing out the good work in juju-core
beta9 and would like to use the juju-gui you will need to upgrade the
juju-gui by:

To upgrade the GUI:
Download the tar.bz2 from https://github.com/juju/juju-gui/releases/tag/2.1.7
Run juju upgrade-gui path/to/release

per
https://github.com/juju/juju-gui/issues/1780#issuecomment-227226545

Note this is only for folks wanting to use the juju-gui in juju 2.0 beta9.

thanks,
-- 
Antonio Rosales
Ecosystem Engineering
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Feedback wanted: tab completion in 2.0 betas

[Antonio Rosales]

On Thursday, June 2, 2016, Jorge O. Castro  wrote:

> Hi everyone,
>
> This entire time I thought tab completion was just not implemented yet
> in 2.0. During a call someone told me that for them tab completion
> worked great. I started asking around and got different answers from
> everyone, on some machines it works great, on others, not at all. So
> we expect it's something to do with either an upgrade at some point or
> some other unknown. So I've opened a bug so we can collect some
> feedback.
>
> https://bugs.launchpad.net/juju-core/+bug/1588403


I previously opened
 https://bugs.launchpad.net/bugs/1582018
for similar issues.

Thanks,
-Antonio


> Martin Packman will post a follow up with some more instructions to
> help us get to the bottom of this, thanks!
>
> --
> Jorge Castro
> Canonical Ltd.
> http://jujucharms.com/ - The fastest way to model your service
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com 
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>


-- 
-Thanks
Antonio
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: information needed for Mariadb Enterprise edition

[Antonio Rosales]

On Thu, May 26, 2016 at 1:34 PM, Daniel Bartholomew <db...@mariadb.com> wrote:
> On Tue, May 24, 2016 at 6:38 PM, Daniel Bartholomew <db...@mariadb.com> wrote:
>> On Thu, May 19, 2016 at 7:46 PM, Kevin Monroe
>> <kevin.mon...@canonical.com> wrote:
>>> I recently took a look at the mariadb charm on ppc64le and ran across some
>>> interesting bits.  I'm looping in the charm maintainer (dbart) for extra
>>> insights.
>>>
>>> First, MariaDB has both enterprise and community versions available for this
>>> charm to deploy.  Rajith, as you saw in the readme, you should be able to
>>> obtain credentials from the MariaDB Portal
>>> (https://mariadb.com/user/login?destination=my_portal/download).  However, 
>>> there was a recent change in the package signing key [0] that
>>> may affect installation.  Daniel, are these "enterprise.yaml" creation
>>> instructions in the charm readme still valid?:
>>>
>>> http://bazaar.launchpad.net/~charmers/charms/trusty/mariadb/trunk/view/head:/README.md#L46
>>>
>> No. Those are old instructions. I submitted an updated version of the
>> charm way back in November, but it looks like it never made it into
>> the charm store. As a first step, the version of the charm currently
>> in my repo (revision 28) should immediately be pushed to the charm
>> store: lp:~dbart/charms/trusty/mariadb/trunk
>>
>> The correct readme is here:
>>
>> http://bazaar.launchpad.net/~dbart/charms/trusty/mariadb/trunk/view/head:/README.md#L24
>>
>> ...but the instructions there won't work unless the charm in the store
>> is updated.
>>
>
> After looking into the issues some more, I've uncovered some new ones
> relating to deployment of MariaDB Enterprise on POWER8 with the
> updated version of the charm my launchpad repo. It's probably best to
> keep the old charm in the store as-is until I have the new version I'm
> working on ready. I should have it done early next week. POWER8
> deployment issues with the old charm, as long as you don't configure
> the enterprise.yaml file, and just 'juju deploy mariadb' are now
> resolved AFAIK thanks to some modifications I made today to the
> community MariaDB repositories.

While you are in the midst of updating have you taken a look at
Resources and Terms in Juju 2.0?

Resources is documented at:
https://jujucharms.com/docs/master/developer-terms

Terms is under final review at:
https://github.com/juju/docs/pull/1122/files
Specifically,
https://github.com/mbruzek/docs/blob/abd31c0962d73efea76a1381a857a279e27d384d/src/en/developer-resources.md


Thanks for the work on the MariaDB charm. If you have any questions
please post here or in #juju@Freenode.
-Antonio

>
> Thanks.
>
> --
> Daniel Bartholomew, MariaDB Release Manager
> MariaDB | http://mariadb.com
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/juju



-- 
Antonio Rosales
Ecosystem Engineering
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Charm Store Policy Update: Propritary applications usage of Terms and Resources

[Antonio Rosales]

Hello,

As we close in on Juju 2.0 I would like to propose an update the Charm
Store policy to require Charms deploying proprietary applications to
use Terms and Resources (where applicable).

Terms help Juju users understand and accept the EULA so they may
properly deploy the software and adhere to the License. Terms
immensely improve usability, and properly guides users so they are
clear about the license of the deployed applications.

Resources also dramatically improves the user experience where the
payload(s) need to be coordinated, and distributed to applications in
a controller.

Should this also be required of Charms deploying Open Source applications?

ref = https://github.com/juju/docs/issues/1120

thanks,
-- 
Antonio Rosales
Ecosystem Engineering
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: ApacheCon Photo

[Antonio Rosales]

On Friday, May 13, 2016, Tom Barber  wrote:

> I have a feeling there was a photo or two taken of me working the booth on
> Tuesday or whenever it was. If anyone has one and fancies sending it my
> way, I'd like to include it in a blog post if its remotely acceptable.
>

Sent over the ones I had.

There was some solid Juju based sessions at Apache Big Data conf. I'll send
them to the list when the Linux Foundation uploads.

-Thanks
Antonio


>
> Ta
>
> Tom
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>



-- 
-Thanks
Antonio
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Layer licensing and charm licensing

[Antonio Rosales]

On Thu, May 5, 2016 at 9:47 AM, Mark Shuttleworth  wrote:
> Hi folks
>
> The move to layers, which is fantastic from a charming productivity point of
> view, will also raise the question of licensing in a cross-charm way.
> Originally, we envisaged each charm being licensed by the charmer
> independently, but layers introduce cross-cutting licensing questions, and
> in particular, questions about copyleft.

Thanks for kicking off this thread.

>
> It certainly is not our intent that contributions from Canonical (which we
> generally prefer to make under copyleft licenses) should force a charm
> author to pick a copyleft license for their own contributions to their own
> charm.
>
> There are two options for common code that would be obvious solutions - a
> limited copyleft (LGPL) and a permissive (Apache2 or BSD). Both options
> enable people to bring shared public layers into their charms but still pick
> their own licenses for their own layers and additional bits. The LGPL option
> would require people modifying shared layers to allow others to use their
> modifications ("if you edit this file, we can merge your edits") but any new
> pieces created by them (typically specific to their charms) could be
> restricted for their own use.
>
> The OSM project, which is using charms for telco application modelling, has
> a preference for Apache2, which is arguably also a preference for many other
> industrial-scale initiatives.

It will be interesting to hear people's opinion on the subject. In my
experience upstreams are more comfortable to contribute, include, and
build on-top of charms that have an Apache License. Thus, as a lowest
common denominator perhaps Apache encourages more comfort for building
on top of and/or reusing.

-thanks,
Antonio

>
> We could also dual-license these components (Apache2 + LGPL, or even Apache2
> + GPL).
>
> Am writing to gather feedback from the charmer community as to your
> preferences in this regard.
>
> Mark

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

[Antonio Rosales]

On Monday, March 28, 2016, Ian Booth <ian.bo...@canonical.com> wrote:

> Hey Antonio
>
> I must apologise - the changes didn't make beta3 due to all the work
> needed to
> migrate the CI scripts to test the new hosted model functionality; we ran
> out of
> time to be able to QA the local bundle changes.
>
> I expect this work will be done for beta4.


Completely understood. I'll retest with Beta 4. Thanks for the update.

-Antonio


>
>
>
On 29/03/16 11:04, Antonio Rosales wrote:
> > + Juju list for others awareness
> >
> >
> > On Thu, Mar 10, 2016 at 1:53 PM, Ian Booth <ian.bo...@canonical.com
> <javascript:;>> wrote:
> >> Thanks Rick. Trivial change to make. This work should be in beta3 due
> next week.
> >> The work includes dropping support for local repositories in favour of
> path
> >> based local charm and bundle deployment.
> >
> > Ian,
> > First thanks for working on this feature. Second, I tried this for a
> > local ppc64el deploy which is behind a firewall, and thus local charms
> > are good way forward. I may have got the syntax incorrect and thus
> > wanted to confirm here. What I did was is at:
> > http://paste.ubuntu.com/15547725/
> > Specifically, I set the the charm path to something like:
> > charm: /home/ubuntu/charms/trusty/apache-hadoop-compute-slave
> > However, I got the following error:
> > ERROR cannot deploy bundle: cannot resolve URL
> > "/home/ubuntu/charms/trusty/apache-hadoop-compute-slave": charm or
> > bundle URL has invalid form:
> > "/home/ubuntu/charms/trusty/apache-hadoop-compute-slave"
> >
> > This is on the latest beta3:
> > 2.0-beta3-xenial-ppc64el
> >
> > Any suggestions?
> >
> > -thanks,
> > Antonio
> >
> >
> >>
> >> On 10/03/16 23:37, Rick Harding wrote:
> >>> Thanks Ian, after thinking about it I think what we want to do is
> really
> >>> #2. The reasoning I think is:
> >>>
> >>> 1) we want to make things consistent. The CLI experience is present a
> charm
> >>> and override series with --series=
> >>> 2) more consistent, if you do it with local charms you can always do it
> >>> 3) we want to encourage folks to drop series from the charmstore urls
> and
> >>> worry less about series over time. Just deploy X and let the charm
> author
> >>> pick the default best series. I think we should encourage this in the
> error
> >>> message for #2. "Please remove the series section of the charm url" or
> the
> >>> like when we error on the conflict, pushing users to use the series
> >>> override.
> >>>
> >>> Uros, Francesco, this brings up a point that I think for multi-series
> >>> charms we want the deploy cli snippets to start to drop the series
> part of
> >>> the url as often as we can. If the url doesn't have the series
> specified,
> >>> e.g. jujucharms.com/mysql then the cli command should not either.
> Right now
> >>> I know we add the series/revision info and such. Over time we want to
> try
> >>> to get to as simple a command as possible.
> >>>
> >>> On Thu, Mar 10, 2016 at 7:23 AM Ian Booth <ian.bo...@canonical.com
> <javascript:;>> wrote:
> >>>
> >>>> I've implemented option 1:
> >>>>
> >>>>  error if Series attribute is used at all with a store charm URL
> >>>>
> >>>> Trivial to change if needed.
> >>>>
> >>>> On 10/03/16 12:58, Ian Booth wrote:
> >>>>> Yeah, agreed having 2 ways to specify store series can be suboptimal.
> >>>>> So we have 2 choices:
> >>>>>
> >>>>> 1. error if Series attribute is used at all with a store charm URL
> >>>>> 2. error if the Series attribute is used and conflicts
> >>>>>
> >>>>> Case 1
> >>>>> --
> >>>>>
> >>>>> Errors:
> >>>>>
> >>>>> Series: trusty
> >>>>> Charm: cs:mysql
> >>>>>
> >>>>> Series: trusty
> >>>>> Charm: cs:trusty/mysql
> >>>>>
> >>>>> Ok:
> >>>>>
> >>>>> Series: trusty
> >>>>> Charm: ./mysql
> >>>>>
> >>>>>
> >>>>> Case 2
> >>>>> --
> >>>&

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

[Antonio Rosales]

On Monday, March 28, 2016, Ian Booth <ian.bo...@canonical.com> wrote:

> Hey Antonio
>
> I must apologise - the changes didn't make beta3 due to all the work
> needed to
> migrate the CI scripts to test the new hosted model functionality; we ran
> out of
> time to be able to QA the local bundle changes.
>
> I expect this work will be done for beta4.


Completely understood. I'll retest with Beta 4. Thanks for the update.

-Antonio


>
>
>
On 29/03/16 11:04, Antonio Rosales wrote:
> > + Juju list for others awareness
> >
> >
> > On Thu, Mar 10, 2016 at 1:53 PM, Ian Booth <ian.bo...@canonical.com
> <javascript:;>> wrote:
> >> Thanks Rick. Trivial change to make. This work should be in beta3 due
> next week.
> >> The work includes dropping support for local repositories in favour of
> path
> >> based local charm and bundle deployment.
> >
> > Ian,
> > First thanks for working on this feature. Second, I tried this for a
> > local ppc64el deploy which is behind a firewall, and thus local charms
> > are good way forward. I may have got the syntax incorrect and thus
> > wanted to confirm here. What I did was is at:
> > http://paste.ubuntu.com/15547725/
> > Specifically, I set the the charm path to something like:
> > charm: /home/ubuntu/charms/trusty/apache-hadoop-compute-slave
> > However, I got the following error:
> > ERROR cannot deploy bundle: cannot resolve URL
> > "/home/ubuntu/charms/trusty/apache-hadoop-compute-slave": charm or
> > bundle URL has invalid form:
> > "/home/ubuntu/charms/trusty/apache-hadoop-compute-slave"
> >
> > This is on the latest beta3:
> > 2.0-beta3-xenial-ppc64el
> >
> > Any suggestions?
> >
> > -thanks,
> > Antonio
> >
> >
> >>
> >> On 10/03/16 23:37, Rick Harding wrote:
> >>> Thanks Ian, after thinking about it I think what we want to do is
> really
> >>> #2. The reasoning I think is:
> >>>
> >>> 1) we want to make things consistent. The CLI experience is present a
> charm
> >>> and override series with --series=
> >>> 2) more consistent, if you do it with local charms you can always do it
> >>> 3) we want to encourage folks to drop series from the charmstore urls
> and
> >>> worry less about series over time. Just deploy X and let the charm
> author
> >>> pick the default best series. I think we should encourage this in the
> error
> >>> message for #2. "Please remove the series section of the charm url" or
> the
> >>> like when we error on the conflict, pushing users to use the series
> >>> override.
> >>>
> >>> Uros, Francesco, this brings up a point that I think for multi-series
> >>> charms we want the deploy cli snippets to start to drop the series
> part of
> >>> the url as often as we can. If the url doesn't have the series
> specified,
> >>> e.g. jujucharms.com/mysql then the cli command should not either.
> Right now
> >>> I know we add the series/revision info and such. Over time we want to
> try
> >>> to get to as simple a command as possible.
> >>>
> >>> On Thu, Mar 10, 2016 at 7:23 AM Ian Booth <ian.bo...@canonical.com
> <javascript:;>> wrote:
> >>>
> >>>> I've implemented option 1:
> >>>>
> >>>>  error if Series attribute is used at all with a store charm URL
> >>>>
> >>>> Trivial to change if needed.
> >>>>
> >>>> On 10/03/16 12:58, Ian Booth wrote:
> >>>>> Yeah, agreed having 2 ways to specify store series can be suboptimal.
> >>>>> So we have 2 choices:
> >>>>>
> >>>>> 1. error if Series attribute is used at all with a store charm URL
> >>>>> 2. error if the Series attribute is used and conflicts
> >>>>>
> >>>>> Case 1
> >>>>> --
> >>>>>
> >>>>> Errors:
> >>>>>
> >>>>> Series: trusty
> >>>>> Charm: cs:mysql
> >>>>>
> >>>>> Series: trusty
> >>>>> Charm: cs:trusty/mysql
> >>>>>
> >>>>> Ok:
> >>>>>
> >>>>> Series: trusty
> >>>>> Charm: ./mysql
> >>>>>
> >>>>>
> >>>>> Case 2
> >>>>> --
> >>>&

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

[Antonio Rosales]

currently use
>>>>>>>>> cs:xenial/nova-compute
>>>>>>>>> but that's not the case for local charms deployed out of a
>>> directory.
>>>>>>> We
>>>>>>>>> need a
>>>>>>>>> way to allow the series to be specified in that latter case.
>>>>>>>>>
>>>>>>>>> We'll look to make the changes in core initially and can followup
>>> later
>>>>>>>>> with the
>>>>>>>>> GUI etc. The attribute is optional and only really affects bundles
>>> with
>>>>>>>>> local
>>>>>>>>> charms.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 09/03/16 09:53, Ian Booth wrote:
>>>>>>>>>> So to clarify what we'll do. We'll support the same syntax in
>>> bundle
>>>>>>>>> files as we
>>>>>>>>>> do for deploy.
>>>>>>>>>>
>>>>>>>>>> Deploys charm store charms:
>>>>>>>>>>
>>>>>>>>>> $ juju deploy cs:wordpress
>>>>>>>>>> $ juju deploy wordpress
>>>>>>>>>>
>>>>>>>>>> Deploys a local charm from a directory:
>>>>>>>>>>
>>>>>>>>>> $ juju deploy ./charms/wordpress
>>>>>>>>>> $ juju deploy ./wordpress
>>>>>>>>>>
>>>>>>>>>> So below deploys a local nova-compute charm in a directory
>>> co-located
>>>>>>>>> with the
>>>>>>>>>> bundle.yaml file.
>>>>>>>>>>
>>>>>>>>>>  series: trusty
>>>>>>>>>>  services:
>>>>>>>>>>nova-compute:
>>>>>>>>>>  charm: ./nova-compute
>>>>>>>>>>  num_units: 2
>>>>>>>>>>
>>>>>>>>>> This one deploys a charm store charm:
>>>>>>>>>>
>>>>>>>>>>  series: trusty
>>>>>>>>>>  services:
>>>>>>>>>>nova-compute:
>>>>>>>>>>charm: nova-compute
>>>>>>>>>>num_units: 2
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 09/03/16 03:59, Rick Harding wrote:
>>>>>>>>>>> Long term we want to have a pattern when the bundle is a directory
>>>>>>> with
>>>>>>>>>>> local charms in a directory next to the bundles.yaml file. We
>>> could
>>>>>>> not
>>>>>>>>> do
>>>>>>>>>>> this cleanly before the multi-series charms that are just getting
>>> out
>>>>>>>>> the
>>>>>>>>>>> door. I think that bundles with local charms will be suboptimal
>>>>>>> until we
>>>>>>>>>>> can get those bits to line up.
>>>>>>>>>>>
>>>>>>>>>>> I don't think we want to be doing the file based urls, but to
>>> build a
>>>>>>>>>>> pattern that's reusable and makes sense across systems. Creating a
>>>>>>>>> standard
>>>>>>>>>>> pattern I think is the best path forward.
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Mar 8, 2016 at 12:26 PM Martin Packman <
>>>>>>>>> martin.pack...@canonical.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 05/03/2016, Ian Booth <ian.bo...@canonical.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> How will bundles work which reference local charms? Will this
>>>>>>> work as
>>>>>>>>>>>>>> expected where nova-compute is a directory at the same level
>>> as a
>>>>>>>>> bundle
>>>>>>>>>>>>>> file?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ```
>>>>>>>>>>>>>> series: trusty
>>>>>>>>>>>>>> services:
>>>>>>>>>>>>>>   nova-compute:
>>>>>>>>>>>>>> charm: ./nova-compute
>>>>>>>>>>>>>> num_units: 2
>>>>>>>>>>>>>> ```
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The above will work but not until a tweak is made to bundle
>>>>>>>>> deployment to
>>>>>>>>>>>>> interpret a path on disk rather than a url. It's a small change.
>>>>>>> This
>>>>>>>>>>>> would
>>>>>>>>>>>>> be done as part of the work to remove the local repo support.
>>>>>>>>>>>>
>>>>>>>>>>>> Can we keep interpreting the the reference in the bundle as a
>>> url,
>>>>>>> but
>>>>>>>>>>>> start supporting file urls? That seems neater than treating the
>>> cs:
>>>>>>>>>>>> prefix as magic not-a-filename.
>>>>>>>>>>>>
>>>>>>>>>>>> The catch is that there's no sane way of referencing locations
>>>>>>> outside
>>>>>>>>>>>> a base url.
>>>>>>>>>>>>
>>>>>>>>>>>> charm: file:nova-compute
>>>>>>>>>>>>
>>>>>>>>>>>> Works as a reference to a dir inside the base location, but:
>>>>>>>>>>>>
>>>>>>>>>>>> charm: file:../nova-compute
>>>>>>>>>>>>
>>>>>>>>>>>> Will not work as a reference to a sibling directory. And absolute
>>>>>>> file
>>>>>>>>>>>> paths are pretty useless across machines.
>>>>>>>>>>>>
>>>>>>>>>>>> Martin
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> 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



-- 
Antonio Rosales
Ecosystem Engineering
Canonical

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

[Antonio Rosales]

currently use
>>>>>>>>> cs:xenial/nova-compute
>>>>>>>>> but that's not the case for local charms deployed out of a
>>> directory.
>>>>>>> We
>>>>>>>>> need a
>>>>>>>>> way to allow the series to be specified in that latter case.
>>>>>>>>>
>>>>>>>>> We'll look to make the changes in core initially and can followup
>>> later
>>>>>>>>> with the
>>>>>>>>> GUI etc. The attribute is optional and only really affects bundles
>>> with
>>>>>>>>> local
>>>>>>>>> charms.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 09/03/16 09:53, Ian Booth wrote:
>>>>>>>>>> So to clarify what we'll do. We'll support the same syntax in
>>> bundle
>>>>>>>>> files as we
>>>>>>>>>> do for deploy.
>>>>>>>>>>
>>>>>>>>>> Deploys charm store charms:
>>>>>>>>>>
>>>>>>>>>> $ juju deploy cs:wordpress
>>>>>>>>>> $ juju deploy wordpress
>>>>>>>>>>
>>>>>>>>>> Deploys a local charm from a directory:
>>>>>>>>>>
>>>>>>>>>> $ juju deploy ./charms/wordpress
>>>>>>>>>> $ juju deploy ./wordpress
>>>>>>>>>>
>>>>>>>>>> So below deploys a local nova-compute charm in a directory
>>> co-located
>>>>>>>>> with the
>>>>>>>>>> bundle.yaml file.
>>>>>>>>>>
>>>>>>>>>>  series: trusty
>>>>>>>>>>  services:
>>>>>>>>>>nova-compute:
>>>>>>>>>>  charm: ./nova-compute
>>>>>>>>>>  num_units: 2
>>>>>>>>>>
>>>>>>>>>> This one deploys a charm store charm:
>>>>>>>>>>
>>>>>>>>>>  series: trusty
>>>>>>>>>>  services:
>>>>>>>>>>nova-compute:
>>>>>>>>>>charm: nova-compute
>>>>>>>>>>num_units: 2
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 09/03/16 03:59, Rick Harding wrote:
>>>>>>>>>>> Long term we want to have a pattern when the bundle is a directory
>>>>>>> with
>>>>>>>>>>> local charms in a directory next to the bundles.yaml file. We
>>> could
>>>>>>> not
>>>>>>>>> do
>>>>>>>>>>> this cleanly before the multi-series charms that are just getting
>>> out
>>>>>>>>> the
>>>>>>>>>>> door. I think that bundles with local charms will be suboptimal
>>>>>>> until we
>>>>>>>>>>> can get those bits to line up.
>>>>>>>>>>>
>>>>>>>>>>> I don't think we want to be doing the file based urls, but to
>>> build a
>>>>>>>>>>> pattern that's reusable and makes sense across systems. Creating a
>>>>>>>>> standard
>>>>>>>>>>> pattern I think is the best path forward.
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Mar 8, 2016 at 12:26 PM Martin Packman <
>>>>>>>>> martin.pack...@canonical.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 05/03/2016, Ian Booth <ian.bo...@canonical.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> How will bundles work which reference local charms? Will this
>>>>>>> work as
>>>>>>>>>>>>>> expected where nova-compute is a directory at the same level
>>> as a
>>>>>>>>> bundle
>>>>>>>>>>>>>> file?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ```
>>>>>>>>>>>>>> series: trusty
>>>>>>>>>>>>>> services:
>>>>>>>>>>>>>>   nova-compute:
>>>>>>>>>>>>>> charm: ./nova-compute
>>>>>>>>>>>>>> num_units: 2
>>>>>>>>>>>>>> ```
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The above will work but not until a tweak is made to bundle
>>>>>>>>> deployment to
>>>>>>>>>>>>> interpret a path on disk rather than a url. It's a small change.
>>>>>>> This
>>>>>>>>>>>> would
>>>>>>>>>>>>> be done as part of the work to remove the local repo support.
>>>>>>>>>>>>
>>>>>>>>>>>> Can we keep interpreting the the reference in the bundle as a
>>> url,
>>>>>>> but
>>>>>>>>>>>> start supporting file urls? That seems neater than treating the
>>> cs:
>>>>>>>>>>>> prefix as magic not-a-filename.
>>>>>>>>>>>>
>>>>>>>>>>>> The catch is that there's no sane way of referencing locations
>>>>>>> outside
>>>>>>>>>>>> a base url.
>>>>>>>>>>>>
>>>>>>>>>>>> charm: file:nova-compute
>>>>>>>>>>>>
>>>>>>>>>>>> Works as a reference to a dir inside the base location, but:
>>>>>>>>>>>>
>>>>>>>>>>>> charm: file:../nova-compute
>>>>>>>>>>>>
>>>>>>>>>>>> Will not work as a reference to a sibling directory. And absolute
>>>>>>> file
>>>>>>>>>>>> paths are pretty useless across machines.
>>>>>>>>>>>>
>>>>>>>>>>>> Martin
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Juju-dev mailing list
>>>>>>>>>>>> juju-...@lists.ubuntu.com
>>>>>>>>>>>> Modify settings or unsubscribe at:
>>>>>>>>>>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/juju-dev



-- 
Antonio Rosales
Ecosystem Engineering
Canonical

-- 
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

[Antonio Rosales]

On Fri, Mar 18, 2016 at 1:28 PM, Charles Butler
<charles.but...@canonical.com> wrote:
> Big +1 to the categories
>
> What i'd like to see is the policy document move to strong language where we
> can build tooling around the automated checking of policy.
>
> Refactoring the MUSTS and SHOULDS give us a strong lead on that language.
> MUST == has to be satisfied
> SHOULD = area for improvement - (proper use of warn, which wont fail charm
> proof for a change)
>
> eg: We require OSI approved licenses, we can scan the copyright file for
> that with a license bot to find the lingo of approved licenses, otherwise it
> flags for human review. It may be an acceptable license we're not aware of.
>
> The more points in policy we can convert to strongly typed lingo, the more
> targeted and automated we can make portions of policy review, and also
> scopes the mission of ~charmers. A limited resource who is responsible for
> enforcing this document.

Strongly agree. The more binary we make the policy the easier it is
for folks to understand what the need to accomplish to get it
recommended. Plus, it mapd lingo, the more
> targeted and automated we can make portions of policy review, and also
> scopes the mission of ~charmers. A limited resource who is responsible for
> enforcing this document. os well to review queue check list.  Thus in that 
> vein
- Consider dropping the "Must" from the "General Guidelines" as some
point are very objective there.
- Reference Fuctional Testing in the Deployment section
- We should be explicit for the items typically called out that are
needed in readmes, ie steps to smoke test, config options to set,
relations to set, upstream links, and how to get the software

I'll propose a branch with above suggestions, but thought I should
also mail here.

-thanks,
Antonio


>
>
>
> On Fri, Mar 18, 2016 at 11:59 AM Jorge O. Castro <jo...@ubuntu.com> wrote:
>>
>> Hello everyone,
>>
>> With 2.0 around the corner we decided to spend some time cleaning up
>> the page everyone loves to hate, the Juju Charm Store policy:
>>
>> https://jujucharms.com/docs/1.25/authors-charm-policy
>>
>> and here is what I would like to propose:
>>
>>
>> https://github.com/castrojo/docs/blob/master/src/en/authors-charm-policy.md
>>
>> I've done a few things here:
>>
>> - I've separated it from one huge paragraph to sections, General,
>> Testing and Quality requirements, Metadata requirements, and Security
>> requirements.
>> - I've split out things that a charm/bundle MUST do and what it SHOULD
>> do in each section to make it clearer on what is a hard requirement
>> and what is a recommendation.
>> - I've removed most of the Ubuntu-specific jargon and generalized it
>> to include other OSes such as CentOS.
>> - Made documenting interfaces and external dependencies a requirement.
>>
>> There are also some new policies that we need ack from ~charmers in
>> order to implement. Specifically we've made the testing and quality
>> requirements explicit. I've also added a requirement of using Juju
>> Resources (which appears to be undocumented?) for payloads.
>>
>> Recommendations from everyone on what we should include here would be
>> most welcome, specifically our recommendations around Windows charms
>> is non-existent.
>>
>>
>> --
>> Jorge Castro
>> Canonical Ltd.
>> http://jujucharms.com/ - The fastest way to model your service
>>
>> --
>> 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
>



-- 
Antonio Rosales
Ecosystem Engineering
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.0~ Local LXD provider workflows are awesome!

[Antonio Rosales]

On Wed, Feb 3, 2016 at 1:09 PM, James Page <james.p...@ubuntu.com> wrote:
> Hi All
>
> I've been using Juju 2.0 (built from source with an in-flight patch for LXD
> 2.0 right now - but that should be resolved soon) with the local LXD
> provider on Ubuntu Xenial development to test some work we've been doing to
> get OpenStack running on-top of LXD in a single machine.
>
> That's now working quite well (a few rough edges), but is not the main topic
> for my post.

This is solid, thanks for sharing here.

-Antonio

>
> 1) Multiple models, single controller
>
> Alongside LXD support, you can also create multiple models against a single
> controller, so I've been creating models to deploy, test and review specific
> pieces of work (reviewing the midonet charms right now for example):
>
>   juju bootstrap
>   juju create-model midonet-review
>   juju switch midonet-review
>
>  and then deploy away;  Not having to re-bootstrap a controller
> every-time I want to tear-down and redeploy, or push something new up for
> test optimizes my workflow nicely.
>
> 2) Tweaking container profiles
>
> For each model, Juju creates a profile in LXD (named juju-)- and
> its quite possible to make additions to that profile for your specific model
> requirements - here's the one we wrote for openstack-on-lxd:
>
> name: juju-openstack-on-lxd
> config:
>   boot.autostart: "true"
>   linux.kernel_modules: openvswitch,nbd,ip_tables,ip6_tables
>   security.nesting: "true"
>   security.privileged: "true"
> devices:
>   eth0:
> mtu: "9000"
> name: eth0
> nictype: bridged
> parent: lxcbr0
> type: nic
>   eth1:
> mtu: "9000"
> name: eth1
> nictype: bridged
> parent: lxcbr0
> type: nic
>   kvm:
> path: /dev/kvm
> type: unix-char
>   root:
> path: /
> type: disk
>   tun:
> path: /dev/net/tun
> type: unix-char
>
> This adds a-lot to the default profile, but at a high level ensures that
> each container gets two network interfaces with a high mtu to avoid packet
> fragmentation, can access a few devices required for virt networking and
> process management - and also switches the container into 'privileged' mode
> that we need for Open vSwitch support in a container right now (Tycho is
> working on fixing that so we can run unprivileged).  Read more about LXD
> profiles here:
>
>   https://github.com/lxc/lxd/blob/master/specs/configuration.md
>
> Editing is super easy - 'lxc profile edit '.
>
> 3) Pause/Resume containers
>
> I've found a few bits that LXD provides outside of Juju quite useful as well
> - specifically I've been away from regular power for the last few days, so
> I've been using the 'pause' feature of containers to freeze containers,
> stopping CPU consumption and making my battery last a alot longer without
> destroying and re-deploying the environment (which would consume far more
> battery anyway) - here's 'pause-juju':
>
>   for container in `lxc list | grep RUNNING | grep juju | awk '{ print $2
> }'`; do
>   lxc pause $container
>   done
>
> and 'resume-juju':
>
>   for container in `lxc list | grep FROZEN | grep juju | awk '{ print $2
> }'`; do
>   lxc start $container
>   done
>
> I'm doing this outside of Juju right now - but I think it would make a great
> feature!
>
> All container processes still consume memory, but stop consuming cpu cycles
> until resumed.
>
> Oh - and use the ZFS backend for LXD - its superfast!:
>
>
> https://insights.ubuntu.com/2015/11/06/using-lxd-with-a-file-based-zfs-pool-on-ubuntu-wily/
>
> Hope people find that all useful!
>
> Cheers
>
> James
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>



-- 
Antonio Rosales
Ecosystem Engineering
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju devel 2.0-alpha1 is available for testing

[Antonio Rosales]

On Thursday, January 21, 2016, Marco Ceppi 
wrote:

> Wow! A lot to play with tomorrow. Thanks for the release core team!
>
+,1 some solid bits to start testing with. Looking forward to exploring.

Thanks juju-core folks.

-Antonio


> On Thu, Jan 21, 2016, 5:06 PM Curtis Hovey-Canonical  > wrote:
>
>> # juju-core 2.0-alpha1
>>
>> A new development release of Juju, juju-core 2.0-alpha1, is now available.
>> This release replaces version 1.26-alpha3.
>>
>>
>> ## Getting Juju
>>
>> juju-core 2.0-alpha1 is available for Xenial and backported to earlier
>> series in the following PPA:
>>
>> https://launchpad.net/~juju/+archive/devel
>>
>> Windows, Centos, and OS X users will find installers at:
>>
>> https://launchpad.net/juju-core/+milestone/2.0-alpha1
>>
>> Development releases use the "devel" simple-streams. You must configure
>> the 'agent-stream' option in your environments.yaml to use the matching
>> juju agents.
>>
>> Upgrading from older releases to this development release is not
>> supported.
>>
>>
>> ## Notable Changes
>>
>> * Terminology
>> * Testing Advice
>> * Command Name Changes
>> * Multi-Model Support Active by Default
>> * Native Support for Charm Bundles
>> * Multi Series Charms
>> * Improved Local Charm Deployment
>> * LXD Provider
>> * Microsoft Azure Resource Manager Provider
>> * Bootstrap Constraints, Series
>> * Juju Logging Improvements
>> * Unit Agent Improvements
>> * API Login with Macaroons
>> * MAAS 1.8 Compatibility
>>
>>
>> ### Terminology
>>
>> In Juju 2.0, environments will now be referred to as "models".  Commands
>> which referenced "environments" will now reference "models".  Example:
>>
>> juju get-environment
>>
>> will become
>>
>> juju get-model
>>
>>
>> The "state-server" from Juju 1.x becomes a "controller" in 2.0. The
>> change in terminology will be done across several alphas, so messages
>> and errors provided by juju may still reference "environments".
>>
>>
>> ### Testing Advice
>>
>> Juju 2.0's new features and behaviours will confuse older Juju clients.
>> It is best to create a new juju home to ensure you can revert to a 1.x
>> Juju client. You can move an existing .juju/ directory out of the way or
>> create a new directory and export it for Juju to find like so:
>>
>> export JUJU_HOME=~/new-juju-testing
>>
>> If you accidentally use Juju 2.0 with a Juju 1.x home, and Juju 1.x
>> reports problems with the environment, you can delete ~/.go-cookie and
>> the environments/cache.yaml in the Juju home dir to unconfuse Juju 1.x.
>> Juju 2.0 will store its data in a new location soon.
>>
>> It is not possible to test an upgrade from Juju 1.x to 2.0 at this time.
>> Juju will support this in future releases.
>>
>>
>> ### Command Name Changes
>>
>> After a while experimenting with nested command structures, the decision
>> was made to go back to a flat command namespace as the nested commands
>> always felt clumsy and awkward when being used even though they seemed
>> like a good idea.
>>
>> So, we have the following changes:
>>
>> 1.25 command   2.0-alpha1 command
>>
>> juju environment destroy   juju destroy-environment *
>> juju environment get   juju get-environment **
>> juju environment get-constraints   juju get-constraints **
>> juju environment retry-provisioningjuju retry-provisioning
>> juju environment set   juju set-environment **
>> juju environment set-constraints   juju set-constraints **
>> juju environment share juju share-environment
>> juju environment unset juju unset-environment **
>> juju environment unshare   juju unshare-environment
>> juju environment users juju list-shares
>> juju user add  juju add-user
>> juju user change-password  juju change-user-password
>> juju user credentials  juju get-user-credentials
>> juju user disable  juju disable-user
>> juju user enable   juju enable-user
>> juju user info juju show-user
>> juju user list juju list-users
>>
>> * the behaviour of destroy-environment has changed, see the section on
>> controllers below
>> ** these commands existed at the top level before but become the
>> recommended approach again.
>>
>> And for the extra commands previously under the "jes" feature flag but
>> now available out of the box:
>>
>> juju system create-environment juju create-environment
>> juju system destroyjuju destroy-controller
>> juju system environments   juju list-environments
>> juju system kill   juju kill-controller
>> juju system list   juju list-controllers
>> juju system list-blocksjuju list-all-blocks
>> 

Re: Juju for Redhat linux

[Antonio Rosales]

On Mon, Nov 16, 2015 at 9:54 AM, José Antonio Rey <j...@ubuntu.com> wrote:
> Hello,
>
> No, unfortunately not. The only supported OSs are Ubuntu and CentOS, and I'm
> not aware of any work in progress towards Red Hat. I'm sorry!

For completeness, Microsoft Windows is also a supported by Juju to
deploy Window based workloads.

-thanks,
Antonio

>
> --
> José Antonio Rey
>
> On Mon, Nov 16, 2015 at 10:21 AM <dinesh.senap...@wipro.com> wrote:
>>
>> Hi,
>>
>> Does Juju work on Redhat linux platform ?
>>
>> Regards,
>> Dinesh
>>
>> The information contained in this electronic message and any attachments
>> to this message are intended for the exclusive use of the addressee(s) and
>> may contain proprietary, confidential or privileged information. If you are
>> not the intended recipient, you should not disseminate, distribute or copy
>> this e-mail. Please notify the sender immediately and destroy all copies of
>> this message and any attachments. WARNING: Computer viruses can be
>> transmitted via email. The recipient should check this email and any
>> attachments for the presence of viruses. The company accepts no liability
>> for any damage caused by any virus transmitted by this email. www.wipro.com
>> --
>> 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
>



-- 
Antonio Rosales
Ecosystem Engineering
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [Review Queue] postgresql

[Antonio Rosales]

On Wed, Nov 11, 2015 at 2:31 PM, Matt Bruzek
 wrote:
> I reviewed the rewrite of the postgresql charm today.  It is finally passing
> tests in the automated test runner but I also ran bundletester on a local
> KVM provider where it too a REALLY long time but all 12 tests passed!
>
> +1 LGTM so I merged it today.
>
> You can read more about the proposal here:
> https://code.launchpad.net/~stub/charms/trusty/postgresql/rewrite/+merge/267646
>
> A big thank you to Stuart Bishop and Tim for all the cycles with our team to
> get the postgresql tests to run in automation!

Great to see the tests passing!

-Antonio

>
>- Matt Bruzek 
>
> --
> 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: UOS 15.11 - Big Data session

[Antonio Rosales]

Thanks Cory, I am also forwarding onto the Juju list if folks aren't
yet on the bigdata list.

-thanks,
Antonio


On Wed, Nov 4, 2015 at 10:23 AM, Cory Johns <cory.jo...@canonical.com> wrote:
> I meant to send this out yesterday, but we're doing a Big Data session for
> the Ubuntu Online Summit today, in about 2 hours (19:00 UTC).
>
> Links to join the Hangout to participate, or just watch the session live can
> be found at:
>
> http://summit.ubuntu.com/uos-1511/meeting/22580/deploying-your-own-big-data-stack/
>
> You can also join us in #ubuntu-uos-cloud on Freenode on IRC to ask
> questions or provide feedback.
>
> --
> Bigdata mailing list
> bigd...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/bigdata
>



-- 
Antonio Rosales
Ecosystem Engineering
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: User creation with cloud-init

[Antonio Rosales]

On Sun, Oct 11, 2015 at 7:08 AM, Martin Packman
<martin.pack...@canonical.com> wrote:
> I proposed a branch this week that alters how juju uses cloud-init to
> create the ubuntu user when provisioning a machine. I've had code
> review, but would appreciate further feedback:
>
> <http://reviews.vapour.ws/r/2860/>
>
> The main aim here is to avoid depending on the /etc/cloud/cloud.cfg in
> the image, but keep the logic unified across *nix systems. This
> includes a CentOS behaviour change that I hope is okay, removing the
> shell script use setup and just using cloud-config.

I see we have https://bugs.launchpad.net/juju-core/+bug/1492066 fixed
committed for 1.25 (thanks Dimiter), does this branch resolve any
other known issues with deploying *Nix Specifically CentOS with Juju,
or are there others we should identify here?

-thanks,
Antonio

>
> There are still a couple of things to be nervous about. The exisitng
> container creation config is very much tied to ubuntu still, and I'm
> not completely confident of stability across series for cloud-init
> versions or default groups.
>
> My intention is to get a reasonable amount of testing in advance of
> landing the branch, but comments welcome as well.
>
> Martin
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/juju-dev



-- 
Antonio Rosales
Ecosystem Engineering
Canonical

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju stable 1.23.2 is released

[Antonio Rosales]

   * Juju needs to support systemd for = vivid
 Lp 1409639

   * Joyent provider uploads user's private ssh key by default
 Lp 1415671

   * Unable to bootstrap on cn-north-1
 Lp 1415693

   * Debug messages show when only info was asked for
 Lp 1421237

   * Juju default logging leaks credentials
 Lp 1423272

   * Juju resolve doesn't recognize error state
 Lp 1424069

   * Juju status --format=tabular
 Lp 1424590

   * Ec2 provider unaware of c3 types in sa-east-1
 Lp 1427840

   * Ec2 eu-central-1 region not in provider
 Lp 1428117

   * Ec2 provider does not include c4 instance family
 Lp 1428119

   * Allwatcher does not remove last closed port for a unit, last removed
 service config
 Lp 1428430

   * Make kvm containers addressable (esp. on maas)
 Lp 1431130

   * Fix container addressability issues with cloud-init, precise, when
 lxc-clone is true
 Lp 1431134

   * Dhcp's option interface-mtu 9000 is being ignored on bridge
 interface br0
 Lp 1403955

   * Juju-1.23beta3 breaks glance - mysql relation when glance is
 hosted in a container
 Lp 1441811

   * Juju ensure-availability should be able to target existing
 machines
 Lp 1394755

   * Juju 1.23b4 vivid panic: runtime error: invalid memory address or
 nil pointer dereference
 Lp 1443541

   * 1.23-beta4 sporadically fails autotests
 Lp 1443440

   * 1.23.1: bootstrap failure, vivid, local provider
 Lp 1447446

   * Hooks don't fire after upgrade 1.23.0
 Lp 1447846

 Finally

 We encourage everyone to subscribe the mailing list at
 juju-...@lists.canonical.com, or join us on #juju-dev on freenode.


 --
 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



-- 
Antonio Rosales
Ecosystem Engineering
Canonical

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Review/Re-review of charms submitted by ibmcharmers

[Antonio Rosales]

On Wed, Apr 15, 2015 at 7:33 PM, Johnny Shieh jsh...@us.ibm.com wrote:
 Please review the following submitted charms:

Hello, and thanks for you contributions to the Juju Charm community in
the xCAT charm and following up on the WebSphere MQ charm.
Encapsulating your team's IBM software expertise into these charms is
valuable to the Juju Ecosystem as well the IBM ecosystem. Looking
forward to see the solutions Juju users put together with MQ, xCAT,
and GPFS now that they are in the Charm store.


 IBM MQ (formerly known as WebSphere MQ)
 https://bugs.launchpad.net/charms/+bug/1432489

A commented added. The readme looks to be updated with the feedback
given, but we are still coordinating binaries for testing. For review
we are leveraging the 90 day trail, but we also need to investigate
longer term binaries for Charm CI testing.


 This has been commented by the charm team.  A response and change has been
 provided.
 Asking for re-review.

 GPFS
 https://bugs.launchpad.net/charms/+bug/1431045

Comment added to the bug. Outstanding item is coordinating the binary
for deployment verification.


 This has been commented by the charm team.  A response and change has been
 provided.
 Asking for re-review.

 xCAT
 https://bugs.launchpad.net/charms/+bug/1441622

Comment added to the bug. Error on downloading the .deb needs to be
resolved as well as some minor fixes.

-thanks,

Antonio





 
 Johnny Shieh
 CTO Office - Software Defined Systems
 jsh...@us.ibm.com
 Mobile: 512-680-1375


 --
 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: Kuberentes provider code has landed in MASTER!

[Antonio Rosales]

On Thu, Apr 2, 2015 at 10:36 AM, Charles Butler
charles.but...@canonical.com wrote:
 Greetings,

 As some of you may know the new-workloads eco team has been working
 dilligently with Google upstream to land Juju as an officially supported
 provider in the Kubernetes project. We've just officially landed our first
 code PR that enables juju in the cluster-up (the official kubernetes
 deployment scripts)

 https://github.com/GoogleCloudPlatform/kubernetes/pull/5414

 I'm very proud to announce we are now ready to start iterating faster, and
 landed more features against the kubernetes charms than before. We are
 excited and looking to a great future being included in the upstream
 repository.

 Currently this will deploy the 0.8.1 release of juju, and can be
 accomplished by:

 cloning the kubernetes project

 export KUBERNETES_PROVIDER=juju
 cluster/kube-up.sh


 This will fire up juju-quickstart to populate details if there is no
 current-environment file in $JUJU_HOME.

 The rest is a fully automated deployment of the k8's charms to setup a
 micro-cluster consisting of 1 master, and 2 minions.

 If you try this and have any feedback we welcome it at the bundle repository

 https://github.com/whitmo/bundle-kubernetes

 Additionally we have a full fledge documentation suite setup here:

 http://whitmo.github.io/bundle-kubernetes/

Thanks for sharing this milestone complete with docs for everyone to
try and give feedback. If folks haven't tried Kubernetes no better
time than the present with Juju.

-Antonio


 All the best,


 Charles Butler charles.but...@canonical.com - Juju Charmer
 Come see the future of datacenter orchestration: http://jujucharms.com

 --
 Cloud mailing list
 cl...@lists.canonical.com
 Modify settings or unsubscribe at:
 https://lists.canonical.com/mailman/listinfo/cloud


-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] IBM GPFS, IBM MQ

[Antonio Rosales]

GPFS
https://bugs.launchpad.net/charms/+bug/1431045
Comments centered around the instructions on how to obtain binaries in
the README. Additional work and testing needed before +1 for
recommended status

MQ
https://bugs.launchpad.net/charms/+bug/1432489
Comments centered around the instructions on how to obtain binaries in
the README. Additional work and testing needed before +1 for
recommended status.

thanks,
-- 
Antonio Rosales
Juju Ecosystem
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] AppScale, IBM MQ, IBM GPFS, Ubuntu, RabbitMQ

[Antonio Rosales]

New Charm AppScale.
https://bugs.launchpad.net/charms/+bug/1424335
The charm overall looked good, and deployed as described.  I had a few
small suggestions, however I recommeded this one to be accepted into
the charm store.

New Charm IBM MQ
https://bugs.launchpad.net/charms/+bug/1432489
Working with IBM to figure out the best way to deliver the licensed binaries.

New Charm IBM GPFS
https://bugs.launchpad.net/charms/+bug/1431045
Also working with IBM on this charm to figure out the best way to
deliver the licensed binaries.

Update to Ubuntu
https://code.launchpad.net/~cbjchen/charms/trusty/ubuntu/lxc-network-config/+merge/250666
This update brought a config option to the Ubuntu charm to create a
new network for LXC. I updated the README with how to use the config
option, made the option false by default, and wrote a test to cover
the new config option. Post those updates I recommended the update be
merged in.

Update RabbitMQ
https://code.launchpad.net/~brad-marshall/charms/trusty/rabbitmq-server/nagios-fixes-sync-charmhelpers/+merge/251551
Adam found some upstream issues, but those are being address. Ultimately a +1.

Also sync'ed up with Nicopace and Marco on a few of his outstanding
charm MPs around charm testing.

thanks,
-- 
Antonio Rosales
Juju Ecosystem
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: systemd support in juju

[Antonio Rosales]

Alexis,
Thanks for sending this out I am also cc'ing juju list as this has an
impact on charm authors.

Charm Authors,
If your charm uses start, stop, restart, initctl for service
lifecycle management you'll need to update your charm for Vivid(15.04)
and greater. Recommended charms are only published on the LTS
branches, however if you are targeting 16.04 or wanting to take
advantage of a recent OS for your charm (15.04 and greater), perhaps
arch enablement reasons, you'll need to ensure your charm supports
Systemd.

Note, the below resources and we'll be working on adding some
additional information to jujucharms.com/docs.

-thanks,

On Thu, Mar 12, 2015 at 5:27 PM, Alexis Bruemmer
alexis.bruem...@canonical.com wrote:
 Hi All,

 systemd support in juju has been developed and currently is in trunk.  It
 will be available in the 1.23 release scheduled to go beta next week.
 Upstart will continue to be supported as well.  However, versions of juju
 prior to 1.23 will not support systemd.  This means that these versions
 cannot run on the latest vivid images without first switching to upstart.

 More information regarding systemd support can be found at:

 https://bugs.launchpad.net/juju-core/+bug/1409639

 Also below are some notes addressing points several folks have asked about
 over the past month.

 The systemd support is new so please do use the 1.23-beta once available
 next week and if you encounter any problems file a bug.  As always juju
 developers are available on #juju-dev or this mailing list if you have
 questions.

 Thanks!
 Alexis

  Notes
 ==

 Running Older juju on vivid
 ==

 In order to use juju 1.22 and earlier on vivid the host must be
 updated to boot with upstart. This can be done by running sudo
 apt-get install upstart followed by sudo update-grub.  As well, a
 vivid host may be booted with upstart for a single boot.  Upon
 booting, in the grub menu select Advanced options for Ubuntu and
 then Ubuntu, with Linux ... (upstart).

 We are working on updating the dist packages for earlier versions of
 juju to specifically require upstart.

 Charms
 =

 Since charms are released on a per-series basis, there is no immediate
 impact from vivid.  The only impact relative to systemd on vivid will
 be to the effort of updating charms for release on vivid.  Most charms
 will be unaffected.  Those that are will be those that currently
 install their own upstart scripts or call upstart-specific commands
 (start, stop, restart, initctl).  Those that call more generic
 commands like service are fine.

 Local Provider
 

 There is a known issue where vivid (systemd) LXC containers on
 non-vivid hosts will not boot.  See
 https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1347020.  This has
 a direct impact on using local provider on non-vivid hosts under those
 circumstances.  However, everything works fine if local provider is
 run on a vivid host.

 There is also an issue with using lxc-create to create vivid
 containers using the ubuntu-cloud template  on a non-vivid host, if
 certain packages have not been updated.  See
 https://bugs.launchpad.net/ubuntu/+source/cloud-utils/+bug/1062671.
 This may impact some users of local provider.

 Discovery
 =

 juju decides at run-time on which init system to use.  For local hosts
 this involves inspecting the host and falling back to inferring the
 init system from the juju version information.  For cloud-init the
 init system is deduced strictly from the juju version information
 defined for the to-be-created instance.  Trusty and earlier indicates
 upstart should be used and vivid and later indicates systemd.
 However, there is a feature flag which may be used to force vivid and
 later to use upstart.  Set JUJU_DEV_FEATURE_FLAGS = legacy-upstart in your
 shell environment.

 Resources
 ==
 * https://wiki.ubuntu.com/SystemdForUpstartUsers




 --
 Alexis Bruemmer
 Juju Core Manager, Canonical Ltd.
 (503) 686-5018
 alexis.bruem...@canonical.com

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev




-- 
Antonio Rosales
Juju Ecosystem
Canonical

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: new releases: juju-gui, juju-quickstart, and jujucharms.com

[Antonio Rosales]

Thanks for continued work to address bug we have log and make
jujuchrms.com and even better site. The API is also a welcome update
too.

-Antonio

On Wed, Jan 14, 2015 at 2:36 PM, Rick Harding
rick.hard...@canonical.com wrote:
 The UI Engineering team would like to let everyone know we had a release
 landslide today.


 First, there’s a new Juju GUI (1.3.0) release in preparation for 1.21 that
 supports the new user code in 1.21. This means that when that lands the GUI
 will support logging in with newly created users. The GUI has also started
 to port to the new charmstore v4 api so things like search is a LOT faster.
 There’s some changes to the sidebar as we adapt to the new API and we’ll be
 continuing this work to improve the GUI’s use of the charmstore API
 throughout. Soon we’ll start to default to the added services bar for live
 environments and deprecate the old ‘interesting’ sidebar for all cases but
 the demo GUI.


 https://jujugui.wordpress.com/2015/01/14/juju-gui-1-3-0-release/


 Second, there’s an update to juju-quickstart that will also support
 importing those .jenv files created from the new user commands and has a
 couple of other fixes. It’ll always deploy the latest gui. It also is an
 initial release for Vivid.


 https://jujugui.wordpress.com/2015/01/14/juju-quickstart-1-6-0/


 Finally, we also release updates to the jujucharms.com website.


 Added support for twitter cards when sharing (not complete we still have to
 finish registration of the site with twitter)

 Clean up dupe search results

 A number of other bug fixes on the front end

 Improve the bundle visualizations (there’s one more fix coming to finish
 that work)

 Ensure that stats and revision history are consistent with other back ends.


 We’ll be doing one small release again tomorrow. We’ve found that there’s a
 bug in our juju docs updating that wasn’t quite fixed all the way that we’ll
 get into a tiny release update tomorrow.


 New charmstore API:


 One thing to mention is that we’re now ready for all of you to start using
 the new charmstore API. It’s what we use to power the jujucharms.com website
 and are working to update the Juju GUI to use for all it’s data needs. You
 can find api docs for the API at:


 https://github.com/juju/charmstore/blob/v4/docs/API.md


 Please feel free to use this API for all your scripts and tooling. If you
 have any questions on using the API make sure to stop by the #juju-gui irc
 channel and ask. We’ll be happy to help.


 We’ll be looking to release a python client for the API very soon and we’re
 working to make sure the use of the API in the GUI is done in a way that we
 can pull out a JS based API client as well. Once those are released we’ll
 send an email and welcome any updates and improvements to those clients. If
 you want to beta test those, again, hit us up in irc and we’ll be happy to
 get your some early access.


 Thanks for the great support everyone and we hope today’s releases of the
 updated GUI, Quickstart, and Jujucharms.com are welcome improvements! As
 always, please try it out and let us know about any issues or suggestions
 you have at: https://github.com/CanonicalLtd/jujucharms.com/issues


 https://jujugui.wordpress.com/2015/01/14/new-jujucharms-com-release-jan-14th/


 Rick Harding

 Juju UI Engineering

 --
 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

[Review Queue] OpenID/SSO, Charm Testing, and Queue Scrubbing

[Antonio Rosales]

Happy 2015! I hope everyone new year is off to a good start.

This week I spent some time on the following reviews:

OpenID/SSO Subordinate Charm
Nice charm from the PES Tools  Certification Canonical team. My major
comments were around adding tests and sprucing up the readme a bit.
Pending adding charm tests this charm looks to be ready for a final
review by a charmer and acceptance into the recommeded charm store.
https://bugs.launchpad.net/charms/+bug/1396237

Pinged Marco on ensuring the following charms dropped out of the review queue:
Trusty Lamp: https://bugs.launchpad.net/charms/+bug/1387467
Trusty pythin-django: https://bugs.launchpad.net/charms/+bug/1387465

The following charms had MPs for adding tests.
https://code.launchpad.net/~marcoceppi/charms/precise/seafile/tests/+merge/240964
https://code.launchpad.net/~marcoceppi/charms/precise/opentsdb/tests/+merge/240984
https://code.launchpad.net/~marcoceppi/charms/precise/thinkup/tests/+merge/240894
https://code.launchpad.net/~mbruzek/charms/precise/newrelic-php/tests/+merge/240983
https://code.launchpad.net/~tvansteenburgh/charms/trusty/rabbitmq-server/add-amulet-test/+merge/245766
https://code.launchpad.net/~nicopace/charms/trusty/rabbitmq-server/10-outofthebox-testing/+merge/245871

 Even though the charm is failing tests I suggest to accept these
charm test MP for the reasons listed in the MPs. My overall reasoning
is as follows:
  1. A test is still valid even if the results aren't positive.
  2. Having charm tests provides the first step to helping the charm
author and community fix the charm. Specifically by providing a
reproducible failure.
  3. The tests are seed (basic) tests that an interested person can
build off of.
  4. As fixes are made to this charm automating charm testing will be
able to run additional tests in addition to charm proof.
  5. Having basic tests, as demonstrated here, helps ensure the charm
is in a working (deployable) state given this charm is a recommended
charm. A test failure can prompt a bug the charm author can take
action on. The charm author may not have been aware of the bug had the
charm not had even basic deployment tests.

I also added specific comments for each MP. In discussion with
~charmers in #juju the folks who responded were a +1 as long as the
test itself was valid and not missing any config values since the
tests were auto-generated.


thanks,
-- 
Antonio Rosales
Juju Ecosystem
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: GCE provider, successful bootstrap and deploy

[Antonio Rosales]

On Wed, Jan 7, 2015 at 3:37 PM, Kapil Thangavelu
kapil.thangav...@canonical.com wrote:
 awesome!

+1 and great to hear. Thanks for the work and updating here.

-Antonio


 On Wed, Jan 7, 2015 at 2:36 PM, Tim Penhey tim.pen...@canonical.com wrote:

 \o/ Well done team!



 On 08/01/15 11:17, Wayne Witzel wrote:
  Eric Snow and myself have recently been working on the GCE provider. As
  of today, we have officially bootstrapped and deployed and setup a
  Wordpress instance and related MySQL instance.
 
  We are still manually working around some issues with GCE images and
  cloud-init. The issue is fixed and merged, we are just waiting for that
  to be SRU'd in to trusty and utopic.
 
  We are now working on getting better test coverage in place and
  addressing remaining TODOs that we left as we were writing code.
 
  Our branch is at: https://github.com/wwitzel3/juju/tree/ww3-gce
 
  --
  Wayne Witzel III
  wayne.wit...@canonical.com mailto:wayne.wit...@canonical.com
 
 


 --
 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


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: [Calico] Project Calico and Juju Charms

[Antonio Rosales]

For those of you looking for the bundle it is at:
http://www.mail-archive.com/calico@lists.projectcalico.org/msg00081.html

CoryB,
Thanks to you and the Project Calico or sharing this solution, and
your contribution to the Juju community.

I saw the mail list stripped your bundle. You can also share your
bundle in LP and have it ingested by the charm store. The process is
documented at:
https://jujucharms.com/docs/charms-bundles#creating-a-bundle

-thanks,
Antonio

On Fri, Dec 12, 2014 at 12:38 PM, Kapil Thangavelu
kapil.thangav...@canonical.com wrote:

 -- Forwarded message --
 From: Cory Benfield cory.benfi...@metaswitch.com
 Date: Fri, Dec 12, 2014 at 4:26 AM
 Subject: [Calico] Project Calico and Juju Charms
 To: cal...@lists.projectcalico.org cal...@lists.projectcalico.org


 Hi everybody,

 I'm excited to announce that, after a fairly substantial amount of work, our
 first preview release of Juju Charms for Project Calico is available!

 Juju is a tool written by Canonical that makes it extremely easy to build
 and orchestrate complex services. One of its most powerful features is that
 it can combine with Metal-as-a-Service, another Canonical tool, to make it
 extremely simple to deploy OpenStack in a number of configurations.

 For the past couple of months we've been working on making it possible to
 build an OpenStack deployment using Juju that uses Calico to provide the
 OpenStack networking. Today marks the public availability of the first set
 of beta charms for doing just that. As of right now you can go online and
 get started with OpenStack Calico using Juju. It's never been easier!

 If you've already got a MAAS + Juju system up and running, you can get
 started right now. Attached to this email is the bundle we sent to the
 OpenStack Interoperability Lab. You should be able to drag and drop this
 bundle into your Juju GUI and immediately get OpenStack with Calico running.
 This particular bundle deploys OpenStack very densely, loading almost all
 the management services onto a single server, and using two more to act as
 compute nodes. If you want a more spread out deployment, feel free to edit
 the bundle: if you need assistance in doing that, please don't hesitate to
 ask for help on this list.

 If you're not familiar with Juju or MAAS and want to give them a try, you
 can find out more on the Juju website[0] and the MAAS website[1]. Both
 products are free and open source, and are absolutely worth checking out.

 The source code for the charms is available on Launchpad. The links are
 below[2-7].

 In the next few weeks we aim to get our modifications to existing charms
 upstreamed into those existing charms. We also plan to add our custom charms
 to the charm store, though that will require a bit more work. The eventual
 goal is that you will be able to install OpenStack with Calico seamlessly
 with Juju, making it easier than ever to simplify and scale your OpenStack
 deployment.

 Keep watching this space!

 Cory (on behalf of the Project Calico team).

 [0]: https://jujucharms.com/
 [1]: https://maas.ubuntu.com/
 [2]: https://code.launchpad.net/~cory-benfield/charms/trusty/bird/trunk
 [3]:
 https://code.launchpad.net/~cory-benfield/charms/trusty/calico-acl-manager/trunk
 [4]:
 https://code.launchpad.net/~cory-benfield/charms/trusty/neutron-api/trunk
 [5]:
 https://code.launchpad.net/~cory-benfield/charms/trusty/nova-cloud-controller/trunk
 [6]:
 https://code.launchpad.net/~cory-benfield/charms/trusty/nova-compute/trunk
 [7]:
 https://code.launchpad.net/~cory-benfield/charms/trusty/neutron-calico/trunk

 ___
 Calico mailing list
 cal...@lists.projectcalico.org
 http://lists.projectcalico.org/listinfo/calico



 --
 Juju mailing list
 Juju@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju




-- 
Antonio Rosales
Juju Ecosystem
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Released update to jujucharms.com today the 10th.

[Antonio Rosales]

Rick and UI team, thanks for getting this fixes in. We had gotten a
few questions on download stats so thanks for addressing that and
posting here for everyone's info on the fix.

-Antonio

On Wed, Dec 10, 2014 at 12:04 PM, Rick Harding
rick.hard...@canonical.com wrote:
 Heads up that a new release has hit jujucharms.com. This contains several
 smaller things but you might be interested. Please check it out and let us
 know if you hit any issues.

 http://jujugui.wordpress.com/2014/12/10/new-jujucharms-com-release-dec-10th/

 Add blog support. https://jujucharms.com/community/blog
 Fix ‘show more’ revisions link on the details page.
 Correct the bug link in the footer to the correct location.
 Add sorting for search results.
 Redesign the ‘Get started’ page.
 Import loegacy download stats for charms (bundles coming in next release)
 Improve search results rankings.
 Improve charm icons by auto adding viewbox attribute when missing.
 UI tweaks in the Juju GUI  for the Inspector, Canvas, and Machine View.
 Add animations to the Added Services bar interactions.


 The UI Engineering team.

 --
 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: kubernetes

[Antonio Rosales]

On Thu, Oct 30, 2014 at 2:00 PM, Kapil Thangavelu
kapil.thangav...@canonical.com wrote:

 Hi Folks,

 I wrote up some kubernetes charms and a bundle to make it easy to deploy
 kubernetes on different clouds and baremetal via juju. Kubernetes is a
 docker container management system from google with support for health
 checks, round robin upgrades, load balancers, etc.

 To get started you can use juju-quickstart or juju-deployer ala

 juju-quickstart  \
 https://raw.githubusercontent.com/kapilt/bundle-kubernetes/master/bundles.yaml

 more instructions over here https://github.com/kapilt/bundle-kubernetes
 and of course at the project site
 https://github.com/GoogleCloudPlatform/kubernetes

Solid work Kapil. Thanks for getting this charmed out so of folks can
easily give Kubernetes a spin.

-Antonio


 cheers,

 Kapil

 --
 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: [Review Queue] hpcc

[Antonio Rosales]

On Thu, Oct 23, 2014 at 5:22 PM, Charles Butler
charles.but...@canonical.com wrote:
 I've been watching this one develop, and it was indeed a long road to
 promulgation.

 Congrats on the win Xiaoming Wang!

+1, well done charm Xiaoming Wang.

-Antonio


 Go Big Data indeed!

 On Thu, Oct 23, 2014 at 2:06 PM, Matt Bruzek matthew.bru...@canonical.com
 wrote:

 I spent some time reviewing the High Performance Computing Cluster (HPCC)
 charm today.  For those that do not know HPCC is a player in Big Data as an
 alternative platform to Hadoop.

 The review passed and hpcc is the newest charm in the charm store!

 https://bugs.launchpad.net/charms/+bug/1272083

 This charm requires a minimum of 4GB nodes to deploy all the thor and
 roxie processes so you will have to use the constraints flag to deploy it
 from juju on a cloud properly.  All this is documented in the well written
 README.md file inside the charm.

 Thanks to the developer Xiaoming Wang for all the work and the patience
 with the review process!

 Go big data!

- Matt Bruzek matthew.bru...@canonical.com

 --
 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




-- 
Antonio Rosales
Juju Ecosystem
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Tags for charms and bundles

[Antonio Rosales]

On Tue, Oct 7, 2014 at 12:18 PM, Jorge O. Castro jo...@ubuntu.com wrote:
 Hello everyone,

 I've been working with the design team on how we can improve what are
 currently called categories. We'd like to propose the following things
 as new charm policy:

 - Rename categories to tags
 - Add a description field to bundles, the same as charms.

Also include the maintainer field in bundles. Idea is to have similar
metadata in bundles as we do for charms.

-thanks,
Antonio


 - Add an icon to bundles so people can optionally brand their bundles.
 - Add these as a initial set of tags for charms promoted as reviewed:

 analytics
 big_data
 ecommerce
 openstack
 cloudfoundry
 cms
 social
 streaming
 wiki
 ops
 backup
 identity
 monitoring
 performance
 audits
 security
 network
 storage
 database
 cache (or cache-proxy?)
 application_development (rails, django, etc.)
 web_server

 In a couple of months we will have the ability to let people tag
 however they want for their personal namespace, so we're not trying to
 make a huge tag cloud here, just cover the majority of use cases.
 Thoughts?


 --
 Jorge Castro
 Canonical Ltd.
 http://juju.ubuntu.com/ - Automate your Cloud Infrastructure

 --
 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

[Review Queue]: nginx, hive, block-storage-broker, mysql review-queue, bundletester

[Antonio Rosales]

# nginx
https://bugs.launchpad.net/charms/+bug/1356856

# hive
https://bugs.launchpad.net/charms/+bug/1356956

# block-storage-charm

# mysql
https://code.launchpad.net/~jorge/charms/trusty/mysql/fix-proof/+merge/234020
Corrected the tab with spaces:
https://code.launchpad.net/~a.rosales/charms/trusty/mysql/add-default-keys/+merge/235064

When reviewing the MySQL charm I noticed that default key values with
blank values are being set to true even if the type is a string:
  http://paste.ubuntu.com/8368121/
This didn't affect the deploy, but I wanted to bring it up here to
confirm a blank default key value is the best practice as we update
charms to pass proof.

Also during the review I logged bugs against the charm-review project:
https://github.com/marcoceppi/review-queue/issues/10
https://github.com/marcoceppi/review-queue/issues/9
(Note, this project is in the process of getting moved to
github.com/juju-solutions)

and also logged a bug against the bundletester project
https://github.com/juju-solutions/bundletester/issues/2

thanks,
-- 
Antonio Rosales
Juju Ecosystem
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Charm Developer Feedback Hangout Aug 1 @ 1400 UTC

[Antonio Rosales]

Hello, we'll be having a Charm Development feedback session with
Sebastian tomorrow at 14:00 UTC via Google Hangout (on air).  The
agenda of the hangout will be to capture learnings from Charm
Development and how we can make it better.

The Google Event page is:
https://plus.google.com/events/cl7icvjofol5jvm6hc675d5dc8k

If you just want to drop your ideas, please feel free to put them at:
https://docs.google.com/a/canonical.com/document/d/1t_55N1il3XoL8z-jfa1CBoSxzOQjC90cgSpCqx5wkH0/edit

thanks,
-- 
Antonio Rosales
Juju Ecosystem
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm Developer Feedback Hangout Aug 1 @ 1400 UTC

[Antonio Rosales]

Note, Jose had the good idea to to host this on Ubuntu On Air@ ubuntuonair.com

https://www.youtube.com/watch?v=DmQcelIWJtI

So we'll be hanging out there.

Hope to virtually see you there and collect ideas.

-thanks,
Antonio

On Thu, Jul 31, 2014 at 1:50 PM, Antonio Rosales
antonio.rosa...@canonical.com wrote:
 Hello, we'll be having a Charm Development feedback session with
 Sebastian tomorrow at 14:00 UTC via Google Hangout (on air).  The
 agenda of the hangout will be to capture learnings from Charm
 Development and how we can make it better.

 The Google Event page is:
 https://plus.google.com/events/cl7icvjofol5jvm6hc675d5dc8k

 If you just want to drop your ideas, please feel free to put them at:
 https://docs.google.com/a/canonical.com/document/d/1t_55N1il3XoL8z-jfa1CBoSxzOQjC90cgSpCqx5wkH0/edit

 thanks,
 --
 Antonio Rosales
 Juju Ecosystem
 Canonical



-- 
Antonio Rosales
Juju Ecosystem
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Proposal: making apt-get upgrade optional

[Antonio Rosales]

On Mon, Jul 7, 2014 at 6:40 AM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
 On Sat, Jul 5, 2014 at 4:05 AM, Antonio Rosales
 antonio.rosa...@canonical.com wrote:

 On Thu, Jul 3, 2014 at 7:41 PM, Andrew Wilkins
 andrew.wilk...@canonical.com wrote:
  On Fri, Jul 4, 2014 at 5:23 AM, Tim Penhey tim.pen...@canonical.com
  wrote:
 
  I do just want to make the point that we are not just an ubuntu only
  system any more, nor even linux only.
 
  I'd prefer if we kept away from terms like apt-get as it doesn't make
  sense for windows nor centos.  While we could certainly treat those
  values differently on the other platforms, it definitely gives the
  feeling that we are *mainly* ubuntu and (hand wavey) some others.

 cloud-init generally supporst other Linux distros and I think
 Cloudbase has cloudbase-init for Windows.

 
  Any ideas for better names?
 
 
  upgrade-packages? Still kinda Linux, so alternatively
  upgrade-system.
 
  In cloud-init, it's package_upgrade, with apt_upgrade as an alias.

 +1 suggest to keep close to the cloud-init packaging as that is what
 Juju will be leveraging. Is there a straightforward mechanism to allow
 users and/or charm authors access to the cloud-init configuration?


 No, because we don't support all of cloud-config in bootstrap or manual
 provisioning. We convert cloud-config to a bash script. There's a TODO to
 have cloud-init support direct invocation (rather than via a metadata
 service), but I'm not sure this is going to happen. Doing so would require
 additional coordination across distributions, making portability more
 difficult.

 We could allow users to specify specific options, such as specifying
 additional packages to install. Can you elaborate on use cases?

Custom disk partitioning/filesystem config, user script, and vendor
scripts are immediate use cases that come up.

Adding Scott and Ben to the cc list to see if they may have any
additional use cases.

Ben/Scott,
Any suggestions on what cloud-init options/config should be made
transparent at the Juju config level? Perhaps there is a cloud-init
config option you thought would be beneficial to see at the Juju
config level.

-thanks,
Antonio

 -thanks,
 Antonio

 
 
  Tim
 
 
  On 04/07/14 02:56, Matt Bruzek wrote:
   +1 to making these options configurable and having sane defaults.
  
   Thanks!
  
  - Matt Bruzek matthew.bru...@canonical.com
   mailto:matthew.bru...@canonical.com
  
  
   On Thu, Jul 3, 2014 at 9:50 AM, Antonio Rosales
   antonio.rosa...@canonical.com
   mailto:antonio.rosa...@canonical.com
   wrote:
  
   On Tue, Jul 1, 2014 at 7:19 PM, Andrew Wilkins
   andrew.wilk...@canonical.com
   mailto:andrew.wilk...@canonical.com
   wrote:
On Wed, Jul 2, 2014 at 3:38 AM, Antonio Rosales
antonio.rosa...@canonical.com
   mailto:antonio.rosa...@canonical.com wrote:
   
Suggest we make an environments.yaml key value of say
   apt-get-update
set to a boolean with the default being true. Existing
   charms
   are
timing out[0] when apt-get update is turned off due to stale
   apt-get
metadata. Users then can them make the choice, and we can make
suggestions in the docs as to what this key value means and
   how
   it can
improve performance especially in the developer scenario when
   the
   care
more about fast iterative deploys.
   
Thoughts?
   
   
I'm not suggesting we turn off update, just upgrade. We add
   repos
(cloud-tools, ppa), so we need to update for juju's
   dependencies
   anyway. I
don't think my proposal will affect charms.
  
   Ah yes, sorry.  However, I would still suggest upgrade and update
   be
   config parameter with the default being past behavior. On that
   note
   it
   would also be nice to have a utility for Juju to pass on
   additional
   user defined cloud-init config options.
  
   -thanks,
   Antonio
  
   
   
[0] https://bugs.launchpad.net/juju-core/+bug/1336353
   
-thanks,
Antonio
   
On Tue, Jul 1, 2014 at 4:43 AM, Andrew Wilkins
andrew.wilk...@canonical.com
   mailto:andrew.wilk...@canonical.com wrote:
 On Tue, Jul 1, 2014 at 5:45 PM, John Meinel
   j...@arbash-meinel.com mailto:j...@arbash-meinel.com
 wrote:

 I would just caution that we'd really prefer behavior to be
   consistent
 across platforms and clouds, and if we can work with
   Microsoft
   to make
 'apt-get update' faster in their cloud everyone wins who
   uses
   Ubuntu
 there,
 not just us.


 I was meaning to disable it across all providers. It would
   be
   ideal to
 improve upgrades for all Ubuntu users, but from what I can
   tell
   it's a
 case
 of Azure's OS disks being a tad slow. If you start going up

Re: Proposal: making apt-get upgrade optional

[Antonio Rosales]

On Thu, Jul 3, 2014 at 7:41 PM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
 On Fri, Jul 4, 2014 at 5:23 AM, Tim Penhey tim.pen...@canonical.com wrote:

 I do just want to make the point that we are not just an ubuntu only
 system any more, nor even linux only.

 I'd prefer if we kept away from terms like apt-get as it doesn't make
 sense for windows nor centos.  While we could certainly treat those
 values differently on the other platforms, it definitely gives the
 feeling that we are *mainly* ubuntu and (hand wavey) some others.

cloud-init generally supporst other Linux distros and I think
Cloudbase has cloudbase-init for Windows.


 Any ideas for better names?


 upgrade-packages? Still kinda Linux, so alternatively upgrade-system.

 In cloud-init, it's package_upgrade, with apt_upgrade as an alias.

+1 suggest to keep close to the cloud-init packaging as that is what
Juju will be leveraging. Is there a straightforward mechanism to allow
users and/or charm authors access to the cloud-init configuration?

-thanks,
Antonio



 Tim


 On 04/07/14 02:56, Matt Bruzek wrote:
  +1 to making these options configurable and having sane defaults.
 
  Thanks!
 
 - Matt Bruzek matthew.bru...@canonical.com
  mailto:matthew.bru...@canonical.com
 
 
  On Thu, Jul 3, 2014 at 9:50 AM, Antonio Rosales
  antonio.rosa...@canonical.com mailto:antonio.rosa...@canonical.com
  wrote:
 
  On Tue, Jul 1, 2014 at 7:19 PM, Andrew Wilkins
  andrew.wilk...@canonical.com mailto:andrew.wilk...@canonical.com
  wrote:
   On Wed, Jul 2, 2014 at 3:38 AM, Antonio Rosales
   antonio.rosa...@canonical.com
  mailto:antonio.rosa...@canonical.com wrote:
  
   Suggest we make an environments.yaml key value of say
  apt-get-update
   set to a boolean with the default being true. Existing charms
  are
   timing out[0] when apt-get update is turned off due to stale
  apt-get
   metadata. Users then can them make the choice, and we can make
   suggestions in the docs as to what this key value means and how
  it can
   improve performance especially in the developer scenario when the
  care
   more about fast iterative deploys.
  
   Thoughts?
  
  
   I'm not suggesting we turn off update, just upgrade. We add repos
   (cloud-tools, ppa), so we need to update for juju's dependencies
  anyway. I
   don't think my proposal will affect charms.
 
  Ah yes, sorry.  However, I would still suggest upgrade and update be
  config parameter with the default being past behavior. On that note
  it
  would also be nice to have a utility for Juju to pass on additional
  user defined cloud-init config options.
 
  -thanks,
  Antonio
 
  
  
   [0] https://bugs.launchpad.net/juju-core/+bug/1336353
  
   -thanks,
   Antonio
  
   On Tue, Jul 1, 2014 at 4:43 AM, Andrew Wilkins
   andrew.wilk...@canonical.com
  mailto:andrew.wilk...@canonical.com wrote:
On Tue, Jul 1, 2014 at 5:45 PM, John Meinel
  j...@arbash-meinel.com mailto:j...@arbash-meinel.com
wrote:
   
I would just caution that we'd really prefer behavior to be
  consistent
across platforms and clouds, and if we can work with Microsoft
  to make
'apt-get update' faster in their cloud everyone wins who uses
  Ubuntu
there,
not just us.
   
   
I was meaning to disable it across all providers. It would be
  ideal to
improve upgrades for all Ubuntu users, but from what I can tell
  it's a
case
of Azure's OS disks being a tad slow. If you start going up the
instance-type scale, then you do get more IOPS. I haven't
  measured how
much
of a difference it makes.
   
   
Have we looked into why Upgrade is taking 3m+? Is it the time
  to
download
things, is it the time to install things? I've certainly heard
  things
like
disk ops is a bit poor on Azure (vs CPU is actually better
  than
average).
Given the variance of 6m+ to 3m20s with Eat my data, it would
  seem disk
sync
performance is at least a factor here.
   
   
I just looked, and it is mostly not network related (I assume
  mostly I/O
bound). On ec2 an upgrade fetches all the bits in 0s; on Azure
  it's
taking
5s.
   
Given I believe apt-get update is also disabled for local (it
  is run on
the initial template, and then not run for the other instances
  copied
from
that), there is certainly precedence. I think a big concern is
  that we
would
probably still want to do apt-get update for security related
  updates.
Though perhaps that is all of the updates we are applying
  anyway...
   
If I read the aws.json file

Re: Proposal: making apt-get upgrade optional

[Antonio Rosales]

Suggest we make an environments.yaml key value of say apt-get-update
set to a boolean with the default being true. Existing charms are
timing out[0] when apt-get update is turned off due to stale apt-get
metadata. Users then can them make the choice, and we can make
suggestions in the docs as to what this key value means and how it can
improve performance especially in the developer scenario when the care
more about fast iterative deploys.

Thoughts?

[0] https://bugs.launchpad.net/juju-core/+bug/1336353

-thanks,
Antonio

On Tue, Jul 1, 2014 at 4:43 AM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
 On Tue, Jul 1, 2014 at 5:45 PM, John Meinel j...@arbash-meinel.com wrote:

 I would just caution that we'd really prefer behavior to be consistent
 across platforms and clouds, and if we can work with Microsoft to make
 'apt-get update' faster in their cloud everyone wins who uses Ubuntu there,
 not just us.


 I was meaning to disable it across all providers. It would be ideal to
 improve upgrades for all Ubuntu users, but from what I can tell it's a case
 of Azure's OS disks being a tad slow. If you start going up the
 instance-type scale, then you do get more IOPS. I haven't measured how much
 of a difference it makes.


 Have we looked into why Upgrade is taking 3m+? Is it the time to download
 things, is it the time to install things? I've certainly heard things like
 disk ops is a bit poor on Azure (vs CPU is actually better than average).
 Given the variance of 6m+ to 3m20s with Eat my data, it would seem disk sync
 performance is at least a factor here.


 I just looked, and it is mostly not network related (I assume mostly I/O
 bound). On ec2 an upgrade fetches all the bits in 0s; on Azure it's taking
 5s.

 Given I believe apt-get update is also disabled for local (it is run on
 the initial template, and then not run for the other instances copied from
 that), there is certainly precedence. I think a big concern is that we would
 probably still want to do apt-get update for security related updates.
 Though perhaps that is all of the updates we are applying anyway...

 If I read the aws.json file correctly, I see only 8 releases of the
 'precise' image. 6 of 'trusty' and 32 total dates of released items. And
 some of the trusty releases are 2014-01-22.1 which means it is likely to be
 beta releases.

 Anyway, that means that they are actually averaging an update only
 1/month, which is a fairly big window of updates to apply by the end of
 month (I would imagine). And while that does mean it takes longer to boot,
 it also means you would be open to more security holes without it.


 My contention is that if we don't *keep* it updated, we may as well just
 leave it to the user. When you create an instance in ec2 or Azure or
 whatever, it doesn't come fully up-to-date. You get the released image, and
 then you can update it if you want to.

 John
 =:-




 On Mon, Jun 30, 2014 at 5:05 PM, Andrew Wilkins
 andrew.wilk...@canonical.com wrote:

 Hi folks,

 I've been debugging a bootstrap bug [0] that was caused by ssh timing out
 (and the client not noticing), which was caused by apt-get upgrade taking
 an awfully long time (6 minutes on Azure).
 [0] https://bugs.launchpad.net/juju-core/+bug/1316185

 I just filed https://bugs.launchpad.net/juju-core/+bug/1335822, and did a
 quick and dirty hack that brought the upgrade down to 3 minutes on Azure. I
 don't know the variance, so I can't be sure that it's all due to eatmydata,
 but smoser's results are similar.

 Even with eatmydata, a full bootstrap on Azure just took me 10 minutes.
 That's roughly broken down into:
  - apt-get update: 20s
  - apt-get upgrade: 3m20s
  - apt-get install various: 10s
  - Download tools (from shared Azure storage account): 5s
  - jujud bootstrap: 1m50s

 We could bring the 10m down to 6m40s. Still not brilliant, but
 considerably better IMO.

 I propose that we remove the apt-get upgrade altogether. Cloud images
 are regularly updated and tested, and I think we should be able to rely on
 that alone. If users want something more up-to-date, they can use the daily
 images which are not tested as a whole, but are composed of SRUs, which is
 effectively what users get today.

 Cheers,
 Andrew

 --
 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




-- 
Antonio Rosales
Juju Ecosystem
Canonical

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju @ IBM Innovate

[Antonio Rosales]

Ubuntu and Juju have been ported to IBM's Power8 Little Endian
hardware. Juju being the masterfully slick way to orchestrate services
 on scale-out infrastructure, such as those provided by Power8, has
been selected as a finalist in the IBM App Throwdown at the IBM
Innovate Conference.

Feel free to browse the finalist selections[0], and vote for your
favorite. I'll be in Orlando at the Innovate conference demo'ing Juju
if any folks would like to learn more about Juju on Power8.

Fyi, voting ends Tuesday (June 3) Morning (8am Pacific) and if you can
cast your vote by tweeting something like:

I vote for @ubuntucloud #IBMInnovateApp http://ibmappthrowdown.tumblr.com

Insert the appropriate twitter handle of the finalist you want to vote for.


[0] http://ibmappthrowdown.tumblr.com/

thanks,
-- 
Antonio Rosales
Juju Ecosystem
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: saucy images on hp cloud

[Antonio Rosales]

As a side note there is an issue on HP for new users that only access
to 13.5 HP cloud services not being able to deploy images that are
indexed from the 12.12 service. I have a support ticket opened with HP
support to bring the 12.12 images forward to 13.5.

The issue David seeing is different and I have been able to reproduce.
 I can verify there is a 13.10 image on HP cloud, however it is not
indexed at:
http://cloud-images.ubuntu.com/releases/streams/v1/com.ubuntu.cloud:released:hpcloud.json

I'll get with the team Certified Public Cloud team that indexes these
images and see if we can get an updated stream.

-thanks,
Antonio Rosales

On Tue, Feb 4, 2014 at 3:37 AM, David Cheney david.che...@canonical.com wrote:
 Hello,

 I am trying to deploy a saucy machine (via the ubuntu charm) on hp cloud.

 lucky(~/src/launchpad.net/juju-core) % juju deploy -v
 --repository=$HOME/charms local:saucy/ubuntu
 verbose is deprecated with the current meaning, use show-log
 2014-02-04 01:33:46 INFO juju api.go:231 connecting to API addresses:
 [15.185.109.120:17070]
 2014-02-04 01:33:46 INFO juju apiclient.go:118 state/api: dialing
 wss://15.185.109.120:17070/
 2014-02-04 01:33:47 INFO juju apiclient.go:128 state/api: connection
 established
 Added charm local:saucy/ubuntu-1 to the environment.
 2014-02-04 01:33:50 INFO juju.cmd supercommand.go:298 command finished
 lucky(~/src/launchpad.net/juju-core) % juju status
 environment: hp
 machines:
   0:
 agent-state: started
 agent-version: 1.17.3.1
 dns-name: 15.185.109.120
 instance-id: 3500935
 instance-state: ACTIVE
 series: precise
 hardware: arch=amd64 cpu-cores=1 mem=1024M root-disk=30720M
   1:
 agent-state-info: '(error: no saucy images in az-1.region-a.geo-1 with
 arches
   [amd64])'
 instance-id: pending
 series: saucy
 services:
   ubuntu:
 charm: local:saucy/ubuntu-1
 exposed: false
 units:
   ubuntu/0:
 agent-state: pending
 machine: 1

 This has not been working for some time.

 Is this a known issue, or something I should be raising ?

 Cheers

 Dave

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev




-- 
Antonio Rosales
Juju Ecosystem
Canonical

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: [ANN] Charm Tools 1.2.3 released

[Antonio Rosales]

Thanks for getting this out.

I have been eagerly awaiting the integration of Charm Tools and Amulet
to ease the burden of writing tests in charms. I am looking forward to
adding much needed tests into charms.

`charm info` is a nice touch for quick access to the readme to look at
examples at the command line.

-thanks,
Antonio

On Wed, Dec 11, 2013 at 12:42 PM, Marco Ceppi marco.ce...@canonical.com wrote:
 Hello all,

 As promised on Friday, there is an update to Charm Tools which fixes bugs
 and adds new features. Charm Tools 1.2.3 supersedes 1.2.0, 1.2.1, and 1.2.2
 - all of which were uploaded to the PPA. If you managed to pull and update
 between now and Monday make sure you have the latest charm-tools installed.

 # 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 charm-tools

 For Windows users, a new Charm Tools MSI will be made available here
 https://launchpad.net/charm-tools/1.2/1.2.3 and on the docs.

 For Mac users, we will work to update the homebrew recipe to include the new
 version of Charm Tools.

 # Highlights

 ## charm add

 New add command create, this will be used to create generators. Currently
 only tests is available

 ### charm add tests

 `juju charm add tests` will create an example Amulet test file based on
 metadata.yaml information for the charm provided (or cwd, if cwd is a charm)

 ## charm get

 We've made `juju charm get` more useful. It accepts standard charm URLs and
 will branch accordingly.
   - juju charm get wordpress
   - juju charm get ~marcoceppi/wordpress
   - juju charm get ~marcoceppi/precise/wordpress
   - juju charm get precise/wordpress-20
   - juju charm get cs:wordpress

  and any permutations of the above

 ## charm info

 New command `juju charm info` added, this will produce the README of the
 charm, if available. Accepts any valid standard charm store URL:
   - juju charm info wordpress
   - juju charm info cs:precise/wordpress
   - juju charm info ~marcoceppi/wordpress

 # Changes

 You can view all bugs addressed in this version at the following urls:

 - https://launchpad.net/charm-tools/1.2/1.2.3
 - https://launchpad.net/charm-tools/1.2/1.2.2
 - https://launchpad.net/charm-tools/1.2/1.2.0

 The 1.2 series will remain open for patches only at this point. All future
 features will be focused on the 1.3 series scheduled for release late
 January.

 # Support

 Support for charm-tools is available via bug reporting at
 https://bugs.launchpad.net/charm-tools, in #juju on freenode.net, this
 mailing list juju@lists.ubuntu.com, and askubuntu.com tagged juju.

 Thanks,
 Marco Ceppi

 --
 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: Vagrant boxes with Juju now available

[Antonio Rosales]

On Thu, Dec 5, 2013 at 9:59 AM, Daniele Stroppa
daniele.stro...@joyent.com wrote:
 Hi Jorge,

 I've tried the Vagrant boxes and they look great.

 However, I'm having a small issue. I've spin up a Saucy (amd64) box, boots
 up fine, I can access the GUI and 'juju status' shows the 'juju-gui' service
 deployed. If I try to deploy my charm from /vagrant (juju deploy
 --repository /vagrant/charms local:precise/node-app) it just gets stuck,
 nothing happens and I need to Ctrl-C to go back to the console. Same happens
 if I do a simple 'ls /vagrant'. (This works in a plain Ubuntu box with Juju
 installed).

Talking with Ben you may be running into:
https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1239384

Thus the recommendation is to use a 12.04 vbox image with latest
vagrant and current vbox.

Let us know if this helps resolve the issue you are seeing, and thanks
for the feedback.

-thanks,
Antonio


 Any suggestions?

 My Environment:
 Mac OS X 10.8.5
 VirtualBox 4.2.18
 Vagrant 1.3.3

 Thanks,
 Daniele


 On Tue, Dec 3, 2013 at 6:04 PM, Jorge O. Castro jo...@ubuntu.com wrote:

 Hi everyone,

 Ben's been working on providing Vagrant images with Juju built in:


 http://blog.utlemming.org/2013/12/beta-cross-platform-juju-development.html

 This is particularly important for those of you on Windows or OSX we
 share the /vagrant directory, allowing you to quickly hack on your
 charm locally and deploy to running Ubuntu Cloud instances just as you
 would to a provider. (Except without the cost!)

 Please feel free to send feedback to this list!

 --
 Jorge Castro
 Canonical Ltd.
 http://juju.ubuntu.com/ - Automate your Cloud Infrastructure

 --
 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

Re: Vagrant boxes with Juju now available

[Antonio Rosales]

On Thu, Dec 5, 2013 at 2:14 PM, Daniele Stroppa
daniele.stro...@joyent.com wrote:
 Thanks Antonio, using a 12.04 box fixed the issue, the shared folder
 /vagrant is accessible.

Great to hear, and thanks again for the feedback and follow up.

-Antonio


 Daniele


 On Thu, Dec 5, 2013 at 7:08 PM, Antonio Rosales
 antonio.rosa...@canonical.com wrote:

 On Thu, Dec 5, 2013 at 9:59 AM, Daniele Stroppa
 daniele.stro...@joyent.com wrote:
  Hi Jorge,
 
  I've tried the Vagrant boxes and they look great.
 
  However, I'm having a small issue. I've spin up a Saucy (amd64) box,
  boots
  up fine, I can access the GUI and 'juju status' shows the 'juju-gui'
  service
  deployed. If I try to deploy my charm from /vagrant (juju deploy
  --repository /vagrant/charms local:precise/node-app) it just gets stuck,
  nothing happens and I need to Ctrl-C to go back to the console. Same
  happens
  if I do a simple 'ls /vagrant'. (This works in a plain Ubuntu box with
  Juju
  installed).

 Talking with Ben you may be running into:
 https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1239384

 Thus the recommendation is to use a 12.04 vbox image with latest
 vagrant and current vbox.

 Let us know if this helps resolve the issue you are seeing, and thanks
 for the feedback.

 -thanks,
 Antonio

 
  Any suggestions?
 
  My Environment:
  Mac OS X 10.8.5
  VirtualBox 4.2.18
  Vagrant 1.3.3
 
  Thanks,
  Daniele
 
 
  On Tue, Dec 3, 2013 at 6:04 PM, Jorge O. Castro jo...@ubuntu.com
  wrote:
 
  Hi everyone,
 
  Ben's been working on providing Vagrant images with Juju built in:
 
 
 
  http://blog.utlemming.org/2013/12/beta-cross-platform-juju-development.html
 
  This is particularly important for those of you on Windows or OSX we
  share the /vagrant directory, allowing you to quickly hack on your
  charm locally and deploy to running Ubuntu Cloud instances just as you
  would to a provider. (Except without the cost!)
 
  Please feel free to send feedback to this list!
 
  --
  Jorge Castro
  Canonical Ltd.
  http://juju.ubuntu.com/ - Automate your Cloud Infrastructure
 
  --
  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

Re: New Pages in docs!

[Antonio Rosales]

Nick,
Thanks for continuing to field feedback, and make the contribution to
the docs story easier.


Juju Users/Authors,
Let us know what you think, and hopefully we'll see some merge requests soon.

-thanks,
Antonio


On Wed, Sep 11, 2013 at 9:59 AM, Nick Veitch nick.vei...@canonical.com wrote:
 Or to be more specific, creating them.

 I have taken on board various feedback about creating new pages, and to make
 everyone's life a little easier(especially mine), if you want to create new
 pages in docs you will find new instructions on the contributing page and a
 new template and build script in the tools directory.
 In short, the build script will replace all the commented sections of a page
 with the correct template files, so you don't need to copy and paste stuff
 or write a document full of the ever-growing headers, footers, scripts and
 other bits. As you will see from the template file, you don't need anything
 in those spaces at all, bar the comments themselves.

 I hope this will make things easier for people with a valuable contribution
 to make!

 Onwards,
 Nick

 --
 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: [ANN] juju-core 1.13.2 has been released

[Antonio Rosales]

James,
Thanks for uploading to Saucy.

Julian/David,
I see the fix is committed  We'll need to cut another release this
week for any remaining Azure fixes in preparation for the announcement
next week.  David, could you confirm with Julian on when is the
correct time to cut another devel release? Also when is the next
stable release slated for (mid september)?

-thanks,
Antonio


On Mon, Aug 26, 2013 at 4:08 AM, James Page james.p...@ubuntu.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 25/08/13 13:17, David Cheney wrote:
 Thanks John. James -- I have uploaded the release tarball now,
 sorry about the delay, I was in an airplane.

 No problem; juju-core 1.13.2 also uploaded to Saucy.

 Cheers

 James

 - --
 James Page
 Ubuntu and Debian Developer
 james.p...@ubuntu.com
 jamesp...@debian.org
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.14 (GNU/Linux)
 Comment: Using GnuPG with undefined - http://www.enigmail.net/

 iQIcBAEBCAAGBQJSGxsTAAoJEL/srsug59jDoYwQAMKovqEhdrY8BdrHNZZWjnXx
 O/DH+SPpbIyyvdLqiuURpAjMXfTrUW9sOOYPmT0L/3KxokyDLvXsYJTau+v1S2m7
 0yZIG8qWkMA5CBzgUoMd1tdxbJWIYEdpKvEaJaMypgB5KBZaJMSA5ZruyQwZXLM5
 wgJXxRxGDXrJqfazrD+j6t+Mexd3PaFB2LWpla0HdqLXc2nAjn7ltGz7euWJNB3E
 n56R9J3YoFPQwUnHUnW63iCIjiBzh02A2wS72rao/V/3rCRIrR5moPRf2Y8edr+g
 wURt4jSD49h0KfNciz5FMTjms08txLXla/zfSP2T8Gb/Dbptf0zznuw5YCV1WeJG
 5MGm9QD9SKi3kvd9hKMXLgHJxZOw0ilsorO/nLDP3wEMTM/x2O8gaOaB0YkAht2g
 PaiJOfIXwpVZRuZmOYufvCutozO3s755zy99QRTvQMb2/SRTnRM2I9GHgkJWgNKX
 Bw0l0mQjHNL9CNhcug/obrWFIgNlGUBcz6cQo2d5VH3qa3hK0PnYmiy1mzVvFz3/
 HJxV6FEB8VUdjrsqpzYdkGXWpD0qXlodaTBrXKJyrY/6/Z+hgS7tsxjjfh/cOEnw
 GH3564WvZYWMeFI2WKhXaVoyD/FC+Go5MtKR2Z1Y9nb3QQ/sR4vgeIBQlUuthyPs
 KxwNytIEP+nDYg2YEr9x
 =iqal
 -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



-- 
Antonio Rosales
Ubuntu Cloud Ecosystem Engineering
juju.ubuntu.com/charm-championship - Share your infrastructure, win 10k!

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: CLI support in lp:charm-helpers and the road to 1.0

[Antonio Rosales]

On Fri, Aug 23, 2013 at 6:29 PM, Mark Mims mark.m...@canonical.com wrote:
 thanks!
+1 Thanks for ensuring we are able to keep the write your charm in
any language story while trying to improve the charm authorship
story. Be sure to join the Charm Development Tooling 1308 UDS
session[0] so we can add your items to the task list.

[0] 
http://summit.ubuntu.com/uds-1308/meeting/21891/servercloud-s-juju-charmhelper2/

-thanks,
Antonio



 On Thu, Aug 22, 2013 at 3:53 PM, Matthew Wedgwood
 matthew.wedgw...@canonical.com wrote:

 I'm happy to announce that lp:charm-helpers now includes support for
 command-line invocation of helpers using the chlp command. This release
 implements only two simple subcommands intended as examples. Nevertheless,
 this is a major milestone, as it paves the way for  charm authors to access
 charm-helpers functionality from any language capable of making shell calls.

 With all the work we've put into the project, I think we're ready to push
 forward to a 1.0 release. The goals I have in mind for 1.0 are:

 * Implement any remaining most-frequently-used functionality for charms
 * Expose generally-useful helpers a chlp subcommands
 * Provide basic documentation for python and command-line users
 * Settle on a stable API by ensuring that helpers outside of contrib are
 well-organized
 * Set up automated unit tests whose success will gate merges to the stable
 tree
 * Set up a stable PPA that can be used with confidence by charm authors
 and deployers

 The top thing you can do to help is to file bugs reports. In addition to
 problem reports, feature requests are most welcome.
 https://bugs.launchpad.net/charm-helpers/+bugs

 If you'd be so generous to contribute development effort, please consider
 the 1.0-milestone bugs top priority.
 https://launchpad.net/charm-helpers/+milestone/1.0

 Finally, I'd like to extend my thanks to all the contributors and users so
 far.

 -Matthew

 --
 Juju mailing list
 Juju@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju




 --
 Mark Mims, Ph.D.
 Canonical Ltd.
 mark.m...@canonical.com
 +1(512)981-6467

 --
 Juju mailing list
 Juju@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju




-- 
Antonio Rosales
Ubuntu Cloud Ecosystem Engineering
juju.ubuntu.com/charm-championship - Share your infrastructure, win 10k!

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju