Re: What's the future of Juju?

2015-03-31 Thread Charles Butler
Hey Merlijn,

I'm a bit late to this thread, but wanted to thank you for calling out the
FOSDEM talk this year :) That was me on stage giving the overview.

Really glad you took the time to reach out and get some answers. If there's
anything else we can do for you feel free to drop by #juju on
irc.freenode.net - i'm lazypower.

All the best,



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

On Sat, Mar 28, 2015 at 4:35 PM, Merlijn Sebrechts 
merlijn.sebrec...@gmail.com wrote:

 Thanks to everyone for taking the time to answer this so thoroughly! The
 project is clearly going in a direction that will be very beneficial to us.
 The monitoring, multi-user and cross-platform features will come in very
 handy!

 I do agree with Mark that writing charms has been poorly documented.
 Writing charms in Bash is pretty well documented and has some good
 examples, but this is much less the case for python. Writing Charms in Bash
 is a great way to get started with Juju, but scripts get very complicated
 very fast. The python-charmhelpers modules seem to have some pretty strong
 features, but they aren't well documented. It seems like you brag about
 your beginner features but you keep quiet about what makes Juju charms
 really competitive...

 This might contribute to the (incorrect) idea people have about what Juju
 is. A lot of people I speak to think Juju is Chef/puppet for people who
 want a nice gui. Although this idea is slowly changing.. Talks like the
 one at Fosdem this year help spread the word about what Juju exactly is..

 2015-03-27 15:58 GMT+01:00 Mark Shuttleworth m...@ubuntu.com:

 On 25/03/15 20:01, Merlijn Sebrechts wrote:
  I'm interested in what the future of Juju is. From the small experience
  I've had with it, it seems like a product with a lot of potential. It
 fills
  a gap in our project that no other technology can fill. Its biggest
  strength is how relations between services are managed. This is
 something
  that, to my knowledge, does not exist in any tool today. It enables a
 very
  modular approach and solves a lot of problems we would have with other
  tools.

 Yes, agreed!

  However, I've also seen some things that worry me. Even after three
 years,
  there are still a lot of bugs in the project. The documentation is
 lacking,
  especially in the parts of Juju that are the most competitive. The
  community is also very small. The fact that it can still only manage
 Ubuntu
  servers worries me too. I could go more into detail here, but I don't
 think
  it is relevant to this question.

 I understand what you mean. In part I think this comes from the team
 being focused on getting to our key Juju 2.0 milestone, and perhaps not
 taking as much time to celebrate the smaller milestones on the way,
 especially when they are things that we know need a little more work.
 For example, the Windows and CentOS support that has landed is a huge
 step, but we know it is still a bit rough and needs more polish. Perhaps
 we should be louder about some of those steps to draw in people who
 could help provide feedback and patches!


  I'm considering starting a big long-term project on top of Juju. The
  project would be very dependent on Juju, so I don't want to do this if
  there is a chance that Juju will be abandoned in 5 years...

 No chance of that.

 In my travels now I am glad to say I see a shift in the way people
 engage with us about Juju. It used to be why would you want to compete
 with Puppet? but now folks understand that we do not want to compete
 with Puppet, we want to come up a level and enable people to collaborate
 and reuse their puppet / chef / bash / python across different clouds
 and environments.

 That focus on collaboration and reuse is what makes Juju special. In the
 long run we will integrate Juju into places like HEAT so you get the
 benefit of charms, together with the underlying cloud information about
 performance, so that things like autoscaling are magical, but in the
 short term it's easy to think the projects compete. But folks are
 starting to understand that now, so I don't get asked why do you not
 just do HEAT?.

 I also think that it will emerge that there are many levels of
 orchestration; Juju will be the BEST for the lowest level of
 infrastructure orchestration, but people will use Juju to deploy things
 like PAAS which themselves offer a kind of orchestration. So end-users
 might use a PAAS, which is like a model or API or orchestration system,
 and underneath that, administrators will use Juju for the base level. We
 won't try to push Juju into every layer; just like we have kept MAAS and
 Juju separate with different interests and different responsibilities,
 so now the Chef guys are happy to use MAAS, which is good for us both.


  What can you tell me about the future of Juju? Things I'm interested in:
 
  - Big companies building services on top of Juju

 Pretty 

