Re: Juju stable 1.25.0 is released

[Richard Harding]

On Mon, 02 Nov 2015, Dimiter Naydenov wrote:

> On 30.10.2015 01:06, Pshem Kowalczyk wrote:
> >
> > Hi
> >
> > On Fri, 30 Oct 2015 at 08:03 Curtis Hovey-Canonical
> > mailto:cur...@canonical.com>> wrote:
> >
> > {cut}
> >
> > ### Support "devices" on MAAS 1.8+
> >
> > MAAS 1.8 introduced a new feature called "devices". This allows
> > the association of a "device", that requires an IP address, with a
> > parent machine managed by MAAS. There is a view in the MAAS UI
> > showing all devices.
> >
> > With the "address-allocation" feature flag enabled, Juju will
> > register LXC and KVM containers as devices on MAAS 1.8+. They are
> > visible in the MAAS UI. If the environment is forcibly shut down,
> > the IP addresses allocated to the containers will be released by
> > MAAS.
> >
> > You can enable "address-allocation" is new Juju environments like
> > so:
> >
> > JUJU_DEV_FEATURE_FLAG=address-allocation juju bootstrap
> >
> >
> >
> > Are they any other requirements in order to get the "devices"
> > feature working? I've just built a  brand new MAAS
> > (1.8.2+bzr4041-0ubuntu1) and juju (1.25.0, from PPA) setup,
> > bootstrapped a new environment using the syntax provided above, but
> > the containers are not getting registered under 'MAAS devices'.
> >
> This is because recently MAAS web UI changed not to show devices as
> before. However, juju should still be registering them for containers
> and this can be verified by using the MAAS CLI:
>
> $ maas  devices list

Copying in Andres to ask if MAAS 1.9alpha has that UI support or is it
part of the planned 2.0 releaes?

--
Rick Harding

Juju 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

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

Re: Downgrade a charm

[Richard Harding]

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

Re: What basic services are you missing in the charm store?

[Richard Harding]

On Mon, 24 Aug 2015, Jorge O. Castro wrote:

> Hi everyone,
>
> I'm taking a quick informal survey. We have teams working on things
> like really complicated big data stacks[1] and container orchestration
> awesomeness[2].
>
> However I wanted to take a minute to ask people what basic, normal,
> boring services they feel are missing from the charm store. Things
> that we tend to forget because we're thinking of the complex problems.
> For example, Robie Basak pointed out to me that it'd be nice to have a
> "mail-in-the-box" style bundle that did a secure, simple mail server
> stack and that it'd be nice to have a promoted "just a blog" bundle
> that is more straightforward.
>
> Things of that sort.
>
> 1: https://jujucharms.com/u/bigdata-dev/realtime-syslog-analytics
> 2: https://github.com/kubernetes/kubernetes/tree/master/cluster/juju/bundles


With the recent discussion and focus on things for developers there's a
couple I think that would be cool

One that I think would be cool is sentry [1][2]. It's a great debugging tool
for python applications and if things like the django framework charm
supported it ootb it'd make an amazing one-two punch for developers. It can
also be used from ruby and other languages. newrelic [3] is another in this
category. I see a charm was created but not tried it out [4]

The other I think that would be great would be nginx [5]. I know personally
I've used it to replace apache, haproxy, and squid into a single service.
If that were able to work with SSL termination, static file caching, and
proxying scaled up applications behind it, that'd be great for a density
story, good development practices story, etc.

I sure wish we could package up travisci as that would be awesome to go
with folks code and run your own internally/etc.


1: https://getsentry.com/welcome/
2: https://github.com/getsentry/sentry
3: http://newrelic.com/application-monitoring
4: https://jujucharms.com/newrelic/precise/3
5: https://launchpad.net/ubuntu/+source/nginx

--

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

Re: How should we change default config values in charms?

[Richard Harding]

On Mon, 17 Aug 2015, Jorge O. Castro wrote:

> On Mon, Aug 17, 2015 at 6:03 AM, Simon Davy  wrote:
> > Interesting. We have been defaulting to production settings, as we
> > don't want to deploy an incorrect/unsafe config in production by
> > omission, especially security related config.
>
> Interesting indeed! That's totally opposite of what I was expecting; I
> was expecting you to be explicit across the board.
>
> Also if anyone from Canonical IS can chip in I would be interested as well.

For our IS deployed services we use the Mojo tool to 'variable-ize' our
bundle/deployer file with config that changes based on the 'stage' and we
have stages for local, testing, staging, and production.

--

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

Re: [Juju-gui-peeps] juju docs search on jujucharms.com down

[Richard Harding]

On Thu, 23 Jul 2015, Richard Harding wrote:

> FYI, due to a release with a bug in it the search for Juju documentation at
> jujucharms.com is erroring. The team is investigating and will be fixing as
> soon as possible.

This has been corrected. We had a bad migration in elasticsearch and a lack
of visibility into the docs search process. We've added work items for both
migrations and better logging during searches.

Thanks everyone for your patience. If you run into any issues please don't
hesitate to let me know and we'll get them taken care of.

--

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

juju docs search on jujucharms.com down

[Richard Harding]

FYI, due to a release with a bug in it the search for Juju documentation at
jujucharms.com is erroring. The team is investigating and will be fixing as
soon as possible.

Note that individual pages do work and you can fall back to Google for
links in the meantime. e.g. https://goo.gl/5oWP2o

--

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

Re: jujucharms.com and charmstore outage in progress

[Richard Harding]

On Tue, 14 Jul 2015, Richard Harding wrote:

> FYI: there's currently an issue with the storage system that the charmstore
> and jujucharms.com are deployed to. The IS team is aware and working on
> this and we're tracking their updates to make sure to get things back asap.
> 
> This means that the jujucharms.com urls that hit the charmstore and related
> sections are not functioning.
> 
> Users of juju 1.24.0 and higher will be unable to do a deploy from the
> charmstore until the outage is resolved.
> 
> I'll reply to this email with updates and if you have any questions please
> feel free to ask me in #juju or #juju-gui on freenode. (irc nick rick_h)

The IS team has worked hard to bring up more storage and services are
responding. Note that performance isn't optimal and you might get a timeout
while the storage system rebalances, and syncs up.

If you hit any consistent issues please let us know and we'll investigate.

Thanks everyone for your patience.

-- 

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

jujucharms.com and charmstore outage in progress

[Richard Harding]

FYI: there's currently an issue with the storage system that the charmstore
and jujucharms.com are deployed to. The IS team is aware and working on
this and we're tracking their updates to make sure to get things back asap.

This means that the jujucharms.com urls that hit the charmstore and related
sections are not functioning.

Users of juju 1.24.0 and higher will be unable to do a deploy from the
charmstore until the outage is resolved.

I'll reply to this email with updates and if you have any questions please
feel free to ask me in #juju or #juju-gui on freenode. (irc nick rick_h)


--

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

Re: Important: upgrading a 1.23 environment

[Richard Harding]

+1 if there's any way we can provide a script to automate this then I'd
suggest to go that route. The less we ask users to do the better and I know
some folks internally are running 1.23 and a tested/scripted upgrade tool
would be useful to share around.

Rick

On Fri, 26 Jun 2015, Charles Butler wrote:

> Menno,
> 
> This is a good find to raise publicly; however I wonder if we couldn't
> offer something up to users that are being caught by this rather than a
> suggested workaround, and more as a "Run this patch to correct the issue" -
> as these things look like they can be scripted, and included in the 1.23
> release as a patch.
> 
> I however don't know the level of effort involved in that.
> 
> All the best,
> 
> 
> Charles Butler  - Juju Charmer
> Come see the future of datacenter orchestration: http://jujucharms.com
> 
> On Fri, Jun 26, 2015 at 12:45 AM, Menno Smits 
> wrote:
> 
> > All,
> >
> > Due to a new worker that was added in 1.23, it is likely that the state
> > server agents will be unable to restart when an upgrade of a 1.23
> > environment is requested.
> >
> > Manual intervention will be required to unstick the upgrade. On each state
> > server host do the following:
> >
> >- Find the tools directory.
> >- For the local provider this will be something like
> >   ~/.juju/local/tools
> >   - For other providers this will be /var/lib/juju/tools
> >   - You should see both the old and the new tools listed with a
> >symlink for the machine agent pointing to the old version. For example:
> >
> > drwxr-xr-x 2 root root 4096 May 27 21:18 1.23.3.1-trusty-amd64
> > drwxr-xr-x 2 root root 4096 Jun 16 11:35 1.24.0-trusty-amd64
> > lrwxrwxrwx 1 root root 21 May 27 21:18 machine-0 ->
> > 1.23.3.1-trusty-amd64
> >
> >- Remove the old symlink, e.g.: sudo rm machine-0
> >- Add one that points to the new tools, e.g.: sudo ln -s
> >1.24.0-trusty-amd64 machine-0
> >- Kill the machine agent so that it restarts into the new version:
> >sudo pkill jujud
> >
> > The upgrade will then proceed as normal.
> >
> > It's regrettable that this is required. Unfortunately but because upgrades
> > themselves get blocked we can't easily offer an upgrade that fixes the
> > problem.
> >
> > The root cause was fixed in 1.24.0 so upgrading directly to 1.24.0 or
> > later (skipping 1.23) will avoid the issue.
> >
> > - Menno
> >
> >
> > --
> > 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: jujucharms.com not able to ingest charm and bundles at this time

