Re: "Designing for Success: Juju and Charm architecture overview" - Juju Charm Summit

[Andrew Wilkins]

On Sat, Sep 19, 2015 at 2:43 AM Marco Ceppi 
wrote:

> Here are my slides from the first session on Thursday morning. It's a
> meant to be an overview of the Juju and Charm architecture. I'm curious on
> feedback as it's the first time I've run this style presentation.
>
>
> https://docs.google.com/presentation/d/1_rTFq-aS_ESK2wabnCviZtDZ-nYOPI23MeLp-GLDyJY/edit
>

Good stuff!

Teeny weeny correction: storage.yaml does not exist, you define storage in
metadata.yaml. See: https://jujucharms.com/docs/devel/storage.

Cheers,
Andrew

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: Designing for Success: Juju and Charm architecture overview

[Samuel Cozannet]

+1, great presentation. We should publish this as a post with some
wordsmithing + marketing (images).

++
Sam


--
Samuel Cozannet
Cloud, Big Data and IoT Strategy Team
Business Development - Cloud and ISV Ecosystem
Changing the Future of Cloud
Ubuntu   / Canonical UK LTD  / Juju

samuel.cozan...@canonical.com
mob: +33 616 702 389
skype: samnco
Twitter: @SaMnCo_23
[image: View Samuel Cozannet's profile on LinkedIn]


On Sun, Sep 20, 2015 at 5:46 PM, James Beedy  wrote:

> Marco -
>
> Your slides and presentation couldn't be more clear and comprehensive! Thanks
> a ton (to you and everyone else) for putting the time and effort in to this
> event to make it the huge success that it was! Knowing the "hows" and
> "whys" is what really matters and what really counts in the end. Having a
> clear understanding of the environment architecture is what will really
> help aspiring juju developers (like myself) to write and develop better
> charms! Thanks again!
>
> James
>
> --
> 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

Great post about Juju from the Meteorite guys

[Mark Shuttleworth]

Sam C was kind enough to point me to this today:

  https://medium.com/@Meteorite_BI/why-i-like-juju-5cd1c16b33b1

This is what makes Juju so much fun, you can actually see what a
difference it's making to people working with big, complex topologies of
fast-moving stuff.

I care a lot about start-ups and innovation. Right now, I think a lot of
start-ups who have great ideas to add to Hadoop or Spark or OpenStack or
Mesos have to wait for their potential customers to get the huge,
clunky, common, commodity parts organised before they can actually strut
their stuff. Having great charms of Apache Hadoop alongside Cloudera
Hadoop means an analytics startup can sell their stuff, make it work
just as well and just as automatically no BOTH those implementations of
hadoop, and get demo's up and running for real on customer premises in a
few minutes.

That's the spirit of Ubuntu, and we're also quite pleased to bring it to
CentOS, SLES, Windows, whatever you need :)

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

Re: Compiling juju on openSUSE

[Mark Shuttleworth]

You might even just be able to run the unmodified juju client binary
from Ubuntu on OpenSUSE, I believe it's all still statically linked.

Mark

On 20/09/15 22:39, Herman Bergwerf wrote:
> Ok great!
> I looked up the source and I think it can be achieved by updating the
> juju/juju and the juju/utils repo. For some reason I only got the
> juju-local binary by installing the Go code though (I also spoofed my OS by
> pointing juju to a copy of the /etc/os-release from Ubuntu).
> However, I would only need this to make the juju client run on my primary
> linux OS which is currently openSUSE and I'm not sure if that is important
> enough to change the source code. I'm perfectly ok with using Ubuntu for
> the actual cluster although SLES compatibility might be interesting for
> other people.
>
> Op zo 20 sep. 2015 om 12:59 schreef Mark Shuttleworth :
>
>> On 20/09/15 02:23, Andrew Wilkins wrote:
>>> The OS-detection code exists primarily to decide how the Juju
>>> servers/agents should be installed, configured, and how they should
>> behave
>>> at runtime. We should stop being so pedantic on the client side.
>> Definitely, and we must already have a way around that because IIRC we
>> build the code for Windows and MacOS, and the server hasn't (yet :))
>> been ported to those. So I would look to figure out how to instruct the
>> build so as to build the client only on OpenSUSE as a starting point.
>> Then of course patches for the server/controller (should be easy enough)
>> and for agents (to enable SLES charms :)) would be next.
>>
>> Mark
>>


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

Re: Downgrade a charm

[Richard Harding]

No problem. Let us know if you hit any other issues. Enjoy Juju!

On Mon, 21 Sep 2015, Tom Barber wrote:

> Hi Rick,
> 
> Spot on thanks, its just a standalone deployment in a shell script so I
> just need to pin the version in that.
> 
> Thanks a lot!
> 
> Tom
> 
> On 21 September 2015 at 12:32, Richard Harding 
> wrote:
> 
> > On Mon, 21 Sep 2015, Tom Barber wrote:
> >
> > > Hi guys
> > >
> > > I thought this might happen and its quite a large problem so any ideas
> > are
> > > greatly appreciated.
> > >
> > > I redeployed my Hadoop cluster this morning and found that the Spark
> > charm
> > > has had its version upgraded from 1.3 to 1.4. SQL in 1.4 has a number of
> > > serious bugs and I need to get 1.3 back, can I deploy a specific charm
> > > version when bootstrapping my environment?
> >
> > When you say bootstrapping to you mean deploying the service? Are you using
> > a bundle to perform this deployment?
> >
> > Yes, you can specify the revision of any deployment command. Just add a -xx
> > to the charm url.
> >
> > So in the case of Spark, the latest revision is currently 3 (if you mean
> > apache-spark) and can be deployed with:
> >
> > juju deploy cs:trusty/apache-spark-3
> >
> > if you wanted a previous revision of the charm you can change that final
> > number:
> >
> > juju deploy cs:trusty/apache-spark-1
> >
> > If you're deploying from a bundle and the revision isn't what you'd like,
> > you'll have to download the bundle yaml file and edit it to be the charm
> > url with the revision you'd like to have.
> >
> > Hope that helps.
> >
> >
> >
> > --
> >
> > Rick Harding
> >
> > Juju UI Engineering
> > https://launchpad.net/~rharding
> > @mitechie
> >

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

Downgrade a charm

[Tom Barber]

Hi guys

I thought this might happen and its quite a large problem so any ideas are
greatly appreciated.

I redeployed my Hadoop cluster this morning and found that the Spark charm
has had its version upgraded from 1.3 to 1.4. SQL in 1.4 has a number of
serious bugs and I need to get 1.3 back, can I deploy a specific charm
version when bootstrapping my environment?

Thanks

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

Reviewed proposals against juju/juju

[Anastasia Macmood]

Hi

Please review list of your proposals on RB :D

While doing reviews today, I have noticed that we have several reviewed
proposals that are older than 2 weeks.

Some of these may have a legitimate reason to be this weathered - they
are against feature branches or do not have ShipIt...

Others should have been merged or updated or abandoned and closed. As
authors, could you please clean up your proposals?

Let's keep our review list current and relevant :D

Sincerely Yours,

Anastasia


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

"Evolution of a Charm" presentation from the Charmer Summit

[Ryan Beisner]

>From the Juju Charmer Summit (Charm Testing session), here are the
"Evolution of a Charm" slides.

https://docs.google.com/presentation/d/1SRo8_qVM0RqZcK78yzgNcIIPuiSMa_bhSBi4s8Zx72M/pub?start=true=false=3300

TLDR;  We describe how we are evolving each of the Ubuntu OpenStack charms
over time to fit the underlying product support matrix as it also evolves.
Functionally testing that matrix is a core piece of the dev and release
process, and yes I am biased.  ;-)

It was really great to work with so many companies and individuals who are
using Juju, MAAS and/or Ubuntu OpenStack in various environments and use
cases.  Thanks again to those who attended and participated.

Cheers!

-- 
Ryan Beisner
QA Engineer, Ubuntu OpenStack Engineering, Canonical, Ltd.
irc:beisner  lp:~1chb1n
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Trying to remove and redeploy quantum-gateway on a different server

[Mark Shuttleworth]

On 21/09/15 04:25, Daniel Bidwell wrote:
> Does this mean that I can use a local install of landscape and grow it
> to more than 10 nodes without getting support for it?  I stopped using
> landscape because I can't afford to use something that will require
> software support when it grows larger than a small cluster.
>
> We are a small, private university without much funding, but would very
> much like to build a private openstack (the easy way).

The charms are your best bet if you want to run all the ops yourself.
They are also a very good way to come to understand how all the parts of
OpenStack fit together.

But do look into the pricing of Landscape, we've aimed to reach a mass
market including universities (several of our fully-managed deployments
are university research offices). The cost runs from $300 to $700 per
server, or alternatively fixed banded cost for clouds of particular
sizes that reduce the per-node cost. I think you'd need at least a few
admins with detailed OpenStack knowledge to match it. May as well keep
your ops folks focused on the actual workloads that define the operation
rather than infrastructure, is the thinking.

Mark


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