Re: What's the future of Juju?

2015-03-28 Thread Nick Veitch
Hi,
Thanks for the useful feedback on docs! I agree that good examples for
Python and the charm helpers are things that are sorely missing, and
we will address that soon.
I don't want to burden you further, but would you mind if I emailed
you some questions about your experience with the documentation? I
don't like to pass up the opportunity to talk to real users!
In the meantime if you have any more suggestions for docs, please feel
free to email me or you can report specific issues on the docs
repository (https://github.com/juju/docs/issues).

-- 
Nick Veitch, Documentation Team
nick.vei...@canonical.com

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


Re: What's the future of Juju?

2015-03-27 Thread Mark Shuttleworth
On 25/03/15 20:01, Merlijn Sebrechts wrote:
 I'm interested in what the future of Juju is. From the small experience
 I've had with it, it seems like a product with a lot of potential. It fills
 a gap in our project that no other technology can fill. Its biggest
 strength is how relations between services are managed. This is something
 that, to my knowledge, does not exist in any tool today. It enables a very
 modular approach and solves a lot of problems we would have with other
 tools.

Yes, agreed!

 However, I've also seen some things that worry me. Even after three years,
 there are still a lot of bugs in the project. The documentation is lacking,
 especially in the parts of Juju that are the most competitive. The
 community is also very small. The fact that it can still only manage Ubuntu
 servers worries me too. I could go more into detail here, but I don't think
 it is relevant to this question.

I understand what you mean. In part I think this comes from the team
being focused on getting to our key Juju 2.0 milestone, and perhaps not
taking as much time to celebrate the smaller milestones on the way,
especially when they are things that we know need a little more work.
For example, the Windows and CentOS support that has landed is a huge
step, but we know it is still a bit rough and needs more polish. Perhaps
we should be louder about some of those steps to draw in people who
could help provide feedback and patches!


 I'm considering starting a big long-term project on top of Juju. The
 project would be very dependent on Juju, so I don't want to do this if
 there is a chance that Juju will be abandoned in 5 years...

No chance of that.

In my travels now I am glad to say I see a shift in the way people
engage with us about Juju. It used to be why would you want to compete
with Puppet? but now folks understand that we do not want to compete
with Puppet, we want to come up a level and enable people to collaborate
and reuse their puppet / chef / bash / python across different clouds
and environments.

That focus on collaboration and reuse is what makes Juju special. In the
long run we will integrate Juju into places like HEAT so you get the
benefit of charms, together with the underlying cloud information about
performance, so that things like autoscaling are magical, but in the
short term it's easy to think the projects compete. But folks are
starting to understand that now, so I don't get asked why do you not
just do HEAT?.

I also think that it will emerge that there are many levels of
orchestration; Juju will be the BEST for the lowest level of
infrastructure orchestration, but people will use Juju to deploy things
like PAAS which themselves offer a kind of orchestration. So end-users
might use a PAAS, which is like a model or API or orchestration system,
and underneath that, administrators will use Juju for the base level. We
won't try to push Juju into every layer; just like we have kept MAAS and
Juju separate with different interests and different responsibilities,
so now the Chef guys are happy to use MAAS, which is good for us both.


 What can you tell me about the future of Juju? Things I'm interested in:

 - Big companies building services on top of Juju

Pretty much the biggest telco's in the world, and many of the companies
that supply them, are writing charms.

Pretty much the biggest investment banks in the world, are writing charms.

Pretty much the biggest media companies in the world, are writing charms.

Pretty much the biggest big data and machine learning companies, are
writing charms.

Now, of course, those companies also do a lot of OTHER things :) so I
can't say they will all move solely to Juju because they naturally will
not. But smart folks are seeing what you see - the model is amazing. And
if we are able to get the next round of model pieces in place - status,
network, disk - then we'll be able to do some really incredible rapid
deployment and service evolution things.

My biggest concern at the moment is that I think it's too hard to add
interfaces to existing charms. I think about adding say a Nagios
interface to an existing charm - that should be really easy, but I think
we haven't optimised the whole charm development process very well, so I
will host the lead charmers at my house next week for a mini sprint so
they can show me what I'm missing and we can discuss how to make it much
better.