[Richard Harding]

Hello Victor, a while back there was a move to the openstack bundle. The
promulgated version is called openstack-base. We'd suggest you move to that
official channel for the bundle.

Notice of the bundle move:
https://lists.ubuntu.com/archives/juju/2015-April/005205.html

New bundle url:
https://jujucharms.com/openstack-base/34

You are right that after the move we left the old bundle in case folks were
still using it and when we reloaded the store that out of date data was not
brought with it.

Please let me know if the bundle openstack-base has any issues for you.

Rick

On Thu, 18 Jun 2015, Victor Estival wrote:

> Hello:
> 
> Since yesterday I am having problems accessing to the bundle for OpenStack
> created by openstack-charmers [1]... might it be related with this?
> 
> [1] https://jujucharms.com/u/openstack-charmers/openstack/25
> 
> Best regards,
> 
> Victor Estival 
> Mobile: *+44 7788 234976*
> Cloud Architect
> 
> 
> On Wed, Jun 17, 2015 at 3:40 PM, Richard Harding  > wrote:
> 
> > On Wed, 17 Jun 2015, Richard Harding wrote:
> >
> > > I apologize that this has taken so long to go out. I wanted to let
> > everyone
> > > know that the UI Engineering team has been fighting to get a new
> > > environment for jujucharms.com up and running. We have not been
> > successful
> > > to date however.
> >
> > I'm happy to report the team has worked with webops with a patched store.
> >
> > Charm ingestion is running and the latest charms should all be available.
> > If you find any issues please let me know.
> >
> > A side note is that this release includes a bunch of new work including a
> > new Juju GUI, but I'll post that as its own email.
> >
> > Thank you everyone for your patience while we got this fixed up and working
> > smoothly again.
> >
> > --
> >
> > Rick Harding
> >
> > Juju UI Engineering
> > https://launchpad.net/~rharding
> > @mitechie
> >
> > --
> > solutions-architects mailing list
> > solutions-archite...@lists.canonical.com
> > Modify settings or unsubscribe at:
> > https://lists.canonical.com/mailman/listinfo/solutions-architects
> >

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

juju 1.24 now talking to api.jujucharms.com

[Richard Harding]

Congrats to the Juju Core team on their 1.24 release. I wanted to make sure
everyone realized one big change in there. With this release, Juju uses the
new charmstore api (api.jujucharms.com/charmstore) in order to deploy
charms and provide upgrades. This is a different service and has a
documented api available here:

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

This means that you might see cases where a charm deploys slightly
differently in 1.23 (or older) and 1.24. Their timings might be a bit off,
but it should be pretty consistent. If you run into any issues please feel
free to file bugs at:

https://github.com/CanonicalLtd/jujucharms.com/issues

--

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

Re: jujucharms.com not able to ingest charm and bundles at this time

[Richard Harding]

On Wed, 17 Jun 2015, Richard Harding wrote:

> I apologize that this has taken so long to go out. I wanted to let everyone
> know that the UI Engineering team has been fighting to get a new
> environment for jujucharms.com up and running. We have not been successful
> to date however.

I'm happy to report the team has worked with webops with a patched store. 

Charm ingestion is running and the latest charms should all be available.
If you find any issues please let me know.

A side note is that this release includes a bunch of new work including a
new Juju GUI, but I'll post that as its own email.

Thank you everyone for your patience while we got this fixed up and working
smoothly again.

-- 

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

jujucharms.com not able to ingest charm and bundles at this time

[Richard Harding]

I apologize that this has taken so long to go out. I wanted to let everyone
know that the UI Engineering team has been fighting to get a new
environment for jujucharms.com up and running. We have not been successful
to date however.

Currently we're running off our old staging site which is not able to run
our ingestion scripts that pull charm and bundle updates from launchpad.
When run, they trigger an issue that causes mongodb to crash and go down.
Mongodb is used to store the data for the charmstore on jujucharms.com.

The team has worked hard this past week to fix those issues and we spent
the last two days attempting to get those fixes into a new environment with
the great help of webops. Unfortunately we've hit an additional bug that
the team has to go back and look into.

The issue is critical and the team is investigating immediately. Our hope
is that it's small and we can attempt to get things going again tomorrow.
However, at this point we do not have a firm date and time for when full
service will be restored.

I want to apologize that this email was not sent out immediately upon the
service issues. This has been noted within the team and a new process put
into place to make sure that any time we have an issue that effects users
of our systems we're up front and clear on what's going on and when you can
expect things to return to normal.

If you have any questions please don't hesitate to ping me on irc (rick_h)
or via email and I will do my best to help in any way I can.

Thank you all for your patience and understanding.

--

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

Re: Upcoming change in 1.24: tags in EC2

[Richard Harding]

On Tue, 26 May 2015, Andrew Wilkins wrote:

> On Tue, May 26, 2015 at 4:05 AM, Mark Shuttleworth  wrote:
>
> > On 25/05/15 18:57, Kapil Thangavelu wrote:
> > > That's super awesome, and very helpful for real world usage. A few
> > > suggestions, For users with multiple environments, seeing a bunch
> > > machine-0 in the ui, is rather confusing, i'd suggest prefixing with
> > > the env name. Potentially even more useful is actually naming the
> > > machines not for their pet names, but their cattle names (workload
> > > name), ie. name with the primary unit that caused the machine to
> > > exist, or was the first unit assigned to the machine (minus state
> > > servers).
> >
> > Agreed; for full chargeback we need environment uuid, for social
> > debugging we need some sort of environment name, unit names and charm(s)
> > deployed, including in containers on the machine. For EBS it would be
> > the store name, uuid, and unit identity.
> >
>
> Kapil, Mark, thanks for the suggestions. Sounds good, I'll look at doing
> that.
>
> A concern I have is that these resources can be reassigned (units added,
> volume
> assigned to different store) so those tags would then be misleading. That's
> the main
> reason why I avoided including information about the workload/store in the
> name. I
> suppose the benefit outweighs, and we could look at updating tags later on.
>
> Cheers,
> Andrew

One suggestion is being careful about what tags might already exist on a
machine that a user might have set through their own control UI. If Juju is
tracking tags it sets we should make sure it never messed with ones it did
not set.

--

Rick Harding

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

new release to jujuchaarms.com

[Richard Harding]

A new release of jujucharms.com hit production today. Updates include
improvements to search, a new header, and improvements to the logged in
experience.

Search improvements

- collapsed search results by series when the charm/owner are the same
- a new sorting/filter drop down the results


New Header

- A new design and some UX improvements of the header as we work towards a
  new experience there. This is stage one of the changes.

Fixes for logged in users

- Correct issue for those with a large number of launchpad groups
- Updated profile page UX


and many bugs/smaller updates for all to enjoy. As always,
please let us know what you think and feel free to file bugs at:

https://github.com/CanonicalLtd/jujucharms.com/issues

For those of you wanting more, keep an eye out for an upcoming Juju GUI
release which will include full support for editing bundles before
deploying them to your environment.


--

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

new release on jujucharms.com

[Richard Harding]

The Juju UI Engineering team is proud to announce a new release to
jujucharms.com.

Highlights include:

- Moved the /solutions page to /store and added the new header with the
  OpenStack topic page.
- Improvements to the logged in profile page.
- Improvements to the solutions page header.
- Search result style improvements.
- Search result sorting improvements.

The Juju GUI was also updated on the demo.jujucharms.com url with updates
including:

- Allow deployment of basketless bundles (new bundle syntax) in sandbox
  mode. This is known as the v4 bundles and some initial docs can be found
  at https://github.com/juju/charmstore/blob/v4/docs/bundles.md

  Of note is the ability to specify the new 'machines' section. This
  support works in real environments and an upcoming release will add
support
  to the fake demo mode of the GUI.

Also note that the team's completed work to update Juju to talk to the new
charmstore v4 api which will be included in the 1.24 release. This means
that Juju will support authenticated charm access coming soon. We'll have
more news and details for this as 1.24 progresses.

As always, if you have any questions let us know and please file any bugs
found at: https://github.com/CanonicalLtd/jujucharms.com/issues


--

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

new release of jujucharms.com

[Richard Harding]

The Juju UI Engineering team is proud to announce a new release of
jujucharms.com. This release includes a few nice features.

Versioned Juju Docs Support:

This still needs some coordination with the docs team and some love from
the UX team but we now pull and build the docs for multiple releases. By
default we go to the 'stable' release and you can view the older versions
as well as upcoming docs.

https://jujucharms.com/docs
https://jujucharms.com/docs/1.18
https://jujucharms.com/docs/devel


Updated Search Results Design:

There's also the first iteration of a new search results design:

https://jujucharms.com/q/owncloud

We'll continue to iterate on that and reduce the duplicate results per
series and such in our next upcoming releases.


New OpenStack Topic Page:

This isn't yet linked from the /solutions page but will be in the next
release but we've implemented the openStack topic page. We've had some good
reviews and feedback so we'll be working on fixing a couple of typos and
looking at adding some additional content, but please take a look and
hopefully this will be useful for those talking about OpenStack to others.

https://jujucharms.com/openstack

Note that this caused a url collision in the site because the openstack
base bundle was under the url /openstack. That bundle has been renamed and
moved to the url /openstack-base.

https://jujucharms.com/openstack-base

Please make sure to update any links and bookmarks you have. The good thing
is that it's the first bundle on the new /openstack page so it should be
easy to find.

And there's a nice handful of bug fixes and tweaks for everyone to enjoy.

As always, please let us know what you think and feel free to file bugs at:

https://github.com/CanonicalLtd/jujucharms.com/issues


--

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

Re: new juju-gui but more importantly, new juju charmstore api

[Richard Harding]

On Fri, 03 Apr 2015, John Meinel wrote:

> On Fri, Apr 3, 2015 at 7:47 AM, Richard Harding 
> wrote:
>
> >
> > tl;dr
> >
> > The new v4 API is out there go migrate to it. v3 API will be EOL'd at the
> > end of the year.
> >
>
> Doesn't that EOL the version of Juju that is in trusty? Yes we'll release a
> new version, but people won't be able to deploy with the old version.
>
> John
> =:->

Sorry for the confusion. The v3 api is the charmworld one [1]. That service
will be shut down. Yes, we'll continue to suppor the legacy charmstore api
until we're confident we can shut down due to lack of Juju support which
will be a different timeline.

1: manage.jujucharms.com

--

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

new juju-gui but more importantly, new juju charmstore api

[Richard Harding]

tl;dr

The new v4 API is out there go migrate to it. v3 API will be EOL'd at the
end of the year.

For those with some time and a coffee on their hands:

The UI Engineering team is happy to announce a new release of the Juju GUI
today. You can get the details on it at the blog post:

https://jujugui.wordpress.com/2015/04/02/juju-gui-1-3-5-cutting-ties-release/

It's a pretty invisible release to users but it completes a line of
important work. The Juju GUI now speaks exclusively to the new charmstore
'v4' api [1]. This is the new charm store powering jujucharms.com. We've
also landed updates to juju-quickstart and are almost done updating juju
itself (targeted at 1.24) to talking to the new API.

We'd like to help everyone move to this API from the legacy charmstore API
[2] and the old charmworld API [3]. We know a lot of folks have scripts and
tools using the older APIs. There's a library, charmworldlib [4], that was
written to assist with this.

To help folks move on to the new API we've started a new python library
codenamed 'theblues' [5] that everyone can get access to in the Juju github
organization and it's available from pypi [6] as well. We have the library
under the CI with the Juju GUI [7] and have a hacking doc [8] for those
interested in helping build out the library and contributing updates, docs,
and example usage.

WARNINGS:

The old charmworld API will be EOL'd at the end of the year. While it's
true it'll be around for a while yet, the data from there will start to
skew as we add new features to the charmstore that the old charmworld
system is not able to handle. So you might find charms, search results, and
metadata out of sync as the systems diverge over the course of the year. So
this is our heads up that sooner is better for any migrations.

Help us help you!

We know migrations to new APIs are painful, we've been working on it
through the GUI, quickstart, and all of our tools over the last few months.
Please let us know how we can help. Feel free to hop into #juju-gui and ask
for any assistance and please join the community and help improve the
tooling and docs. And yes, this is selfish as we don't want to support 3
different systems any longer. Three cheers to a single point of
trusty...soon!

1: https://github.com/juju/charmstore/blob/v4/docs/API.md
2: https://store.juju.ubuntu.com
3: https://manage.jujucharms.com/api/3
4: https://launchpad.net/charmworldlib
5: https://github.com/juju/theblues
6: https://pypi.python.org/pypi/theblues
7: http://ci.jujugui.org:8080/job/theblues-lib/
8: https://github.com/juju/theblues/blob/develop/HACKING.rst


--

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

new jujucharms.com and Juju GUI release

[Richard Harding]

The Juju UI Engineering team is proud to announce a pair of releases today.
First, the Juju GUI was updated with a couple of bug fixes and some
performance improvements.

- Service icons on the canvas no longer bounce back to their original
  positions when being repositioned.
- Bundle deploys no longer fail with invalid name error.

Upgrade your Juju GUI with:

juju upgrade-charm juju-gui
juju set juju-gui “juju-gui-source=1.3.3″


The team is also proud to update the jujucharms.com with the latest series
of bug fixes and features. Some notable things to look out for:

