Re: Proposal: Make setting bug-url and homepage metadata policy

We were thinking of blocking the "recommended" procedure to an entity without those values set. So, you want to have a recommended charm, make sure URLs are set and valid. I don't think we need to make it mandatory for all charms, as it introduces a barrier maybe not everyone wants to cover at

Re: Proposal: Make setting bug-url and homepage metadata policy

On Wed, Sep 14, 2016 at 10:05 AM, Uros Jovanovic < uros.jovano...@canonical.com> wrote: > I don't think we need to make it mandatory for all charms, as it > introduces a barrier maybe not everyone wants to cover at the beginning of > their charming path ... Agreed, people's namespaces are their

Feedback wanted: Changes to the Ubuntu Charm

Hey everyone, Normally, I wouldn't bother with an update like this, but it's slightly larger than I'd care to just push out. Today, the Ubuntu charm is a no-op, which is largely the goal of the charm. However, as juju becomes more rich this no-op charm starts to look incomplete. I know a few

Proposal: Make setting bug-url and homepage metadata policy

Good morning, I'd like to propose a policy change as a for incoming new charms. The homepage and bugs-url fields are used to point users to where they can file bugs, and where they can find the source code to the charm. The store uses these fields to generate the page for each charm on

Re: Feedback wanted: Changes to the Ubuntu Charm

Is there a merge proposal or pull request for the changes? I'd like to validate with 1.25.6 as the current stable release, but --channel isn't a thing there. I tried to `charm pull ubuntu --channel candidate` but received: ERROR cannot get archive: unauthorized: access denied. Thanks, Ryan

Re: LXD instances fail to start

In one case yesterday, with a full openstack-on-lxd deployed and in use, I quickly hit the too-many-open-files issue. I raised fs.inotify.max_user_instances on the host to 50 which unblocked me for a while. I ended up raising both to 99 and have had smooth sailing since. Currently, the

Re: Feedback wanted: Changes to the Ubuntu Charm

Hi Ryan, I have granted everyone access to the candidate channel. Could you try again? Thanks, Marco Ceppi On Wed, Sep 14, 2016 at 3:26 PM Ryan Beisner wrote: > Is there a merge proposal or pull request for the changes? I'd like to > validate with 1.25.6 as the

Re: Feedback wanted: Changes to the Ubuntu Charm

Marco, This is awesome. I use the ubuntu charm all the time for testing, and seeing the workload version and workload status being set is pretty cool. I had hoped that seeing the "unknown" status would apply gentle pressure to get people to set a workload status. Winning!!! Tim On

Upcoming Azure auth changes

Hi folks, Just a heads up, where will be some changes to authentication in the Azure provider. When https://github.com/juju/juju/pull/6247 lands (if you're working off master), or otherwise when rc1 is out, you will need to remove "tenant-id" from your credentials.yaml. There is more work

LXD instances fail to start

For those who have been following the lxd issue that we've been digressing on at the charmer summit, see https://bugs.launchpad.net/juju-core/+bug/1602192 7/22-now no activity It looks like the bug already has eyes on it, but has been idle for a while now. It would be nice to get this thing

Re: JUJU Charm Certification

Hi Chris , Thank you very much. I got a very good information. Sorry. I didn't understand one thing Clearly. For the Question, At a time, can I deploy two storages arrays to same cinder node? Can we add two storage arrays to cinder node using the single charm? description =

Getting Error while installing juju-local for juju 1.25 : juju-local : Depends: lxc (>= 1.0.0~alpha1-0ubuntu14) but it is not going to be installed....

Hi All, I am trying to install juju 1.25 and getting error while performing the below step: sudo apt-get install juju-local [sudo] password for charm: no talloc stackframe at ../source3/param/loadparm.c:4864, leaking memory Reading package lists... Done Building dependency tree Reading state

Re: Upcoming Azure auth changes

On Thu, Sep 15, 2016 at 9:15 AM Andrew Wilkins wrote: > Hi folks, > > Just a heads up, where will be some changes to authentication in the Azure > provider. When https://github.com/juju/juju/pull/6247 lands (if you're > working off master), or otherwise when rc1 is

Re: JUJU Charm Certification