Also, I think we need to really socialise the status work, because it's
too easy for charms to fail mysteriously, and that makes Juju look bad.
So automated testing of charms is going to get even more important.

 - Statements of long-term commitment from Canonical

You heard it from me. I'm personally interested in Juju and it has a
future, for sure, under all the scenarios I can influence. I think the
cloud world needs something like Juju that is cross-platform and
cross-cloud, and I find the project personally challenging and
interesting. Looking at the thread, you also 

Re: What's the future of Juju?

2015-03-26 Thread Alexis Bruemmer
I second Nate's statement!

On Thu, Mar 26, 2015 at 9:04 AM, Nate Finch nate.fi...@canonical.com
wrote:

 I wanted to specifically thank you for pointing out the bugs that affect
 you. It's a huge help in prioritizing what we work on.



 On Wed, Mar 25, 2015 at 5:24 PM, Merlijn Sebrechts 
 merlijn.sebrec...@gmail.com wrote:

 Thanks for your answer! I didn't know Windows and Centos support was
 coming so soon, great to know!

 The lacking documentation is the biggest issue to me. The charm-helpers
 documentation is outdated in a lot of places and that makes it seem as it
 isn't being actively maintained anymore. Ofcourse, this is a side-effect of
 a rapidly expanding product...
 The charm-helpers documentation also lacks some good examples and
 guidelines. Things like What's the best way to create templates, What's
 the easiest way to get relation data, ... The documentation shows you how
 to do it in bash, but is really lacking for python. I had a really hard
 time trying to decipher how the services framework works exactly. Then
 again, this is probably also partly due to the fact that I'm still learning
 my way around python.


 As for the bugs. I submitted/affects me a few:
 Critical:
 https://bugs.launchpad.net/juju-deployer/+bug/1434458

 Medium:
 https://bugs.launchpad.net/charm-tools/+bug/1433035
 https://bugs.launchpad.net/juju-core/+bug/1415176
 https://bugs.launchpad.net/juju-core/+bug/1429790
 https://bugs.launchpad.net/juju-core/+bug/1316174

 Feature request:
 https://bugs.launchpad.net/juju-core/+bug/1432331

 The saltstack charm-helpers integration also has few problems. I just
 gave up on it and wrote the install hooks in python.



 2015-03-25 21:32 GMT+01:00 Nate Finch nate.fi...@canonical.com:

 I'm a core dev on Juju, I can answer some, but not all of these
 questions.

 First off, as far as long term commitment for Juju - Juju is a huge part
 of Canonical's long term strategy... right up there with the Ubuntu Phone
 and Ubuntu itself.  The Juju team has been expanding hugely in the last
 couple years... I forget exactly the numbers we're at now, but it's an
 order of magnitude more people working on Juju than there were just a
 couple years ago.

 Juju is used *extensively* internally at Canonical.  We have a mandate
 that all internal services be deployed via Juju.

 As far as supporting other operating systems, we actually do support
 Windows, right now (though it can be a little tricky to set up, and
 generally only works on private clouds, due to licensing restrictions on
 distributing Windows images).  See here:
 http://www.cloudbase.it/windows-with-juju-and-maas/   (Cloudbase
 partnered with us to get Juju working with Windows)

 Cloudbase is also currently tackling CentOS support.  It currently works
 and is just being cleaned up, it should be available for testing in a few
 weeks.

 The number of features that have landed in the last year is tremendous -
 high availability, networking, storage, major improvements in the GUI,
 support for more clouds (Google Cloud Compute support is coming out with
 1.23, which is due any day now), Windows support, backup and restore

 As for bugs, there are bugs in every product, especially new and rapidly
 expanding products, like Juju.  If there are particular bugs that concern
 you, we'd be happy to look into them.  We try to make sure that we fix
 anything that is a regression or would majorly hinder usage we do use
 this internally after all, so believe me, we hear about it when things
 aren't working well! :)

 I'm sorry you find the documentation lacking. We have been putting
 effort into that recently.  I, personally, am a big fan of extensive
 documentation, and I know our documentation is not nearly as extensive as
 it could be.

 I can't personally talk about big companies using Juju... I know we have
 several very large companies doing very large installations, but I don't
 think anything is public about that.  Hopefully someone else can bring up a
 list of people using Juju.

 Hope that answers at least some of your questions.


 On Wed, Mar 25, 2015 at 4:01 PM, Merlijn Sebrechts 
 merlijn.sebrec...@gmail.com wrote:

 Hi


 I'm interested in what the future of Juju is. From the small experience
 I've had with it, it seems like a product with a lot of potential. It fills
 a gap in our project that no other technology can fill. Its biggest
 strength is how relations between services are managed. This is something
 that, to my knowledge, does not exist in any tool today. It enables a very
 modular approach and solves a lot of problems we would have with other
 tools.

 However, I've also seen some things that worry me. Even after three
 years, there are still a lot of bugs in the project. The documentation is
 lacking, especially in the parts of Juju that are the most competitive. The
 community is also very small. The fact that it can still only manage Ubuntu
 servers worries me too. I could go more into detail here, but I 