- Update bundle visualizations.
- Add sitemap.xml support. (Let's go better Google juice!)
- Add robots.txt for web crawlers
- Update the videos from the insights feed in the community page.
- Fix routing issues around ending with slashes.
- Generate versioned jujudocs. (Exposing them via urls will be in the next
  release.)
- Anchors for charm config keys working well with sticky header.
- A number of back end to the charmstore and how charms are handled.

As always, please try it out and let us know if you find any issues by
filing a bug:

https://github.com/CanonicalLtd/jujucharms.com/issues

Thanks for the teams that put in such hard work and we look forward to the
next scheduled release at the end of the month.

--

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

Re: new juju quickstart 2.0 and releases of jujucharms.com and the Juju GUI

[Richard Harding]

On Thu, 05 Mar 2015, Richard Harding wrote:

> The UI Engineering team is proud to announce a series of releases from this
> week.

While not technically a release I also wanted to note that we've now setup
redirects from juju.ubuntu.com and manage.jujucharms.com. This means that
old urls such as juju.ubuntu.com/docs now head over to jujucharms.com.

We've tried to test and make sure the redirects are solid. Please let us
know if you find any issues and we'll work to get them addressed asap. Feel
free to file any bug reports at:

https://github.com/CanonicalLtd/jujucharms.com/issues

One nice side effect is that it looks like our Google Fu is picking up and
we'll continue to work with the web team to improve things.

https://www.google.com/search?q=juju%20myql&rct=

This brings us a single online home of Juju to support, improve, and
maintain.

Thanks for all the help from the web team on making this happen!

--

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

new juju quickstart 2.0 and releases of jujucharms.com and the Juju GUI

[Richard Harding]

The UI Engineering team is proud to announce a series of releases from this
week.

The big update is juju-quickstart hitting 2.0. You can find all the details
in the blog post [1] but the big thing to be aware of is that
juju-quickstart now talks to the new charmstore and uses the apiv4 [2].
Part of this is support for deploying bundles using the new jujucharms.com
ID syntax.  What's great is that the url you see on jujucharms.com is now
the ID you pass to juju-quickstart.

We also released new versions of jujucharms.com and the Juju GUI. Both of
which are updated so that the deployment instructions for bundles use the
new juju-quickstart 2.0 syntax. What's great is that the new commands are
shorter and simpler. For a promulgated bundle this is as nice as:

juju quickstart transcode-cloud

jujucharms.com got numerous bug fixes along with updating sharing to
twitter and Google+. You can check out that we now have full charm icon
support in sharing so when you share out a charm it'll look even more
awesome.

https://plus.google.com/116120911388966791792/posts/M3hE8oF1S9y
https://twitter.com/mitechie/status/573498215116369921

The Juju GUI also had a few bugs fixed, some more api calls moved to the
newer and much faster charmstore v4 api, and updated deployment
instructions for the new juju-quickstart 2.0

Thank you all for the great feedback and bug reports and we'll continue to
make things better and are working on our updates for the next release
scheduled to happen on the 16th.

1: https://jujugui.wordpress.com/2015/03/03/juju-quickstart-2-0
2: https://github.com/juju/charmstore/blob/v4/docs/API.md

--

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

Re: New Error With juju-deployer

[Richard Harding]

Just to confirm the new package is available in the juju stable PPA now.

Rick

On Sat, 28 Feb 2015, Richard Harding wrote:

> Kapil has built a new version of python-jujuclient 0.50.1 which we've QA'd
> against the current deployer, quickstart, and gui charm. The QA has passed
> and we've copied the packages for python-jujuclient into the juju stable
> PPA. They've built and we're waiting on them to be published.
> 
> Once that's complete an apt-get upgrade should hopefully get you on the
> right track again.
> 
> https://launchpad.net/~juju/+archive/ubuntu/stable/+packages
> 
> Rick
> 
> On Sat, 28 Feb 2015, Marco Ceppi wrote:
> 
> > This is a regression in juju-core, which is being documented here:
> > https://bugs.launchpad.net/juju-core/+bug/1425435 The latest upstream of
> > jujuclient (the library juju-deployer uses) has patched this, I imagine
> > we'll see a new package in the archive for 0.19.1 of python-jujuclient soon.
> > 
> > Marco
> > 
> > On Fri, Feb 27, 2015 at 6:15 PM Kevin Sargent  wrote:
> > 
> > > Suddenly all my deploys stopped working with following error message:
> > >
> > > Traceback (most recent call last):
> > >   File "/usr/bin/juju-deployer", line 9, in 
> > > load_entry_point('juju-deployer==0.4.3', 'console_scripts',
> > > 'juju-deployer')()
> > >   File "/usr/lib/python2.7/dist-packages/deployer/cli.py", line 130, in
> > > main
> > > run()
> > >   File "/usr/lib/python2.7/dist-packages/deployer/cli.py", line 228, in 
> > > run
> > > importer.Importer(env, deployment, options).run()
> > >   File "/usr/lib/python2.7/dist-packages/deployer/action/importer.py",
> > > line 196, in run
> > > self.deploy_services()
> > >   File "/usr/lib/python2.7/dist-packages/deployer/action/importer.py",
> > > line 92, in deploy_services
> > > env_status = self.env.status()
> > >   File "/usr/lib/python2.7/dist-packages/deployer/env/go.py", line 203, in
> > > status
> > > return self.client.get_stat()
> > >   File "/usr/lib/python2.7/dist-packages/jujuclient.py", line 599, in
> > > get_stat
> > > return StatusTranslator().run(watch)
> > >   File "/usr/lib/python2.7/dist-packages/jujuclient.py", line 999, in run
> > > self._unit(d)
> > >   File "/usr/lib/python2.7/dist-packages/jujuclient.py", line 1031, in
> > > _unit
> > > for p in ports:
> > > TypeError: 'NoneType' object is not iterable
> > >
> > > --
> > > 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

Re: New Error With juju-deployer

[Richard Harding]

Kapil has built a new version of python-jujuclient 0.50.1 which we've QA'd
against the current deployer, quickstart, and gui charm. The QA has passed
and we've copied the packages for python-jujuclient into the juju stable
PPA. They've built and we're waiting on them to be published.

Once that's complete an apt-get upgrade should hopefully get you on the
right track again.

https://launchpad.net/~juju/+archive/ubuntu/stable/+packages

Rick

On Sat, 28 Feb 2015, Marco Ceppi wrote:

> This is a regression in juju-core, which is being documented here:
> https://bugs.launchpad.net/juju-core/+bug/1425435 The latest upstream of
> jujuclient (the library juju-deployer uses) has patched this, I imagine
> we'll see a new package in the archive for 0.19.1 of python-jujuclient soon.
> 
> Marco
> 
> On Fri, Feb 27, 2015 at 6:15 PM Kevin Sargent  wrote:
> 
> > Suddenly all my deploys stopped working with following error message:
> >
> > Traceback (most recent call last):
> >   File "/usr/bin/juju-deployer", line 9, in 
> > load_entry_point('juju-deployer==0.4.3', 'console_scripts',
> > 'juju-deployer')()
> >   File "/usr/lib/python2.7/dist-packages/deployer/cli.py", line 130, in
> > main
> > run()
> >   File "/usr/lib/python2.7/dist-packages/deployer/cli.py", line 228, in run
> > importer.Importer(env, deployment, options).run()
> >   File "/usr/lib/python2.7/dist-packages/deployer/action/importer.py",
> > line 196, in run
> > self.deploy_services()
> >   File "/usr/lib/python2.7/dist-packages/deployer/action/importer.py",
> > line 92, in deploy_services
> > env_status = self.env.status()
> >   File "/usr/lib/python2.7/dist-packages/deployer/env/go.py", line 203, in
> > status
> > return self.client.get_stat()
> >   File "/usr/lib/python2.7/dist-packages/jujuclient.py", line 599, in
> > get_stat
> > return StatusTranslator().run(watch)
> >   File "/usr/lib/python2.7/dist-packages/jujuclient.py", line 999, in run
> > self._unit(d)
> >   File "/usr/lib/python2.7/dist-packages/jujuclient.py", line 1031, in
> > _unit
> > for p in ports:
> > TypeError: 'NoneType' object is not iterable
> >
> > --
> > 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: Bug filed for Juju Quickstart Documentation

[Richard Harding]

On Mon, 09 Feb 2015, Charles Butler wrote:

> I've been working my way through documenting some of the newer workload
> enablement items coming out of my team, and in doing so I've run across
> Quickstart being under-represented in the docs.
>
>
> https://github.com/juju/docs/issues/261
>
>
> With quickstart being a pointed at defacto utility to rapidly deploy
> bundles and configure your cloud environment, this gap is a fairly large
> concern to me. What I propose is I can scaffold out some baseline user
> documentation - but it would be great to see a Juju User Interface team
> member step into maintaining this particular tool documentation once I've
> got a PR up for review.
>
> Also, if there are any existing blog posts I can consume you can point me
> to I'd certainly appreciate it.
>
> Cheers

Thanks Chuck, definitely something we should look to improve. We have
decent help in the app, but not great exernal docs.

The best place to look for blog posts (and one is a video walk through) is
searching on the team's blog:

https://jujugui.wordpress.com/?s=quickstart

We'll look to help pull together some better 'readable' docs. Thanks for
bringing this up.

--

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

Re: feedback about juju after using it for a few months

[Richard Harding]

On Wed, 17 Dec 2014, Caio Begotti wrote:

> Folks, I just wanted to share my experience with Juju during the last few
> months using it for real at work. I know it's pretty long but stay with me
> as I wanted to see if some of these points are bugs, design decisions or if
> we could simply to talk about them :-)

Thanks for the great feedback. I've got some replies and we'd love to help
improve the experience.


> Juju GUI:
>
> 11. Juju's GUI's bells and whistles are nice, but I think there's a bug
> with it because its statuses are inaccurate. If you set a relation, Juju
> says the relation is green and active immediately, which is not true if you
> keep tailing the log file and you know things can still fail because
> scripts are still running.

The relation is green, but if it errors after some time it should turn red
with error info. If the relation goes into an error state and it does not
then that's a bug we'd love to fix. If you could file the bug and let us
know if there's two services that this is easily replicated with that's be
awesome!

https://bugs.launchpad.net/juju-gui/+filebug

> 12. Cancelling actions on Juju's GUI does not make much sense since you
> need to click on commit, then click on clear, then confirm it. Why not
> simply having a different cancel button instead? It's like shutting down
> Windows from the start menu. The cancel button should cancel the action,
> and the actual X button should simply dismiss it. That clear button seems
> useless UX-wise?

Thanks, we'll take this feedback to the UX team. The deployment bar is a
new UX item and getting feedback on the use of it is greatly appreciated.

> 13. Juju's GUI's panel with charmstore stays open all the time wasting
> window space (so I have to zoom out virtually all my deployments because of
> the amount of wasted space, every time). There could be a way to hide that
> panel, because honestly it's useless locally since it never lists my local
> charms even if I export JUJU_REPOSITORY correctly. I'd rather have my local
> charms listed there too or just hide the panel instead.

You can hide the panel. If you type '?' a series of keyboard shortcuts come
up. One of them is to toggle the sidebar using 'ctrl-shift-h' (hide).
Please try that out and let us know if that helps or not. As we improve the
sidebar and make the added services bar more prevalent we hope the sidebar
being there is more and more useful.


> 13. Juju's GUI shows new relations info incorrectly. If I set up a DB
> relation to my service it simply says in the confirmation window that "db
> relation added between postgresql and postgresql". I've noticed sometimes
> this changes to "between myservice and myservice" so perhaps it has to do
> with the order of the relation, from what service to the other? Anyway,
> both cases seem to show it wrong?

Thanks, we'll look into this. Is there two services you can replicate this
every time or is it something that happens less consistently?

> 14. Juju's GUI always shows the service panel even if the service unit has
> been destroyed, just because I opened it once. Also, it says "1 dying
> units" (sic) forever until I close it manually.

By service panel is this the details panel that slides out from the left
sidebar? We can definitely look into making sure those go away when the
unit or service are destroyed.

> 15. Why subordinate charms don't have a color bar beneath their icons too?
> Because if it fails then it will appear in red right? Why not always
> display it to indicate it's been correctly deployed or set up?

There's a UX decision to try not to highlight subordinates unless there's an
issue because they tend to clutter the UI. With the new added services bar
and the ability to show/hide them perhaps it's something we should revisit.

> 16. Juju's GUI lists all my machines. Like, all of them, really. In the
> added services part of the panel it lists even inactive machines, which
> does not make much sense I'd say because it makes it seem only deployed
> machines are listed. I think that count is wrong.

The GUI lists the machines it knows about from Juju. I'm not sure about
hiding them because in machine view we use them for targets to deploy
things to. Now machines are only listed in machine view, but you mention
seeing them in the 'added services' panel? Do you have a screenshot of what
you mean we could take a look at?

> That's it, thank you for those who made it to the end :-D

And thank you for taking the time to write out the great feedback.

--

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

Re: juju-gui on utopic

[Richard Harding]

On Sat, 22 Nov 2014, Marco Ceppi wrote:

> oneiric, precise, quantal, raring, saucy, trusty, utopic, and vivid are all
> valid series for charms. We don't' freeze releases so once a release of
> Ubuntu exists a charm series will also exist.

Right, but that being said there is no series 'utopic' I could use to push
a non-official charm to help our Sameer.

https://launchpad.net/charms/+series

If the plan is to support that we need to open that up to provide a space
to publish to that series.