> On Sep 13, 2016, at 23:02, SivaRamaPrasad Ravipati wrote: > > Hi Chris , > > Thank you very much. I got a very good information. > > Sorry. I didn't understand one thing Clearly. > > For the Question, > > At a time, can I deploy two storages arrays to same cinder

Re: LXD instances fail to start

In one case yesterday, with a full openstack-on-lxd deployed and in use, I quickly hit the too-many-open-files issue. I raised fs.inotify.max_user_instances on the host to 50 which unblocked me for a while. I ended up raising both to 99 and have had smooth sailing since. Currently, the

Reviews on Github

In case you missed it, Github rolled out a new review process. It basically works just like reviewboard does, where you start a review, batch up comments, then post the review as a whole, so you don't just write a bunch of disconnected comments (and get one email per review, not per comment).

Re: Reviews on Github

/me is always +1 on reducing the number of things we have to maintain and keeping things simpler. On Wed, Sep 14, 2016 at 4:04 PM Nate Finch wrote: > In case you missed it, Github rolled out a new review process. It > basically works just like reviewboard does, where

Re: Reviews on Github

Also +1 for that source not being review board On Wed, Sep 14, 2016 at 5:23 PM, Reed O'Brien wrote: > Also +1 for a single source of truth. > > On Wed, Sep 14, 2016 at 1:20 PM, Rick Harding > wrote: > >> /me is always +1 on reducing the

Re: Reviews on Github

As long as we can have draft reviews like on RB and not email-spam-per-comment, totally +1 On 09/14/2016 01:25 PM, Horacio Duran wrote: > Also +1 for that source not being review board > > On Wed, Sep 14, 2016 at 5:23 PM, Reed O'Brien

Re: Reviews on Github

I'm halfway through my first Github review (different project though) on the new system, and so far I'm loving it. Also consider the issues we've had with rbt being unable to handle diffs with files added/removed/relocated. +1 from me! -Casey On Wed, Sep 14, 2016 at 3:23 PM, Reed O'Brien

Re: Reviews on Github

I'm +1 if we can remove the extra tools and we don't get email per comment. On 15/09/16 08:03, Nate Finch wrote: In case you missed it, Github rolled out a new review process. It basically works just like reviewboard does, where you start a review, batch up comments, then post the review as a

Upcoming Azure auth changes

Hi folks, Just a heads up, where will be some changes to authentication in the Azure provider. When https://github.com/juju/juju/pull/6247 lands (if you're working off master), or otherwise when rc1 is out, you will need to remove "tenant-id" from your credentials.yaml. There is more work

Re: Reviews on Github

One thing review board does better is use gutter indicators so as not to interrupt the flow of reading the code with huge comment blocks. It also seems much better at allowing previous commits with comments to be viewed in their entirety. And it allows the reviewer to differentiate between issues

LXD instances fail to start

For those who have been following the lxd issue that we've been digressing on at the charmer summit, see https://bugs.launchpad.net/juju-core/+bug/1602192 7/22-now no activity It looks like the bug already has eyes on it, but has been idle for a while now. It would be nice to get this thing

Re: Upcoming Azure auth changes

On Thu, Sep 15, 2016 at 9:15 AM Andrew Wilkins wrote: > Hi folks, > > Just a heads up, where will be some changes to authentication in the Azure > provider. When https://github.com/juju/juju/pull/6247 lands (if you're > working off master), or otherwise when rc1 is

Re: Reviews on Github

I think that the issue is that someone has to maintain the RB and the cost/time spent on that does not seem commensurate with the bonus features in my experience. On Wed, Sep 14, 2016 at 6:13 PM Ian Booth wrote: > One thing review board does better is use gutter

Re: Reviews on Github

On Thu, Sep 15, 2016 at 6:22 AM Rick Harding wrote: > I think that the issue is that someone has to maintain the RB and the > cost/time spent on that does not seem commensurate with the bonus features > in my experience. > Agreed and +1. I propose we all try it for a

Re: Reviews on Github

+1 on moving away from RB \o/ Currently contributors need to allow RB to run against their github fork, if they don't then we do not see their contributions on RB and PRs go un-reviewed and seem ignored. Communication between github and RB is not optimal: we had plenty of instances where RB