RE: What's the future of Juju?

2015-03-26 Thread Cory Benfield
On Thu, Mar 26, 2015 at 14:35:23, Mark Ramm-Christensen (Canonical.com) wrote:
 As promised partners making use of juju as part of the OpenStack
 Interoperability Lab (OIL)  include:
 
 * IBM
 * Microsoft
 * Intel
 * AMD
 * HP
 * Juniper
 * Lenovo
 * Melanox
 * Metaswitch
 * OCP (Open Compute Project)
 * SanDisk
 * VMWare

Metaswitch's engagement with Juju goes beyond the OIL: all of our open source 
products have Juju charms available, many of which are already in the charm 
store with more in review. That said, we have had a lot of success working with 
Juju for OpenStack deployments: on a personal level I've found it the best tool 
in my toolbox for deploying large OpenStack clusters.

We're really happy with where Juju is and where it's going, and we're excited 
to be a part of that. I think there are a lot of reasons to be optimistic about 
Juju's future.

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


Re: What's the future of Juju?

2015-03-25 Thread Mark Ramm-Christensen (Canonical.com)
Well, I can provide a few things off the top of my head that should help.

   - Canonical is fully committed to Juju as the way we deploy software
   internally, the way we deploy Open Stack clouds for our largest clients
   - Windows workloads are supported in the current beta version of Juju,
   and should after a bit of real-world testing be fully supported in one of
   the next (bi-monthly) production ready releases.
   - CentOS support is nearly feature complete, and should enter a beta
   release of Juju for testing within the next month.  Like windows it will
   flow to a production release after it's had some real-world tests.

There are quite a few big companies working on juju charms.  IBM for
example is delivering quite a few charms and has committed multiple full
time development resources to working with juju.

There are also quite a few other big names working on juju charms -- many
of them in the OpenStack space.  I'll get a list of folks who are already
public about being part of our juju based openstack integration labs for
you as soon as I can.

We also have some big plans for products built on top of juju.  The first
of which is the OpenStack Autopilot which automates the deployment,
scale-out, and management of OpenStack clouds.   But, we are also building
more products on top of Juju right now, and it is core to our future plans
in the cloud.

So, to make a long story short, I think juju is gaining traction with some
big enterprise players, Canonical is fully committed to Juju, and we are
seeing momentum pick up in the marketplace.   So, I personally would
definitely bet on a bright future for Juju.

--Mark Ramm





On Wed, Mar 25, 2015 at 4:01 PM, Merlijn Sebrechts 
merlijn.sebrec...@gmail.com wrote:

 Hi


 I'm interested in what the future of Juju is. From the small experience
 I've had with it, it seems like a product with a lot of potential. It fills
 a gap in our project that no other technology can fill. Its biggest
 strength is how relations between services are managed. This is something
 that, to my knowledge, does not exist in any tool today. It enables a very
 modular approach and solves a lot of problems we would have with other
 tools.

 However, I've also seen some things that worry me. Even after three years,
 there are still a lot of bugs in the project. The documentation is lacking,
 especially in the parts of Juju that are the most competitive. The
 community is also very small. The fact that it can still only manage Ubuntu
 servers worries me too. I could go more into detail here, but I don't think
 it is relevant to this question.

 I'm considering starting a big long-term project on top of Juju. The
 project would be very dependent on Juju, so I don't want to do this if
 there is a chance that Juju will be abandoned in 5 years...

 What can you tell me about the future of Juju? Things I'm interested in:

 - Big companies building services on top of Juju

 - Statements of long-term commitment from Canonical

 - Usage statistics

 - Statements of commitment to support other distro's

 - .. or else, signs that Juju doesn't have a bright future.


 Thanks

 --
 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: What's the future of Juju?