In the end though, as someone maintaining charms I'd prefer to stick with
LTS releases as official charms and allow users to use the local charm
deployment method for unsupported series. I'd be curious to hear what other
charm maintainers are thinking.

Rick


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

Re: juju-gui on utopic

[Richard Harding]

On Sat, 22 Nov 2014, Sameer Zeidat wrote:

>  Hello,
> How do I deploy juju-gui on Ubuntu 14.10 (stable or otherwise)? I get charm 
> not found cs:utopic/juju-gui.
> Setting 'juju-gui-source' to 'develop' didn't help.
>
> Thank you,Sameer

At the moment the only way to use the charm on utopic is to use it as a
local charm. I copied the trusty charm and deployed it on utopic on ec2
successfully and verified that it works. It's not currently part of our
supported charms. We've not really talked about it, but currently we supply
supported charms for precise and trusty.

Actually, I started to look at pushing up a non-official branch for your
use to utopic, but there's not currently a series for charms for utopic.

So I guess the bigger question is what are you up to? Are you running a
juju environment based on utopic? Are they all other local charms?


--

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

juju gui release 1.2.4 with new added services view

[Richard Harding]

The Juju UI Engineering team is proud to announce the latest release of the
Juju GUI, version 1.2.4. This release comes with a new feature, the added
services bar. In short, it's a view in the left sidebar that allows you to
highlight, show, and hide services in your canvas and machine view.

Jeff has written up a great blog post announcement here:
http://jujugui.wordpress.com/2014/11/18/juju-gui-1-3-0-released-now-with-added-services-view-2/

The release comes with a new charm version which now allows you to
configure the http port that the GUI runs on. This has been a highly
requested feature we're very happy to get out to everyone. We hope this is
useful in those small deployments so that you can have the GUI colocated
with other web based services.

I also want to mention we recently had a release of juju-quickstart,
version 1.5.0, which included several MAAS friendly updates and bug fixes.
http://jujugui.wordpress.com/2014/11/13/juju-quickstart-1-5-0/

If anyone has any questions or feedback make sure to let us know. Ask away
in #juju or #juju-gui and please file any bugs you might run across:
https://bugs.launchpad.net/juju-gui
https://bugs.launchpad.net/juju-quickstart

A huge thanks goes out to the team for their hard work on these new
releases!

--

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

Re: Where is the Juju-gui heading ?

[Richard Harding]

On Wed, 12 Nov 2014, Stein Myrseth wrote:

> In earlier versions of the Juju-gui it was easy and simple to deploy a
> charm, by just dragging and dropping it into the canvas and hit commit.
>
> With the latest versions the same process it is no more intuitive how to
> deploy anymore. I hit “confirm” and “commit” and nothing happens. I have
> create a machine first, or auto place, or add the constraints or as part
> of the unit configuration, or as part of the machine configuration to
> create a machine and assign the unit etc. And the approach is different
> if I do it from the CLI and UI.
>
>  To me this set the focus on two things. There will be two very distinct
>  different user groups using Juju with different requirements.
>
>
> 1) A charm designer/developers want to expose options for configuration
>
> 2) A charm consumer, want to add a “service” to his or her deployment and
> is interested in a “serious relationships” :-)
>
>  The first category has all the data, info and knows all requirements
>  needed for the charm regarding constraints etc.
>
>
> The constraints are a part of my frustrations here. Today constraints are
> detached from the charm, which to me does not make sense regarding the
> two different target user groups. It’s detached in the UI on creation,
> but can be assigned from the CLI, and also copied as a constraint on
> export.
>
>  As a charm developer I would very much like to see the support of adding
>  the constraints like RAM, cores etc. as part of the charm config itself.
>  This could be added to either the config.yaml or in a separate
>  constraints.yaml file as an option.
>
>
>  In this way as a charm developer I have an option to enforce the
>  constraints on deployment, either using the CLI or the UI. It could be
>  easy to check on deployment (as done when deploying bundles) if there is
>  available machine resource matching the constraints or if the user would
>  like a new machine matching the constraints to be created automatically.
>  The deployment part has become to complex, and involved to many steps
>  for the charm consumer. For the consumer the machines, assigned units,
>  where etc. are completely secondary. The consumer is looking for
>  storage, db proxy service relation without the need to learn how Mongodb
>  works. Thats’s my focus.
>
>
>  So as
>
>
> 1) As a charm developer I need a way to make the constraints of my charms
> consistent across the different way of deploying.
>
> 2) As a charm consumer I don’t care about machines, only services and the
> relationships provided and deploying should be simple.
>
>
> What is the future plans and directions for the the UI, define
> constraints and the easy of deployments ?


Thanks for the feedback Stein. As was mentioned your concern with charm
constraints is valid and something we've got on the list. We hit it all the
time as things like Jenkins (go go java) don't like to run on the default
small machines Juju uses out of the box. Having the charm author, who knows
more than anyone what you need to operate, defined that in the
charm level makes a lot of sense.

As to the ease of getting something deployed, I think there's a different
here. The GUI with machine view and the deployment bar is an attempt to
help realize that people are not just going out and deploying a single
thing. They're building a set of services that provide a complete solution
for some infrastructure need. To help with that, and make it easier to do
that work in total, we hold off on just 'hit deploy' so that the user can
freely build out everything they want, build relations, set config, and
really basically construct a custom bundle, before the tell Juju to go do
anything.

You don't mention the particular use case for the immediate deploy option.
We have the ability to do that and perhaps what we want is a bit of both
worlds.

https://demo.jujucharms.com/?deploy-target=precise/mysql

Is your use case primarily around using the GUi to manage your environment?
Is it usually a speedy demo situation? If we gave you the option in the
GUI config (you can get access to that via the ? key to set some config
options) so that immediate deployment was a default behaviour for the demo
would that help?

I'd love to hear some more details on how you're using the GUI and when the
extra deployment summary steps cause you pain and see if there's a good way
to address them.

Thanks again for the great feedback.


--

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

Re: Manipulating juju-gui upon running hooks of other charms

[Richard Harding]

On Mon, 03 Nov 2014, Malshan Peiris wrote:

> Hi all,
>
> I have juju-gui charm and other charm (A) deployed. Is it possible to do
> following while running hook scripts of charm A:
>
> 1. Make configurations read only for charm A on juju-gui.
>
> ex: We have a charm which should only allow configuration changes only once.

Not currently. We've wanted to do a read-only mode but wanted to wait for
Juju to gain the idea of users beyond admin so that some users have full
access and others have read-only access. With users work landing in Juju
1.21 (the next release) this is something we'll be looking to put into the
roadmap.

> 2. Pop up messages on juju-gui as called by hook scripts of charm A.
>
> ex: We have certain info messages to be shown to the user while making
> relationships on our charm using juju-gui.

Hmmm, so the GUI maintains a database of services, relations, machines, and
units (window.app.db). You'd have to add some JS to the page that watched
that database for changes. From there you can fire notifications like the
rest of the app using db.notifications.add().

Hope that helps. Feel free to let me know if you've got any other
questions.

--

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

Re: [Review Queue] hpcc charm

[Richard Harding]

I'm a +1 on some form of this. I've run into it with our CI and Jenkins.
Java loves it some RAM before services startup and operate. I wonder if
this kind of thing is discoverable in charm testing? At least to help us
gauge the subset of charms that might use something like this in order to
start and operate.

Rick

On Wed, 27 Aug 2014, Matt Bruzek wrote:

> I am tentatively +1 for adding some charm metadata for minimum requirements
> for the charm.  We could certainly add that kind of information in the
> README but having it in the metadata would make it automatic (magic).
>
> José makes a great point about how something like this could increase the
> cloud bill unexpectedly.  Perhaps some kind of informational message
> requiring a response from the user would be good here.  Users could accept
> or override the constraints.
>
> The number of charms that would take advantage of this metadata would be a
> small subset of what we have.  The big data charms, and other resource
> intensive charms could set this optional metadata to give the user a good
> experience.
>
> Are there any other concerns that people have about this metadata idea?
>
>- Matt Bruzek 
>
>
> On Wed, Aug 27, 2014 at 7:21 AM, José Antonio Rey  wrote:
>
> > It is a nice idea, but it should definitely fire up a warning saying
> > that the machine will have larger specs, as well as asking for
> > confirmation. I don't want to see any surprise charges in my AWS bills!
> >
> > On 08/27/2014 02:34 AM, Mark Shuttleworth wrote:
> > > On 27/08/14 00:10, Matt Bruzek wrote:
> > >>  First and most importantly the hpcc charm deploys according to the
> > readme
> > >> file! I had to increase the memory constraints on the HP-cloud to 4GB
> > per
> > >> machine (juju set-constraints mem=4GB) so all the services had enough
> > >> memory to start up. After that I was able to cluster by adding units of
> > >> hpcc.
> > >
> > > We have a couple of charms which break on tiny instances on some clouds
> > > because of this sort of disconnect. Would it be helpful to be able to
> > > encode minimum requirements in the charm metadata?
> > >
> > > Obviously, real requirements are configuration and load dependent, but I
> > > think we could avoid the obvious "try it then debug it" cycle if we had
> > > some explicit minimum requirements up front.
> > >
> > > Thanks for the review commentary and advice to charmers!
> > >
> > > Mark
> > >
> >
> > --
> > José Antonio Rey
> >