2015-03-25 Thread Merlijn Sebrechts
Thanks for your answer! I didn't know Windows and Centos support was coming
so soon, great to know!

The lacking documentation is the biggest issue to me. The charm-helpers
documentation is outdated in a lot of places and that makes it seem as it
isn't being actively maintained anymore. Ofcourse, this is a side-effect of
a rapidly expanding product...
The charm-helpers documentation also lacks some good examples and
guidelines. Things like What's the best way to create templates, What's
the easiest way to get relation data, ... The documentation shows you how
to do it in bash, but is really lacking for python. I had a really hard
time trying to decipher how the services framework works exactly. Then
again, this is probably also partly due to the fact that I'm still learning
my way around python.


As for the bugs. I submitted/affects me a few:
Critical:
https://bugs.launchpad.net/juju-deployer/+bug/1434458

Medium:
https://bugs.launchpad.net/charm-tools/+bug/1433035
https://bugs.launchpad.net/juju-core/+bug/1415176
https://bugs.launchpad.net/juju-core/+bug/1429790
https://bugs.launchpad.net/juju-core/+bug/1316174

Feature request:
https://bugs.launchpad.net/juju-core/+bug/1432331

The saltstack charm-helpers integration also has few problems. I just gave
up on it and wrote the install hooks in python.



2015-03-25 21:32 GMT+01:00 Nate Finch nate.fi...@canonical.com:

 I'm a core dev on Juju, I can answer some, but not all of these questions.


 First off, as far as long term commitment for Juju - Juju is a huge part
 of Canonical's long term strategy... right up there with the Ubuntu Phone
 and Ubuntu itself.  The Juju team has been expanding hugely in the last
 couple years... I forget exactly the numbers we're at now, but it's an
 order of magnitude more people working on Juju than there were just a
 couple years ago.

 Juju is used *extensively* internally at Canonical.  We have a mandate
 that all internal services be deployed via Juju.

 As far as supporting other operating systems, we actually do support
 Windows, right now (though it can be a little tricky to set up, and
 generally only works on private clouds, due to licensing restrictions on
 distributing Windows images).  See here:
 http://www.cloudbase.it/windows-with-juju-and-maas/   (Cloudbase
 partnered with us to get Juju working with Windows)

 Cloudbase is also currently tackling CentOS support.  It currently works
 and is just being cleaned up, it should be available for testing in a few
 weeks.

 The number of features that have landed in the last year is tremendous -
 high availability, networking, storage, major improvements in the GUI,
 support for more clouds (Google Cloud Compute support is coming out with
 1.23, which is due any day now), Windows support, backup and restore

 As for bugs, there are bugs in every product, especially new and rapidly
 expanding products, like Juju.  If there are particular bugs that concern
 you, we'd be happy to look into them.  We try to make sure that we fix
 anything that is a regression or would majorly hinder usage we do use
 this internally after all, so believe me, we hear about it when things
 aren't working well! :)

 I'm sorry you find the documentation lacking. We have been putting effort
 into that recently.  I, personally, am a big fan of extensive
 documentation, and I know our documentation is not nearly as extensive as
 it could be.

 I can't personally talk about big companies using Juju... I know we have
 several very large companies doing very large installations, but I don't
 think anything is public about that.  Hopefully someone else can bring up a
 list of people using Juju.

 Hope that answers at least some of your questions.


 On Wed, Mar 25, 2015 at 4:01 PM, Merlijn Sebrechts 
 merlijn.sebrec...@gmail.com wrote:

 Hi


 I'm interested in what the future of Juju is. From the small experience
 I've had with it, it seems like a product with a lot of potential. It fills
 a gap in our project that no other technology can fill. Its biggest
 strength is how relations between services are managed. This is something
 that, to my knowledge, does not exist in any tool today. It enables a very
 modular approach and solves a lot of problems we would have with other
 tools.

 However, I've also seen some things that worry me. Even after three
 years, there are still a lot of bugs in the project. The documentation is
 lacking, especially in the parts of Juju that are the most competitive. The
 community is also very small. The fact that it can still only manage Ubuntu
 servers worries me too. I could go more into detail here, but I don't think
 it is relevant to this question.

 I'm considering starting a big long-term project on top of Juju. The
 project would be very dependent on Juju, so I don't want to do this if
 there is a chance that Juju will be abandoned in 5 years...

 What can you tell me about the future of Juju? Things I'm interested in:

 - Big companies building 

Re: What's the future of Juju?

2015-03-25 Thread Nate Finch
I'm a core dev on Juju, I can answer some, but not all of these questions.

First off, as far as long term commitment for Juju - Juju is a huge part of
Canonical's long term strategy... right up there with the Ubuntu Phone and
Ubuntu itself.  The Juju team has been expanding hugely in the last couple
years... I forget exactly the numbers we're at now, but it's an order of
magnitude more people working on Juju than there were just a couple years
ago.

Juju is used *extensively* internally at Canonical.  We have a mandate that
all internal services be deployed via Juju.

As far as supporting other operating systems, we actually do support
Windows, right now (though it can be a little tricky to set up, and
generally only works on private clouds, due to licensing restrictions on
distributing Windows images).  See here:
http://www.cloudbase.it/windows-with-juju-and-maas/   (Cloudbase partnered
with us to get Juju working with Windows)

Cloudbase is also currently tackling CentOS support.  It currently works
and is just being cleaned up, it should be available for testing in a few
weeks.

The number of features that have landed in the last year is tremendous -
high availability, networking, storage, major improvements in the GUI,
support for more clouds (Google Cloud Compute support is coming out with
1.23, which is due any day now), Windows support, backup and restore

As for bugs, there are bugs in every product, especially new and rapidly
expanding products, like Juju.  If there are particular bugs that concern
you, we'd be happy to look into them.  We try to make sure that we fix
anything that is a regression or would majorly hinder usage we do use
this internally after all, so believe me, we hear about it when things
aren't working well! :)

I'm sorry you find the documentation lacking. We have been putting effort
into that recently.  I, personally, am a big fan of extensive
documentation, and I know our documentation is not nearly as extensive as
it could be.

I can't personally talk about big companies using Juju... I know we have
several very large companies doing very large installations, but I don't
think anything is public about that.  Hopefully someone else can bring up a
list of people using Juju.

Hope that answers at least some of your questions.


On Wed, Mar 25, 2015 at 4:01 PM, Merlijn Sebrechts 
merlijn.sebrec...@gmail.com wrote:

 Hi


 I'm interested in what the future of Juju is. From the small experience
 I've had with it, it seems like a product with a lot of potential. It fills
 a gap in our project that no other technology can fill. Its biggest
 strength is how relations between services are managed. This is something
 that, to my knowledge, does not exist in any tool today. It enables a very
 modular approach and solves a lot of problems we would have with other
 tools.

 However, I've also seen some things that worry me. Even after three years,
 there are still a lot of bugs in the project. The documentation is lacking,
 especially in the parts of Juju that are the most competitive. The
 community is also very small. The fact that it can still only manage Ubuntu
 servers worries me too. I could go more into detail here, but I don't think
 it is relevant to this question.

 I'm considering starting a big long-term project on top of Juju. The
 project would be very dependent on Juju, so I don't want to do this if
 there is a chance that Juju will be abandoned in 5 years...

 What can you tell me about the future of Juju? Things I'm interested in:

 - Big companies building services on top of Juju

 - Statements of long-term commitment from Canonical

 - Usage statistics

 - Statements of commitment to support other distro's

 - .. or else, signs that Juju doesn't have a bright future.


 Thanks

 --
 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: What's the future of Juju?