> --
> 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: We need a process to unpromulgate charms.

[Richard Harding]

On Fri, 22 Aug 2014, Curtis Hovey-Canonical wrote:

> We can delete branches, the charm store will still have its copy. If
> ~charmer's branch is identical to another user's branch (possibly to
> original author), then I favour deletion [1]

The charm store has a script to remove charms as well. We're building this
into an admin api in the current charm store work we've got going on.

I do think we need a good practice/policy for this. I'm always nervous of
moving/deleting charms because it could break someone's bundle down the
road. This really has me thinking that promulgate/unpromulgate need to
support some idea of redirecting. Maybe there's something here in the idea
of a 'that no longer exists, an alternate can be located at the following
personal branch' redirect.

We can make an alternate path part of the api for removing a charm, again
it's something that might cause unnoticed changes in a bundle deployment
though. At least we'd hope it would continue to function though.


--

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

Re: No icon = no promulgation?

[Richard Harding]

On Thu, 14 Aug 2014, José Antonio Rey wrote:

> On Aug 14, 2014 12:24 PM, "Richard Harding" 
> wrote:
> > I'd suggest to work with the author to use either the default charm icon
> or
> > a category icon and move the charm forward.
>
> As far as I know, the default category icon is applied when no icon is
> available.
>
> On the other hand, there are currently charms with no icon. How would we
> deal with those?

The category icon is used when the charm has no icon or is not promulgated,
and has a category set. This was to help users tell a bit more info from a
charm at a glace rather than all of them having the same default icon.

We own those icons and I think it'd be ok to use one on a promulgated charm
such as this situation if available. Though I don't think we have a
category/icon for a framework charm like CakePHP.

I'd just pull down the default icon and stick it in the charm to move it
forward for now.

https://manage.jujucharms.com/static/img/charm_160.svg


--

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

Re: No icon = no promulgation?

[Richard Harding]

On Wed, 13 Aug 2014, José Antonio Rey wrote:

> Hello,
>
> As I am subscribed to all bugs in Juju (as some of you may also be),
> today I got an email from a CakePHP charm review. On this one, a charmer
> had to reject the submission because, when promulgating, the tool runs
> `charm proof` to make sure things are not broken, not promulgating if
> any Error or Warning pops up. And there was a problem: this charm did
> not have an icon (which throws a Warning in `charm proof`, making it
> impossible to promulgate it.

Yes, charm checks are broken down into a couple of classes.

Warnings are things that allow a personal charm to be uploaded and served
to other users, but are required to be updated for promulgation.

Errors, are obvious things that we think are issues for charms regardless
of a personal branch or not. If a user uploads a charm with a proof error
it will never be ingested and put forth to users.

> I totally understand what has been done. Now, a charm cannot be
> promulgated when there are Errors or Warnings. But since not having an
> icon is a Warning, it will not allow a charmer to promulgate any charms
> which do not contain an icon, may it be because the author is asking for
> official permission (like in this case), because the service has no
> icon, or any other reasons. In some of the cases, it may be a
> fully-working charm, with no other issues apart from not having an icon.
> We even have lots of charms with no icon in the store. And about
> proposing a temporary icon, when I proposed an icon which was just an
> orange background with the service name, it got rejected. So, I don't
> know what may be an idea for a 'temporary' or 'provisional' icon.

We supply a starter file for an icon. The policy/proof is that the file is
there and is an svg image of the right sizes. I think that there are a
number of ways around this by helping the author use our default icon or
even one of our category icons that might fit in place in order to meet the
requirement for now.

> I believe having an icon is not that of a priority, and that we should
> focus in having charms that provide working services. Still, we should
> try to ensure and promote the idea of charms having icons, but I do not
> see it as a fatal error like to prevent promulgation.

Sorry, I hate to disagree here. We're building tools like the Juju GUI in
order to help users have a nice experience browsing charms. Every other
store, from Firefox/Chrome extensions to Apple/Android app stores require
an icon and sometimes even more to submit material. Promulgated material is
meant to go through curation to make sure we filter material to those that
provide the best experience and represent Juju. I think an icon is part of
that, not functionally I admit, but visually in the GUI environment and
browsing experience.

> In this case, I would be for demoting the level of the warning issued by
> `charm proof` from Warning to Information. This, as it is not something
> critical, and charms/services will still work, even with no icon. It
> doesn't affect functionality, but it only removes the pretty part (that
> can be added later) of the GUI. By doing this, we will throw something
> when `charm proof` is ran, but still allow promulgation if there is no icon.
>
> What do you guys think about it?

I'd suggest to work with the author to use either the default charm icon or
a category icon and move the charm forward. I also think it'd be good to
work with the author and perhaps provide some additional help in getting
permission for a real icon. In checking the license, it's a CC license, but
is no derivatives. Perhaps our community folks can help the author
demonstrate that permitting a derivative in the case of the charm is only
good for CakePHP users.

Please let me know if you disagree or want to setup a chat in person. I
understand the frustration of the icon, but I feel it's very important in
getting our best foot forward to users of Juju out there.

--

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

Re: Juju Digest, Vol 42, Issue 12

[Richard Harding]

Hello Nilaxan, the icons of charms that have been reviewed by the charmers
team are shown. We do not show the icons of other charms as a way to
protect against users that place inappropriate material in their icons.

Please let me know if you have any other questions and I look forward to
seeing your charm getting through the review queue.

--

Rick Harding

Juju UI Engineering
https://launchpad.net/~rharding
@mitechie


On Tue, 29 Jul 2014, Nilaxan Satgunanantham wrote:

> Hi Admin,
>
> Can anyone briefly explain this problem.
>
> "I have added a new icon for my charms in Juju charms store, the icon name
> is "icon.svg",
> and This change is updated in the '
> https://code.launchpad.net/~snilaxan/charms/precise/devspace-simulator/trunk
> '
> but, Not in the Juju charms store, it still remains the old icon "
>
>
> Thanks in advance
>
>
> On Fri, Jul 25, 2014 at 2:53 PM, Nilaxan Satgunanantham 
> wrote:
>
> > Hi Admin,
> >
> > Can anyone briefly explain "How to create a hook file to make the
> > relationship with two juju charms"
> >
> > Thanks in advance
> >
> >
> > Best Regards,
> > S.Nilaxan
> >
> >
> > On Wed, Jul 23, 2014 at 5:30 PM,  wrote:
> >
> >> Send Juju mailing list submissions to
> >> juju@lists.ubuntu.com
> >>
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >> https://lists.ubuntu.com/mailman/listinfo/juju
> >> or, via email, send a message with subject or body 'help' to
> >> juju-requ...@lists.ubuntu.com
> >>
> >> You can reach the person managing the list at
> >> juju-ow...@lists.ubuntu.com
> >>
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of Juju digest..."
> >>
> >>
> >> Today's Topics:
> >>
> >>1. Juju GUI (Adewole Ogunyadeka)
> >>2. Re: Juju GUI (Richard Harding)
> >>3. Juju bootstrap stuck on Openstack (Giuseppe Civitella)
> >>4. Re: Juju bootstrap stuck on Openstack (Hui Xiang)
> >>
> >>
> >> --
> >>
> >> Message: 1
> >> Date: Tue, 22 Jul 2014 17:02:52 +0100
> >> From: Adewole Ogunyadeka 
> >> To: juju@lists.ubuntu.com
> >> Subject: Juju GUI
> >> Message-ID:
> >>  >> 8b...@mail.gmail.com>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> I cant seem to get the juju-gui working even after exposing it.
> >>
> >> I type in the address on the browser (https://10.0.0.109) and it doesnt
> >> connect. It was installed on the same node that has the MAAS
> >>
> >>
> >> *Kind regards*
> >> *Conrad , *
> >> *Research student*
> >> -- next part --
> >> An HTML attachment was scrubbed...
> >> URL: <
> >> https://lists.ubuntu.com/archives/juju/attachments/20140722/db2000cb/attachment-0001.html
> >> >
> >>
> >> --
> >>
> >> Message: 2
> >> Date: Tue, 22 Jul 2014 15:16:48 -0400
> >> From: Richard Harding 
> >> To: Adewole Ogunyadeka 
> >> Cc: juju@lists.ubuntu.com
> >> Subject: Re: Juju GUI
> >> Message-ID: <20140722191648.GH2161@xraken>
> >> Content-Type: text/plain; charset=us-ascii
> >>
> >> On Tue, 22 Jul 2014, Adewole Ogunyadeka wrote:
> >>
> >> > I cant seem to get the juju-gui working even after exposing it.
> >> >
> >> > I type in the address on the browser (https://10.0.0.109) and it doesnt
> >> > connect. It was installed on the same node that has the MAAS
> >>
> >> Hello Adewole, sorry you're having issues. When you say it doesn't
> >> connect,
> >> do you get the normal GUI loading screen as it attempts to connect to the
> >> Juju environment? Or do you mean you don't get any html from the deployed
> >> Juju GUI at all? You mentioned that you installed it on the same node that
> >> has MAAS, is this the maas controller? If so, I wonder if you're having
> >> conflicting applications attempting to serve out content on port 80 and
> >> 443. The GUI isn't constructed to work alongside another application that
> >> is also on those ports.
> >>
> >> Please let me know some more information

Re: Juju GUI

[Richard Harding]

On Tue, 22 Jul 2014, Adewole Ogunyadeka wrote:

> I cant seem to get the juju-gui working even after exposing it.
>
> I type in the address on the browser (https://10.0.0.109) and it doesnt
> connect. It was installed on the same node that has the MAAS

Hello Adewole, sorry you're having issues. When you say it doesn't connect,
do you get the normal GUI loading screen as it attempts to connect to the
Juju environment? Or do you mean you don't get any html from the deployed
Juju GUI at all? You mentioned that you installed it on the same node that
has MAAS, is this the maas controller? If so, I wonder if you're having
conflicting applications attempting to serve out content on port 80 and
443. The GUI isn't constructed to work alongside another application that
is also on those ports.

Please let me know some more information and hopefully we can help get you
up and running quickly.


--

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

Re: Cloadbase

[Richard Harding]

Maarten, my understanding is that the work shown off is more of a proof of
concept. There's future work required to make it something that can be used
by others. There are not any windows charms in the store and will not be
for a bit.

Rick

On Mon, 26 May 2014, Maarten Ectors wrote:

> Are the windows charms already available?
>
> Thanks,
> Maarten
> On 25 May 2014 16:23, "Stein Myrseth"  wrote:
>
> > I saw the Cloadbase demo of their Windows charms. Are they available
> > somewhere in any charmstore etc ? Can't find them doing a regular search in
> > the charmstore ?
> >
> > Stein
> > _
> > *Stein Myrseth :  ForgeRock AS*
> > e: stein.myrs...@forgerock.com 
> > a: Lysaker torg 2, N-1366 Lysaker, NORWAY
> > t: +47 90962763, f: +47 21520010
> > w: www.forgerock.com
> >
> > [image: irmsummit.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

Re: About GUI juju control panel

[Richard Harding]

On Wed, 26 Mar 2014, Anant wrote:

> Hello Everyone,
>
> I am new to Juju stuff. I am just trying a juju charm in my local
> environment. and I found that if any charm is providing web management
> interface. then Password field should be mandatory.
>
> Like I have set
>
> user-admin
> password-admin
>
> and log in to management console. But now i have go to GUI control panel
> again and remove the password and save it. It successfully saved. But
> when i tried to login with-out password, it is not allowing me to login,
> and still i can log in with old password, that means GUI Panel has not
> changed the password when it is blank. But my concern is it should
> prompt to user that password can't be blank or it will not allow to save
> the configuration when password is blank.

Hello Anant, thanks for the email. You're correct that the GUI does not
currently validate the config fields. The definitions are often a bit
vague, but we've been looking into things we can do to support this better.
There's an open bug [1] you can monitor as well.

If I'm following your email, there's also the issue that the charm in
question allows you to set the password via a charm config setting, and it
also provides a webui setting from itself. Those are not kept in sync. This
is an interesting problem that we might be able to look at helping charm
authors work to sync this data. Do you recall which charm you were using?


1: https://bugs.launchpad.net/juju-gui/+bug/1178472


--

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

Re: juju-deployer releases & dropping pyjuju support.

[Richard Harding]

On Sat, 22 Feb 2014, Kapil Thangavelu wrote:

> Hi Folks,
>
> There have been a few juju-deployer releases over the last month.
>
>  0.3.1 https://launchpad.net/juju-deployer/trunk/0.3.1
>  0.3.2 https://launchpad.net/juju-deployer/trunk/0.3.2
>  0.3.3 https://launchpad.net/juju-deployer/+milestone/0.3.3
>
> Many thanks to half-dozen contributors to the last few releases (of special
> note JuanJo Ciarlante)
>
> As always the latest releases are @
> https://pypi.python.org/pypi/juju-deployer
>
> Looking to the future, deployer's ability to work with both pyjuju and
> juju-core implementations has become a burden to new feature development
> and its something i plan on dropping in the next juju-deployer release
> (0.4.0). Given that pyjuju is effectively unsupported and deprecated, I
> hope this doesn't come as a surprise to anyone, but if you do still need
> pyjuju support, please speak up.

Just to toss some support for this. I know we're also looking at removing
pyjuju support to to help reduce maintenance and we're all for the same in
the deployer. Thanks for the heads up Kapil.

--

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

Re: Juju Plugins

[Richard Harding]

I think we could easily reference external plugins with a readme type doc
instead of a script to start out with. That way there's visibility, but
they reference their own home for larger pluigins. We'd do this for
quickstart for example.

On Fri, 14 Feb 2014, Kapil Thangavelu wrote:

> I think it really depends on how big the plugins are.. most of the ones in
> that repo are of the single page variety. i've got several plugins which
> are a bit on the larger side (half-dozen to a dozen files) and benefit from
> their own repo (bug tracking, etc). Ideally we could just have a page in
> the docs that people could submit pull requests for as new plugins emerge.
> re centralized plugin management, seems a bit down the road, juju plugins
> can be written in any language, while sublime tended to gravitate towards
> python for plugins.
> 
> -k
> 
> 
> 
> On Fri, Feb 14, 2014 at 7:31 AM, Joshua Strobl wrote:
> 
> > Have multiple repositories for the plugins is just unnecessary
> > fragmentation (at least at this point). If someone wants to maintain
> > their own plugins, they can easily fork the project, add their plugin
> > (setting their fork as master and the juju/plugins as upstream) and
> > simply do a pull request to get it merged the plugin merged.
> >
> > In terms of having an index to "register" plugins, you could argue that
> > the GitHub repo is for that, given the person "registers" the plugin by
> > a pull request and having it be accepted upstream (juju/plugins).
> >
> > I can agree that we should have some sort of webpage (at
> > jujuplugins.com) that lists the plugins (as well as their description,
> > required and optional commands or arguments, etc), but that isn't needed
> > at this point and we should only cross that bridge when we really need
> > to. (It should be noted that the page can still leverage GitHub via
> > their APIs, so we won't have to manually add plugins to the site.)
> >
> > > Sublime Text and Homebrew (if I remember right) does that.
> >
> > I think you are referring to https://sublime.wbond.net/, which is an
> > unofficial repository of Sublime Text plugins, and while I totally
> > understand your point about having the multi-repo in the case of Sublime
> > Text plugins (and it absolutely makes sense in that environment), it
> > should be noted that it isn't possible to accomplish having all of a
> > Sublime Text plugin within a single file (from my not-so-immense
> > understanding of SL plugin dev), unlike Juju Plugins where it is simply
> > something written in a single bash script, so for Sublime Text plugins
> > it is more of a necessity, unless you want to do something like
> > DefinitelyTyped - https://github.com/borisyankov/DefinitelyTyped - where
> > they divide each definition, in our case plugin, into a separate folder.
> >
> > But yea, I agree 100% about utilizing jujuplugins.com EVENTUALLY, where
> > we do disagree on is how we should keep Juju Plugins organized and
> > reduce fragmentation (while trying to ensure the plugins remain
> > up-to-date) as much as possible.
> >
> > - Joshua Strobl
> >
> > On 02/14/2014 01:06 AM, Sebastian wrote:
> > > This sounds great!, I was wondering how to extend Juju.
> > >
> > > When I think about plugins, using Github as a repository seems the right
> > > thing, and not just one repository to all. Sublime Text and Homebrew(if I
> > > remember right) does that. But definitively we need an index for register
> > > them, and not actually for storing the plugin.
> > >
> > >
> > > Abs,
> > > Sebas.
> > >
> > >
> > >
> > > 2014-02-13 20:58 GMT-02:00 Marco Ceppi :
> > >
> > >> So, when I first started plugins, I was like "WE SHOULD HAVE A WEBSITE,
> > >> AND IT SHOULD HAVE PLUGINS, AND AWESOME", but then I realized that we
> > don't
> > >> have that many plugins. In the future, if plugins become a popular
> > thing we
> > >> can invest some time in making jujuplugins.com and have a plugin
> > >> installer, etc. For now just collecting them all in one place is a good
> > >> start.
> > >>
> > >> Thanks,
> > >> Marco Ceppi
> > >>
> > >>
> > >> On Thu, Feb 13, 2014 at 5:50 PM, Joshua Strobl  > >wrote:
> > >>
> > >>> Would it be feasible and/or benefitial to have some sort of rating
> > >>> system for the plugins, with those that get the most support being
> > >>> merged into juju-core (assuming there wouldn't be some upcoming
> > >>> functionality that would make the plugin no-longer-useful)? I see that
> > >>> as a great way to improve Juju's core functionality gradually without
> > >>> having to worry about tackling a possible issue later where plugin X
> > >>> that could've been merged is now out-of-date.
> > >>>
> > >>> On 02/13/2014 11:37 PM, Jorge O. Castro wrote:
> >  If you didn't know, Juju has support for plugins. So far these have
> >  been scattered over junk branches and pastebins so we're going to
> >  organize them so people have one place to find them:
> > 
> >  https://github.com/juju/plugins
> > 
>

Re: jenkins version in jenkins charm

[Richard Harding]

I've filed a bug related to the expectation on the charm: #1267873.

On Fri, 10 Jan 2014, Steve Powell wrote:

> Yup, because it doesn’t do the fetch part.
>
> On 10 Jan 2014, at 14:17, Mark Shuttleworth  wrote:
>
> > fetching, installing and *using* that version. Definitely
> > sounds like the charm is missing that logic.
>

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

Re: jenkins version in jenkins charm

[Richard Harding]

On Fri, 10 Jan 2014, Steve Powell wrote:

> Is there a way of fixing the charm settings before deploying for the
> first time, so that I can set the release (source) (and plugins, btw)
> before the service is initialised?

Definitely. `juju deploy` takes an option for a config file. I use that in
my Jenkins install to set the source and the admin password on install.

I created a file 'jenkins_conf.yaml'

  jenkins:
password: test
release: trunk


and then deploy with:

  juju deploy --config jenkins_conf.yaml precise/jenkins

This brings up the service with the config specified.

--

Rick Harding

Cloud 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

Re: jenkins version in jenkins charm

[Richard Harding]

On Fri, 10 Jan 2014, Steve Powell wrote:

> I have deployed the jenkins charm (and slaves) successfully, but cannot
> get the right version of jenkins installed that permits me to install the
> right plugins.
>
> Here are my settings:
>
> ...
> and I have tried release distro, trunk and lts, and they all remaining
> stuck on the same release.  The plugins (git maven-plugin
> parameterized-trigger) are all accepted (and the hook completes
> successfully) but only the last one is actually installed (apparently)
> because the others are too up-level to work with the (old) release of
> jenkins.
>
> I can download a jenkins.war of a later release, but how do I tell the
> charm to use it?
>
> Is it time for me to ‘get down and dirty’ with the charm implementation?
>
> Steve Powell

Steve, I believe that changing the release changes the source updates are
fetched from during the normal apt-get install/upgrade process. It does not
actually perform the upgrade itself. I also run a Jenkins install from the
charm and have it running with the release set to 'trunk'. Even with this
set, all it does is add the apt repository from Jenkins to the server.
Updates need to be managed. A tool like Landscape [1] can be used to manage
the updates on the system. You should be able to ssh to the machine and
perform an apt-get update && apt-get upgrade to get the Jenkins package to
update.

If you do want to get dirty with the charm implementation the work that
handles the release updates is part of the install hook in the charm [2].
You can find the source for it here [3] and see that it's just doing an
apt-get install. Not an upgrade.


1: http://www.ubuntu.com/management/landscape-features
2. https://jujucharms.com/precise/jenkins/
3. 
http://bazaar.launchpad.net/~charmers/charms/precise/jenkins/trunk/view/head:/hooks/install#L15

--

Rick Harding

Cloud 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

Re: Nagios charm

[Richard Harding]

On Mon, 18 Nov 2013, Richard Harding wrote:

> On Tue, 19 Nov 2013, David Cheney wrote:
> 
> > > That just sounds like a presentation issue to me. It might be useful to 
> > > have
> > > some concept of layers in the GUI, allowing you to, for example, hide the
> > > monitoring layer.
> >
> > I'm not quite sure what the issue is here. The NRPE subordinate does
> > not show it's relationship lines by default, for this reason.
> 
> This has come to the Gui team's attention previously and the great UX folks
> have thought on the problem. It's work we're trying to schedule and yes,
> it'll involve the idea of being able to hide, in some fashion,
> subordinates.

And Matt's going to kill me when he realizes I didn't notice we were hiding
the subordinate links like this already. Doh!

-- 

Rick Harding

Cloud 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

Re: Nagios charm

[Richard Harding]

On Tue, 19 Nov 2013, David Cheney wrote:

> > That just sounds like a presentation issue to me. It might be useful to have
> > some concept of layers in the GUI, allowing you to, for example, hide the
> > monitoring layer.
>
> I'm not quite sure what the issue is here. The NRPE subordinate does
> not show it's relationship lines by default, for this reason.

This has come to the Gui team's attention previously and the great UX folks
have thought on the problem. It's work we're trying to schedule and yes,
it'll involve the idea of being able to hide, in some fashion,
subordinates.


--

Rick Harding

Cloud 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

Re: Charm Quality Ratings updates

[Richard Harding]

Yes, we can do this. We currently support doing markdown rendering of a
charm's readme in JS. Jorge, how are we looking to have users document
their interfaces? As a description attribute in the yaml? Could that be
easy to write out as markdown?

On Mon, 30 Sep 2013, Mark Shuttleworth wrote:

>
> Are there good markdown renderers in JS? Should we aim for interface
> documentation in MD?
>
> On 30/09/13 12:32, Richard Harding wrote:
> > On Wed, 25 Sep 2013, Luca Paulina wrote:
> >
> >> On Wed, Sep 25, 2013 at 3:06 PM, Jorge O. Castro  wrote:
> >>
> >>> Hi everyone,
> >>>
> >>> I'd like to revise the charm quality stuff a bit, mostly the ~charmers
> >>> have captured that we would like to encourage folks to document the
> >>> interfaces in their charms and I'd like to add that as a charm quality
> >>> bullet item.
> >>>
> >>> In the past that just meant getting a +1 from some charmers and
> >>> editing the docs, but now that we have a GUI I want to make sure we
> >>> don't add things to the guidelines and not sync up with the GUI and
> >>> design teams, so what would be the best way for me to drive that
> >>> forward?
> >> Thanks for the email Jorge, maybe we can find sometime to discuss it
> >> tomorrow over a hangout. There is a need to revise the copy of the intro
> >> paragraph as well, we should discuss that at the same time.
> >>
> >> Thanks,
> >>
> >> Luca
> > Did this happen? To answer the first, question, a bit on charmworld to add
> > the new QA item with the text and section to place it in will allow us to
> > add it to the QA process. The Gui will then pick it up and adjust scores
> > accordingly.
> >
> > --
> >
> > Rick Harding
> >
> > Cloud Engineering
> > https://launchpad.net/~rharding
> > @mitechie
> >
>

--

Rick Harding

Cloud 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

Re: Charm Quality Ratings updates

[Richard Harding]

On Wed, 25 Sep 2013, Luca Paulina wrote:

> On Wed, Sep 25, 2013 at 3:06 PM, Jorge O. Castro  wrote:
>
> > Hi everyone,
> >
> > I'd like to revise the charm quality stuff a bit, mostly the ~charmers
> > have captured that we would like to encourage folks to document the
> > interfaces in their charms and I'd like to add that as a charm quality
> > bullet item.
> >
> > In the past that just meant getting a +1 from some charmers and
> > editing the docs, but now that we have a GUI I want to make sure we
> > don't add things to the guidelines and not sync up with the GUI and
> > design teams, so what would be the best way for me to drive that
> > forward?

> Thanks for the email Jorge, maybe we can find sometime to discuss it
> tomorrow over a hangout. There is a need to revise the copy of the intro
> paragraph as well, we should discuss that at the same time.
>
> Thanks,
>
> Luca

Did this happen? To answer the first, question, a but on charmworld to add
the new QA item with the text and section to place it in will allow us to
add it to the QA process. The Gui will then pick it up and adjust scores
accordingly.

--

Rick Harding

Cloud 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

Re: jujucharms.com not loading

[Richard Harding]

On Thu, 19 Sep 2013, Gustavo Niemeyer wrote:

> And it just happened again while navigating there. :-(
> 
> On Thu, Sep 19, 2013 at 11:31 AM, Gustavo Niemeyer  
> wrote:
> > Morning,
> >
> > First time I tried to load http://jujucharms.com today it got stuck in
> > "Connecting to the environment...":
> >
> > http://pbrd.co/17M5Fgy
> >
> > Not sure if that's a side effect of the changes being done for the new 
> > release?
> >
> >
> > gustavo @ http://niemeyer.net

Can you please check the console in the dev tools of your browser for any
error messages or hints we can chase down? Feel free to ping me in irc if a
hangout would help debug why you're seeing this. I'm currently unable to
duplicate.

-- 

Rick Harding

Cloud 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

Re: RackSpace support

[Richard Harding]

On Wed, 28 Aug 2013, Patrick Hetu wrote:

> In RackSpace's Ubuntu images cloud-init is not installed by default
> so you have to create a custom image and bootrap with it.
> For that you need to create public container (cdn) with the metadata.
> 
> I discovered that the userdata field doesn't exist in the API but there
> is a field named "personality" that is doing more or less the same thing.
> 
> So I've put the user-data in the personnality field but now
> I'm getting a 413 error (Request Entity Too Large).

Just a heads up that I've brought this up to Jesse Noller, their community
guy, and he's brought it up internally to work on.

See: https://twitter.com/jessenoller/status/372340805639225345

I'd been looking at testing things out on rackspace a little bit ago and
ran into this as well.

-- 

Rick Harding

Cloud 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