2015-03-25 Thread Michael Nelson
On Thu, Mar 26, 2015 at 8:24 AM, Merlijn Sebrechts
merlijn.sebrec...@gmail.com wrote:
 Thanks for your answer! I didn't know Windows and Centos support was coming
 so soon, great to know!

 The lacking documentation is the biggest issue to me. The charm-helpers
 documentation is outdated in a lot of places and that makes it seem as it
 isn't being actively maintained anymore. Ofcourse, this is a side-effect of
 a rapidly expanding product...
 The charm-helpers documentation also lacks some good examples and
 guidelines. Things like What's the best way to create templates, What's
 the easiest way to get relation data, ... The documentation shows you how
 to do it in bash, but is really lacking for python. I had a really hard time
 trying to decipher how the services framework works exactly.

The services framework is quite new... I've not yet had the chance to
use it yet either.

 The saltstack charm-helpers integration also has few problems. I just gave
 up on it and wrote the install hooks in python.

... and yes, I'll try to get some time to reevaluate the saltstack
charm-helpers intergration and see whether it should be fixed or
removed. We (the team I work in) used it initially for some charms,
but then migrated quite soon to use the ansible support which we're
using now, but the next time we write a new charm, we'll evaluate the
services framework instead.

So the issue with the salt support may be that there are no charms
(that I'm aware of) using it and so it is not being integration-tested
regularly (though I'm keen to check).

I'd recommend exactly what you're doing - starting your charm in plain
python. As you develop the charm, you may start to understand the need
for, and use the services framework (or other charm-helper-provided
support).

Cheers,
-Michael





 2015-03-25 21:32 GMT+01:00 Nate Finch nate.fi...@canonical.com:

 I'm a core dev on Juju, I can answer some, but not all of these questions.

 First off, as far as long term commitment for Juju - Juju is a huge part
 of Canonical's long term strategy... right up there with the Ubuntu Phone
 and Ubuntu itself.  The Juju team has been expanding hugely in the last
 couple years... I forget exactly the numbers we're at now, but it's an order
 of magnitude more people working on Juju than there were just a couple years
 ago.

 Juju is used extensively internally at Canonical.  We have a mandate that
 all internal services be deployed via Juju.

 As far as supporting other operating systems, we actually do support
 Windows, right now (though it can be a little tricky to set up, and
 generally only works on private clouds, due to licensing restrictions on
 distributing Windows images).  See here:
 http://www.cloudbase.it/windows-with-juju-and-maas/   (Cloudbase partnered
 with us to get Juju working with Windows)

 Cloudbase is also currently tackling CentOS support.  It currently works
 and is just being cleaned up, it should be available for testing in a few
 weeks.

 The number of features that have landed in the last year is tremendous -
 high availability, networking, storage, major improvements in the GUI,
 support for more clouds (Google Cloud Compute support is coming out with
 1.23, which is due any day now), Windows support, backup and restore

 As for bugs, there are bugs in every product, especially new and rapidly
 expanding products, like Juju.  If there are particular bugs that concern
 you, we'd be happy to look into them.  We try to make sure that we fix
 anything that is a regression or would majorly hinder usage we do use
 this internally after all, so believe me, we hear about it when things
 aren't working well! :)

 I'm sorry you find the documentation lacking. We have been putting effort
 into that recently.  I, personally, am a big fan of extensive documentation,
 and I know our documentation is not nearly as extensive as it could be.

 I can't personally talk about big companies using Juju... I know we have
 several very large companies doing very large installations, but I don't
 think anything is public about that.  Hopefully someone else can bring up a
 list of people using Juju.

 Hope that answers at least some of your questions.


 On Wed, Mar 25, 2015 at 4:01 PM, Merlijn Sebrechts
 merlijn.sebrec...@gmail.com wrote:

 Hi


 I'm interested in what the future of Juju is. From the small experience
 I've had with it, it seems like a product with a lot of potential. It fills
 a gap in our project that no other technology can fill. Its biggest strength
 is how relations between services are managed. This is something that, to my
 knowledge, does not exist in any tool today. It enables a very modular
 approach and solves a lot of problems we would have with other tools.

 However, I've also seen some things that worry me. Even after three
 years, there are still a lot of bugs in the project. The documentation is
 lacking, especially in the parts of Juju that are the most competitive. The
 community is also