Re: LXD on Manual incorrect resolv.conf

[Tom Barber]

Ah right, apologies, the IP address is provided by the LXD default bridge.


On 26 June 2018 at 22:31:12, Tim Penhey (tim.pen...@canonical.com) wrote:

I guess I should have been more clear with respect to the IP addresses.

Clearly the container isn't being set up correctly if it can't reach out
and we should look into that.

When a container is started there are several options for how it gets an
IP address. The various default behaviours are different for different
providers.
* there is the LXD default, which is to get an IP address from the
bridge subnet, and this container should be able to reach out, but
ingress to the container is limited to other things on the bridge.
* getting an IP address from a DHCP server
* using the fan


Tim

On 27/06/18 09:03, Tom Barber wrote:
> I don’t have any expectation other than connectivity to the internet
> would be nice because otherwise it makes juju quite hard :)
>
> But irrespective of my expectations, if standalone LXD containers get a
> resolv.conf that allows connection to the WWW, why doesn’t Juju, it
> seems both reasonable and logical? I guess thats my expectation,
> considering the containers need to apt-get etc.
>
> Juju is 2.3.7
>
> Tom
>
>
> On 26 June 2018 at 21:57:21, Tim Penhey (tim.pen...@canonical.com
> <mailto:tim.pen...@canonical.com>) wrote:
>
>> Hi Tom,
>>
>> What is your expectation on how the containers are getting their IP
>> addresses?
>>
>> Also, which version of Juju?
>>
>> Tim
>>
>> On 27/06/18 08:29, Tom Barber wrote:
>> > Hi folks,
>> >
>> > I’m trying to do a manual cloud with LXD containers within it.
>> >
>> > When I manually launch and LXD container I get
>> >
>> > nameserver 10.61.251.1
>> > search lxd
>> >
>> > If juju launches a container it gets:
>> >
>> > nameserver 127.0.0.1
>> > search ovh.net <http://ovh.net> <http://ovh.net> lxd
>> >
>> > Which doesn’t connect to the interwebs and makes Juju sad. What can I
do
>> > to fix this?
>> >
>> >
>> > Spicule Limited is registered in England & Wales. Company Number:
>> > 09954122. Registered office: First Floor, Telecom House, 125-135
Preston
>> > Road, Brighton, England, BN1 6AF. VAT No. 251478891.
>> >
>> >
>> > All engagements are subject to Spicule Terms and Conditions of
Business.
>> > This email and its contents are intended solely for the individual to
>> > whom it is addressed and may contain information that is confidential,
>> > privileged or otherwise protected from disclosure, distributing or
>> > copying. Any views or opinions presented in this email are solely
those
>> > of the author and do not necessarily represent those of Spicule
Limited.
>> > The company accepts no liability for any damage caused by any virus
>> > transmitted by this email. If you have received this message in error,
>> > please notify us immediately by reply email before deleting it from
your
>> > system. Service of legal notice cannot be effected on Spicule Limited
by
>> > email.
>> >
>> >
>> >
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com <mailto:Juju@lists.ubuntu.com>
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>
> Spicule Limited is registered in England & Wales. Company Number:
> 09954122. Registered office: First Floor, Telecom House, 125-135 Preston
> Road, Brighton, England, BN1 6AF. VAT No. 251478891.
>
>
> All engagements are subject to Spicule Terms and Conditions of Business.
> This email and its contents are intended solely for the individual to
> whom it is addressed and may contain information that is confidential,
> privileged or otherwise protected from disclosure, distributing or
> copying. Any views or opinions presented in this email are solely those
> of the author and do not necessarily represent those of Spicule Limited.
> The company accepts no liability for any damage caused by any virus
> transmitted by this email. If you have received this message in error,
> please notify us immediately by reply email before deleting it from your
> system. Service of legal notice cannot be effected on Spicule Limited by
> email.
>

-- 


Spicule Limited is registered in England & Wales. Company Number: 
09954122. Registered office: First Floor, Telecom House, 125-135 Preston 
Road, Brighton, England, BN1 6AF. VAT No. 251478891.




All engagements 
are subject to Spicule Terms and Conditions of Business. This email and its 
contents are intended solely for the individual 

Re: LXD on Manual incorrect resolv.conf

[Tom Barber]

I don’t have any expectation other than connectivity to the internet would
be nice because otherwise it makes juju quite hard :)

But irrespective of my expectations, if standalone LXD containers get a
resolv.conf that allows connection to the WWW, why doesn’t Juju, it seems
both reasonable and logical? I guess thats my expectation, considering the
containers need to apt-get etc.

Juju is 2.3.7

Tom


On 26 June 2018 at 21:57:21, Tim Penhey (tim.pen...@canonical.com) wrote:

Hi Tom,

What is your expectation on how the containers are getting their IP
addresses?

Also, which version of Juju?

Tim

On 27/06/18 08:29, Tom Barber wrote:
> Hi folks,
>
> I’m trying to do a manual cloud with LXD containers within it.
>
> When I manually launch and LXD container I get
>
> nameserver 10.61.251.1
> search lxd
>
> If juju launches a container it gets:
>
> nameserver 127.0.0.1
> search ovh.net <http://ovh.net> lxd
>
> Which doesn’t connect to the interwebs and makes Juju sad. What can I do
> to fix this?
>
>
> Spicule Limited is registered in England & Wales. Company Number:
> 09954122. Registered office: First Floor, Telecom House, 125-135 Preston
> Road, Brighton, England, BN1 6AF. VAT No. 251478891.
>
>
> All engagements are subject to Spicule Terms and Conditions of Business.
> This email and its contents are intended solely for the individual to
> whom it is addressed and may contain information that is confidential,
> privileged or otherwise protected from disclosure, distributing or
> copying. Any views or opinions presented in this email are solely those
> of the author and do not necessarily represent those of Spicule Limited.
> The company accepts no liability for any damage caused by any virus
> transmitted by this email. If you have received this message in error,
> please notify us immediately by reply email before deleting it from your
> system. Service of legal notice cannot be effected on Spicule Limited by
> email.
>
>
>

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

-- 


Spicule Limited is registered in England & Wales. Company Number: 
09954122. Registered office: First Floor, Telecom House, 125-135 Preston 
Road, Brighton, England, BN1 6AF. VAT No. 251478891.




All engagements 
are subject to Spicule Terms and Conditions of Business. This email and its 
contents are intended solely for the individual to whom it is addressed and 
may contain information that is confidential, privileged or otherwise 
protected from disclosure, distributing or copying. Any views or opinions 
presented in this email are solely those of the author and do not 
necessarily represent those of Spicule Limited. The company accepts no 
liability for any damage caused by any virus transmitted by this email. If 
you have received this message in error, please notify us immediately by 
reply email before deleting it from your system. Service of legal notice 
cannot be effected on Spicule Limited by email.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

LXD on Manual incorrect resolv.conf

[Tom Barber]

Hi folks,

I’m trying to do a manual cloud with LXD containers within it.

When I manually launch and LXD container I get

nameserver 10.61.251.1
search lxd

If juju launches a container it gets:

nameserver 127.0.0.1
search ovh.net lxd

Which doesn’t connect to the interwebs and makes Juju sad. What can I do to
fix this?

-- 


Spicule Limited is registered in England & Wales. Company Number: 
09954122. Registered office: First Floor, Telecom House, 125-135 Preston 
Road, Brighton, England, BN1 6AF. VAT No. 251478891.




All engagements 
are subject to Spicule Terms and Conditions of Business. This email and its 
contents are intended solely for the individual to whom it is addressed and 
may contain information that is confidential, privileged or otherwise 
protected from disclosure, distributing or copying. Any views or opinions 
presented in this email are solely those of the author and do not 
necessarily represent those of Spicule Limited. The company accepts no 
liability for any damage caused by any virus transmitted by this email. If 
you have received this message in error, please notify us immediately by 
reply email before deleting it from your system. Service of legal notice 
cannot be effected on Spicule Limited by email.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Major Roadblocks - real life use cases

[Tom Barber]

I have a couple of new bits and pieces coming to the data charms soonish so
if no one beats me to it we can take a look at Hadoop storage also.


Tom


On 29 May 2018 at 16:50:22, James Beedy (jamesbe...@gmail.com) wrote:

Drew,

Thanks for the response.

I've been dabbling in these areas.

Looks like I may just need to use a combination of a few different methods
here.

~James



On Tue, May 29, 2018 at 8:45 AM, Drew Freiberger <
drew.freiber...@canonical.com> wrote:

> On Mon, May 28, 2018 at 10:23:21PM -0700, James Beedy wrote:
>
>> I want to shed some light on a few blockers for me right now.
>>
>> 2) Maas needs better support for 3rd party drivers.
>>  * Getting my Mellanox drivers hooked up at commissioning so maas
>> recognizes the 40Gb interfaces is taking me a few weeks now. Supporting
>> user defined 3rd party driver should be a primary supported capability of
>> MAAS.
>>  * how are people doing Hadoop,and Ceph and Openstack without this,
>> possibly someone knows something I don’t know here?
>>
>
> Hello James,
>
> I believe that MAAS 2.x's nodes-scripts (Hardware Testing and
> Commissioning scripts) might be helpful for any custom code or
> drivers you might want to inject in the commissioning process.
>
> Here is a link to the guide for these scripts.  I might suggest
> the cript example for "Configure HPA" might provide a good template for
> how you might want to inject a Mellanox driver/config into your build.
>
> https://docs.maas.io/2.3/en/nodes-scripts
>
> The MAAS server has a web server serving out a docroot from
> /var/www/htdocs where you can drop any files you might want to curl/wget
> from your scripts.  I believe there are environment variables for the
> preseeds for the IP of the MAAS server for your URL.
>
> You might also notice that you can have the script automatically install
> packages from any of apt, snap, or URL.  You can even tag the script to
> automatically run on hardware with a specific PCI ID. with the
> for_hardware metadata field.
>
> Documentation on managing these scripts via the CLI is here:
>
> https://docs.maas.io/2.3/en/nodes-scripts-cli
>
> In MAAS 1 environments, one would have to update the curtin preseeds
> manually in /etc/maas/preseeds to inject scripts of this type.
>
> I do not know if the commissioning scripts also happen at deployment
> time (doubtful), but hopefully the install of your chosen OS will
> include the drivers needed, or you've found that you can add an Ubuntu
> package repository or PPA that contains your packages to be installed
> per https://docs.maas.io/2.3/en/manage-repos.
>
> I hope this information helps.
>
> Sincerely,
> -Drew
>
> Any feedback would be greatly appreciated.
>>
>> Thanks
>>
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju

-- 


Spicule Limited is registered in England & Wales. Company Number: 
09954122. Registered office: First Floor, Telecom House, 125-135 Preston 
Road, Brighton, England, BN1 6AF. VAT No. 251478891.




All engagements 
are subject to Spicule Terms and Conditions of Business. This email and its 
contents are intended solely for the individual to whom it is addressed and 
may contain information that is confidential, privileged or otherwise 
protected from disclosure, distributing or copying. Any views or opinions 
presented in this email are solely those of the author and do not 
necessarily represent those of Spicule Limited. The company accepts no 
liability for any damage caused by any virus transmitted by this email. If 
you have received this message in error, please notify us immediately by 
reply email before deleting it from your system. Service of legal notice 
cannot be effected on Spicule Limited by email.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

SSH to machines from add-user

[Tom Barber]

Hello folks

IRC has failed me so lets try the wider world.

We have a multinode manual cloud deployed. We have juju add-user 2 new 
users and also juju add-ssh-key for those users.


We know the ssh key works because

ssh ubuntu@

works fine and we can sudo -i etc and do stuff.

But

juju ssh 

says:

ERROR permission denied (unauthorized access)
11:05:18 DEBUG cmd supercommand.go:459 error stack:
permission denied (unauthorized access)
github.com/juju/juju/rpc/client.go:149:
github.com/juju/juju/api/apiclient.go:924:
github.com/juju/juju/api/sshclient/facade.go:109:
github.com/juju/juju/cmd/juju/commands/ssh_common.go:257:
github.com/juju/juju/cmd/juju/commands/ssh_common.go:141:
github.com/juju/juju/cmd/juju/commands/ssh.go:117:

I've looked at the code and it claims we can

juju ssh ubuntu@ -i 

that fails with the same error.

If I tail the target servers auth.log there isn't even a failed login 
attempt which strikes me as a little weird considering it says


permission denied (unauthorized access)

Which does make me question... what permission is denied?


--


Spicule Limited is registered in England & Wales. Company Number: 
09954122. Registered office: First Floor, Telecom House, 125-135 Preston 
Road, Brighton, England, BN1 6AF. VAT No. 251478891.





All engagements 
are subject to Spicule Terms and Conditions of Business. This email and its 
contents are intended solely for the individual to whom it is addressed and 
may contain information that is confidential, privileged or otherwise 
protected from disclosure, distributing or copying. Any views or opinions 
presented in this email are solely those of the author and do not 
necessarily represent those of Spicule Limited. The company accepts no 
liability for any damage caused by any virus transmitted by this email. If 
you have received this message in error, please notify us immediately by 
reply email before deleting it from your system. Service of legal notice 
cannot be effected on Spicule Limited by email.


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

Re: Juju Charm Store and CI

[Tom Barber]

Yeah I'd be interested in having a chat with folks about this.

On 01/03/18 07:29, Sandor Zeestraten wrote:
On Wed, Feb 28, 2018 at 8:51 AM, Mark Shuttleworth > wrote:


On 02/27/2018 10:44 PM, Sandor Zeestraten wrote:

I feel like I'm hitting some rough spots while setting up a
simple pipeline which pushes a charm build to the edge channel
using the charm store CLI.
The last Juju Show (#30) talked about macaroon support in libjuju
and CI which sounds great, but that seems to be aimed at those
using libjuju and/or JAAS controllers.


The charm store should definitely use macaroons, and should have a
language to be able to setup limited-use macaroons ('token to push
for this charm', 'token to release to edge channel for this charm'
etc).

Can I suggest a hangout between folks interested in this, and the
charm store folks, to work out whats needed?

Mark


Hey Mark, happy to join a hangout if needed. I'm mainly CET, but can 
do NA time zones with some planning.


Thanks
--
Sandor Zeestraten





--


Spicule Limited is registered in England & Wales. Company Number: 09954122. 
Registered office: First Floor, Telecom House, 125-135 Preston Road, 
Brighton, England, BN1 6AF. VAT No. 251478891.



All engagements are subject to Spicule Terms and Conditions of Business. 
This email and its contents are intended solely for the individual to whom 
it is addressed and may contain information that is confidential, 
privileged or otherwise protected from disclosure, distributing or copying. 
Any views or opinions presented in this email are solely those of the 
author and do not necessarily represent those of Spicule Limited. The 
company accepts no liability for any damage caused by any virus transmitted 
by this email. If you have received this message in error, please notify us 
immediately by reply email before deleting it from your system. Service of 
legal notice cannot be effected on Spicule Limited by email.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju Charm Store and CI

[Tom Barber]

I have a proper hack for a circleci build chain I wrote, but works 
pretty well:


https://github.com/spiculedata/circleci-juju

On 27/02/18 21:44, Sandor Zeestraten wrote:

Hey Juju folks,

I feel like I'm hitting some rough spots while setting up a simple 
pipeline which pushes a charm build to the edge channel using the 
charm store CLI.
The last Juju Show (#30) talked about macaroon support in libjuju and 
CI which sounds great, but that seems to be aimed at those using 
libjuju and/or JAAS controllers.


Here are some of the steps for a new project:
* Create a launchpad team for a namespace in the charm store
  - Fair enough
* Create a launchpad CI user/bot and add it project so we can push to 
the store without using personal credentials
  - This feels like a hack and rather insecure. Why not use limited 
deploy/API keys? https://github.com/juju/charmstore/issues/776 

* Manually login to launchpad with the CI user in order to activate it 
in the charm store
    - This gotcha took me a few moments to figure out. 
https://jujucharms.com/docs/stable/authors-charm-store#the-juju-charm-store 

* Manually login to the charm store with the CI user with `charm 
login` to create a token.
  - Had to find this 
bug,https://github.com/juju/charmstore-client/issues/61 
, after I figured 
out that `charm login` did not have a non-interactive way to authenticate
  - This is still not document anywhere as far as I can tell. 
https://github.com/juju/charmstore-client/issues/145 


  - According to the comments in #61 it needs to be updated periodically
  - I've seen another approach using expect, 
https://lists.ubuntu.com/archives/juju/2017-November/009691.html 
, 
but that seems like a workaround too
* Encrypt and deploy token to a specific directory in CI in order for 
`charm login` to work
  - Again, https://github.com/juju/charmstore-client/issues/61 
 and 
https://github.com/juju/charmstore-client/issues/145 

* Mess around with `charm push` and `charm release` in order to push 
charm to the edge channel

  - This involves dealing with revisions which feels rather unnecessary
  - Seehttps://github.com/juju/charmstore-client/issues/135 
and 
https://github.com/juju/charmstore-client/issues/146 


* Celebrate with your favourite beverage

How are you all interacting with the charm store with your charm CI?
Am I missing some obvious steps which would simplify things?
Is anyone working on proper deploy/API keys for the charm store?

Cheers
--
Sandor Zeestraten





--


Spicule Limited is registered in England & Wales. Company Number: 09954122. 
Registered office: First Floor, Telecom House, 125-135 Preston Road, 
Brighton, England, BN1 6AF. VAT No. 251478891.



All engagements are subject to Spicule Terms and Conditions of Business. 
This email and its contents are intended solely for the individual to whom 
it is addressed and may contain information that is confidential, 
privileged or otherwise protected from disclosure, distributing or copying. 
Any views or opinions presented in this email are solely those of the 
author and do not necessarily represent those of Spicule Limited. The 
company accepts no liability for any damage caused by any virus transmitted 
by this email. If you have received this message in error, please notify us 
immediately by reply email before deleting it from your system. Service of 
legal notice cannot be effected on Spicule Limited by email.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Saiku Analytics with JAAS

[Tom Barber]

Morning all

We've been working on getting our latest Saiku Enterprise charm ready to 
go and fancied sharing what we're working on with the wider community. 
Apologies for the rather silent video..


https://youtu.be/6TJv2IA4nHg

Whats great about deploying Saiku with Juju and leveraging the relations 
is the ability for us to configure data sources without user 
interaction, couple that with the schema designer to interrogate data 
sources and create a working schema on the fly and I'm absolutely loving 
the whole solution. Thanks to you folks for building a great platform, 
and I'm excited about getting this out to the end users and adding more 
features!


Cheers

Tom


--


Spicule Limited is registered in England & Wales. Company Number: 09954122. 
Registered office: First Floor, Telecom House, 125-135 Preston Road, 
Brighton, England, BN1 6AF. VAT No. 251478891.



All engagements are subject to Spicule Terms and Conditions of Business. 
This email and its contents are intended solely for the individual to whom 
it is addressed and may contain information that is confidential, 
privileged or otherwise protected from disclosure, distributing or copying. 
Any views or opinions presented in this email are solely those of the 
author and do not necessarily represent those of Spicule Limited. The 
company accepts no liability for any damage caused by any virus transmitted 
by this email. If you have received this message in error, please notify us 
immediately by reply email before deleting it from your system. Service of 
legal notice cannot be effected on Spicule Limited by email.


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

Re: Charm Developer program

[Tom Barber]

Hi Nadeem

I had one of my guys sign up about 6 months ago  and pinged a bunch of 
people,  never got anywhere. It'd make more sense to remove the page to 
be honest!


Tom

On 17/12/17 10:20, Nadeem Idrees wrote:

Hi,
I have filled the form  to be a part 
of charm developer program about 2 weeks ago but I haven't received 
any response yet. I have re-submitted the form today again. Is there 
anything else that I would need to share/complete after the form 
submission?


Thanks,
Nadeem





--


Spicule Limited is registered in England & Wales. Company Number: 09954122. 
Registered office: First Floor, Telecom House, 125-135 Preston Road, 
Brighton, England, BN1 6AF. VAT No. 251478891.



All engagements are subject to Spicule Terms and Conditions of Business. 
This email and its contents are intended solely for the individual to whom 
it is addressed and may contain information that is confidential, 
privileged or otherwise protected from disclosure, distributing or copying. 
Any views or opinions presented in this email are solely those of the 
author and do not necessarily represent those of Spicule Limited. The 
company accepts no liability for any damage caused by any virus transmitted 
by this email. If you have received this message in error, please notify us 
immediately by reply email before deleting it from your system. Service of 
legal notice cannot be effected on Spicule Limited by email.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Problem with editing file on container

[Tom Barber]

You should be able run

export TERM=xterm

or similar and then open the editor.

Tom

On 09/12/17 18:59, Naas Si Ahmed wrote:

Hi,

I'm trying to modify a file using the command vi or nano to edit a 
file on a juju container, but I'm receiving an error such : terminal 
unknown.


Is there any way that I can use to edit a file graphically from 
another juju container ?


The juju command I used is :
Juju run "vi /etc/conf.rules" --machine =8

Thank you,
Ahmed.





--


Spicule Limited is registered in England & Wales. Company Number: 09954122. 
Registered office: First Floor, Telecom House, 125-135 Preston Road, 
Brighton, England, BN1 6AF. VAT No. 251478891.



All engagements are subject to Spicule Terms and Conditions of Business. 
This email and its contents are intended solely for the individual to whom 
it is addressed and may contain information that is confidential, 
privileged or otherwise protected from disclosure, distributing or copying. 
Any views or opinions presented in this email are solely those of the 
author and do not necessarily represent those of Spicule Limited. The 
company accepts no liability for any damage caused by any virus transmitted 
by this email. If you have received this message in error, please notify us 
immediately by reply email before deleting it from your system. Service of 
legal notice cannot be effected on Spicule Limited by email.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Deploying a charm with t's & c's

[Tom Barber]

Thanks chaps,

I'll try elsewhere.

Tom

On 04/12/17 18:17, Rick Harding wrote:
Thanks for this Tom, for some reason the controller in the region 
there isn't running 2.2.6, we're looking into it and will try to get 
it updated as soon as possible.


On Mon, Dec 4, 2017 at 9:22 AM Tom Barber <t...@spicule.co.uk 
<mailto:t...@spicule.co.uk>> wrote:


mymodel jaas    aws/us-east-1  2.2.2    unsupported


Tom


On 04/12/17 14:08, Matthew Williams wrote:

Hi Tom,

What version of the controller are you using (show in juju
status). Is this your own controller or are you using jimm?

Thanks

Matty

On Mon, Dec 4, 2017 at 10:33 AM, Tom Barber <t...@spicule.co.uk
<mailto:t...@spicule.co.uk>> wrote:

Hi Casey

https://asciinema.org/a/qXUZqY5WhCYFUA44l9OILeZWB As you'll
see here. #45 works for me also but #47 fails. I don't think
we changed anything massively but clearly something in there
is sad, the problem is that, the error thrown gives me no
indication of where we've messed up.

On a side note I wanted to grab the zip archive of #45 and
#47 and do a diff to see if it was obvious but both give me a
404 from the charm store.

juju list-agreements
Term     Agreed on
isrg-lets-encrypt/2      2017-04-26 09:43:38 + UTC
canonical/sla-terms/3        2017-08-31 21:19:16 + UTC
spiculecharms/pdi-terms/1    2017-11-27 23:24:11 + UTC

Tom


On 04/12/17 02:54, Casey Marshall wrote:

Tom,
With 2.2.6, I cannot reproduce any problems with deploying
your charm. See https://paste.ubuntu.com/26109617/

Please send me more information about your installation:

- How you installed Juju (snap, deb from PPA, compiled from
source, etc.)
- Platform information on the machine you're running the
Juju client on, OS, etc. Is it on a physical host, in a VM,
in a container?
- What cloud you're trying to deploy into

If you type `juju list-agreements`, does that show terms
you've agreed to?

-Casey

On Sat, Dec 2, 2017 at 4:55 PM, Tom Barber
<t...@spicule.co.uk <mailto:t...@spicule.co.uk>> wrote:

Just as a quick update, I get the same if I deploy the
charm directly and from the charm store ie not in a bundle.

But removing the terms in the metadata.yaml removes the
error.

Tom


On 28/11/17 18:36, Stephen Downie wrote:

Thanks for looking into this Casey. The version of Juju
I'm running is 2.2.6-xenial-amd64


Spicule Ltd

Tel: 01603 327762



www.spicule.co.uk <http://www.spicule.co.uk>


On Tue, Nov 28, 2017 at 6:30 PM, Casey Marshall
<casey.marsh...@canonical.com
<mailto:casey.marsh...@canonical.com>> wrote:

    On Tue, Nov 28, 2017 at 12:09 PM, Tom Barber
<t...@spicule.co.uk <mailto:t...@spicule.co.uk>> wrote:

hey Casey

if you have no models and try and deploy a
bundle with terms it shows you the deploy
screen them hangs. if you go back you see the
model with 0 units deployed.

this is a local bundle we were testing, just
exported from the gui, Ste can provide it if
you need it.


Thanks for clarifying. One last question, what
version of Juju was used on the command line when
trying to deploy the exported bundle?


Tom


On 28 Nov 2017 6:00 pm, "Casey Marshall"
<casey.marsh...@canonical.com
<mailto:casey.marsh...@canonical.com>> wrote:

On Tue, Nov 28, 2017 at 10:50 AM, Stephen
Downie <step...@spicule.co.uk
<mailto:step...@spicule.co.uk>> wrote:

Thanks. I have tried running juju agree
spiculecharms/pdi-terms/1 and it states
terms already agreed?

When trying to deploy in the GUI it
returns the error message cannot create
bundle: already exists. It appears that
it creates the model but does't
actually deploy anything? I know I'm a
bit new to this but something seems a
bit broken.


Is it possible that the model name in the
GUI (the

Re: Debug logs

[Tom Barber]

Thanks Corey,

Its pretty unfriendly in terms of usability, I currently have to find 
this thread every time I want to debug something. Maybe I'll stick it as 
a bash alias or something.


I do remember the discussion about the noise, it does make sense, but 
being able to change the levels more intuitively I think would help.


Tom


On 04/12/17 14:36, Cory Johns wrote:
It seems that the default logging level for models was reduced some 
time back.  This makes the logs much less noisy and saves quite a bit 
of space, but it has the unfortunate side effect of making debugging 
charm failures from logs more difficult, as most failure messages only 
show up as stderr output.  It would probably be worth adding explicit 
logging of uncaught exceptions to the reactive framework so that they 
are clearly visible in the logs.


I've opened this as an issue against reactive here: 
https://github.com/juju-solutions/charms.reactive/issues/147


On Sun, Nov 26, 2017 at 2:47 PM, Tim Penhey <tim.pen...@canonical.com 
<mailto:tim.pen...@canonical.com>> wrote:


What is the logging level for the model?

The output from the hooks are logged at debug level.

Tim

On 26/11/17 13:25, Tom Barber wrote:
> Maybe its just me, I dunno.
>
> Has the amount of detail in debug-logs decreased?
>
> I'm  not seeing failure causes for example:
>
> 2017-11-26 00:11:18 INFO juju.worker.uniter resolver.go:104
found queued
> "install" hook
> 2017-11-26 00:12:26 ERROR juju.worker.uniter.operation
runhook.go:107
> hook "install" failed: exit status 1
> 2017-11-26 00:12:26 INFO juju.worker.uniter resolver.go:100 awaiting
> error resolution for "install" hook
> 2017-11-26 00:12:31 INFO juju.worker.uniter resolver.go:100 awaiting
> error resolution for "install" hook
> 2017-11-26 00:12:32 ERROR juju.worker.uniter.operation
runhook.go:107
> hook "install" failed: exit status 1
> 2017-11-26 00:12:32 INFO juju.worker.uniter resolver.go:100 awaiting
> error resolution for "install" hook
> 2017-11-26 00:12:42 INFO juju.worker.uniter resolver.go:100 awaiting
> error resolution for "install" hook
> 2017-11-26 00:12:43 ERROR juju.worker.uniter.operation
runhook.go:107
> hook "install" failed: exit status 1
> 2017-11-26 00:12:43 INFO juju.worker.uniter resolver.go:100 awaiting
> error resolution for "install" hook
> 2017-11-26 00:13:03 INFO juju.worker.uniter resolver.go:100 awaiting
> error resolution for "install" hook
> 2017-11-26 00:13:05 ERROR juju.worker.uniter.operation
runhook.go:107
> hook "install" failed: exit status 1
> 2017-11-26 00:13:05 INFO juju.worker.uniter resolver.go:100 awaiting
> error resolution for "install" hook
> 2017-11-26 00:13:43 INFO juju.worker.uniter resolver.go:100 awaiting
> error resolution for "install" hook
> 2017-11-26 00:13:44 ERROR juju.worker.uniter.operation
runhook.go:107
> hook "install" failed: exit status 1
> 2017-11-26 00:13:44 INFO juju.worker.uniter resolver.go:100 awaiting
> error resolution for "install" hook
> 2017-11-26 00:15:01 INFO juju.worker.uniter resolver.go:100 awaiting
> error resolution for "install" hook
> 2017-11-26 00:15:02 ERROR juju.worker.uniter.operation
runhook.go:107
> hook "install" failed: exit status 1
> 2017-11-26 00:15:02 INFO juju.worker.uniter resolver.go:100 awaiting
> error resolution for "install" hook
> 2017-11-26 00:17:39 INFO juju.worker.uniter resolver.go:100 awaiting
> error resolution for "install" hook
> 2017-11-26 00:17:40 ERROR juju.worker.uniter.operation
runhook.go:107
> hook "install" failed: exit status 1
> 2017-11-26 00:17:40 INFO juju.worker.uniter resolver.go:100 awaiting
> error resolution for "install" hook
> 2017-11-26 00:21:42 INFO juju.worker.uniter resolver.go:100 awaiting
> error resolution for "install" hook
> 2017-11-26 00:22:40 INFO juju.worker.uniter resolver.go:100 awaiting
> error resolution for "install" hook
> 2017-11-26 00:22:41 ERROR juju.worker.uniter.operation
runhook.go:107
> hook "install" failed: exit status 1
>
>
>
>
> Spicule Limited is registered in England & Wales. Company Number:
> 09954122. Registered office: First Floor, Telecom House, 125-135
Preston
> Road, Brighton, England, BN1 6AF. VAT No. 251478891.
>
>
> All engagements are subject to Spicule Terms and Conditions of
Busines

Re: Deploying a charm with t's & c's

[Tom Barber]

mymodel  jaas    aws/us-east-1 2.2.2    unsupported

Tom

On 04/12/17 14:08, Matthew Williams wrote:

Hi Tom,

What version of the controller are you using (show in juju status). Is 
this your own controller or are you using jimm?


Thanks

Matty

On Mon, Dec 4, 2017 at 10:33 AM, Tom Barber <t...@spicule.co.uk 
<mailto:t...@spicule.co.uk>> wrote:


Hi Casey

https://asciinema.org/a/qXUZqY5WhCYFUA44l9OILeZWB
<https://asciinema.org/a/qXUZqY5WhCYFUA44l9OILeZWB> As you'll see
here. #45 works for me also but #47 fails. I don't think we
changed anything massively but clearly something in there is sad,
the problem is that, the error thrown gives me no indication of
where we've messed up.

On a side note I wanted to grab the zip archive of #45 and #47 and
do a diff to see if it was obvious but both give me a 404 from the
charm store.

juju list-agreements
Term         Agreed on
isrg-lets-encrypt/2      2017-04-26 09:43:38 + UTC
canonical/sla-terms/3        2017-08-31 21:19:16 + UTC
spiculecharms/pdi-terms/1    2017-11-27 23:24:11 + UTC

Tom


On 04/12/17 02:54, Casey Marshall wrote:

Tom,
With 2.2.6, I cannot reproduce any problems with deploying your
charm. See https://paste.ubuntu.com/26109617/
<https://paste.ubuntu.com/26109617/>

Please send me more information about your installation:

- How you installed Juju (snap, deb from PPA, compiled from
source, etc.)
- Platform information on the machine you're running the Juju
client on, OS, etc. Is it on a physical host, in a VM, in a
container?
- What cloud you're trying to deploy into

If you type `juju list-agreements`, does that show terms you've
agreed to?

-Casey

On Sat, Dec 2, 2017 at 4:55 PM, Tom Barber <t...@spicule.co.uk
<mailto:t...@spicule.co.uk>> wrote:

Just as a quick update, I get the same if I deploy the charm
directly and from the charm store ie not in a bundle.

But removing the terms in the metadata.yaml removes the error.

Tom


On 28/11/17 18:36, Stephen Downie wrote:

Thanks for looking into this Casey. The version of Juju I'm
running is 2.2.6-xenial-amd64


Spicule Ltd

Tel: 01603 327762



www.spicule.co.uk <http://www.spicule.co.uk>


On Tue, Nov 28, 2017 at 6:30 PM, Casey Marshall
<casey.marsh...@canonical.com
<mailto:casey.marsh...@canonical.com>> wrote:

    On Tue, Nov 28, 2017 at 12:09 PM, Tom Barber
<t...@spicule.co.uk <mailto:t...@spicule.co.uk>> wrote:

hey Casey

if you have no models and try and deploy a bundle
with terms it shows you the deploy screen them
hangs. if you go back you see the model with 0 units
deployed.

this is a local bundle we were testing, just
exported from the gui, Ste can provide it if you
need it.


Thanks for clarifying. One last question, what version
of Juju was used on the command line when trying to
deploy the exported bundle?


Tom


On 28 Nov 2017 6:00 pm, "Casey Marshall"
<casey.marsh...@canonical.com
<mailto:casey.marsh...@canonical.com>> wrote:

On Tue, Nov 28, 2017 at 10:50 AM, Stephen Downie
<step...@spicule.co.uk
<mailto:step...@spicule.co.uk>> wrote:

Thanks. I have tried running juju agree
spiculecharms/pdi-terms/1 and it states
terms already agreed?

When trying to deploy in the GUI it returns
the error message cannot create bundle:
already exists. It appears that it creates
the model but does't actually deploy
anything? I know I'm a bit new to this but
something seems a bit broken.


Is it possible that the model name in the GUI
(the drop down in the upper-left of the canvas)
matched an already-created model name? You might
need to type in a new model name there.

Or does this happen for new models with this
bundle no matter what?

Was this in the GUI in JAAS (jujucharms.com
<http://jujucharms.com>)? Did you try deploying
a bundle from the charmstore, or did you try
importing a bundle.yaml file?


Thanks all for your help.

   

Re: Deploying a charm with t's & c's

[Tom Barber]

Hi Casey

https://asciinema.org/a/qXUZqY5WhCYFUA44l9OILeZWB As you'll see here. 
#45 works for me also but #47 fails. I don't think we changed anything 
massively but clearly something in there is sad, the problem is that, 
the error thrown gives me no indication of where we've messed up.


On a side note I wanted to grab the zip archive of #45 and #47 and do a 
diff to see if it was obvious but both give me a 404 from the charm store.


juju list-agreements
Term         Agreed on
isrg-lets-encrypt/2      2017-04-26 09:43:38 + UTC
canonical/sla-terms/3        2017-08-31 21:19:16 + UTC
spiculecharms/pdi-terms/1    2017-11-27 23:24:11 + UTC

Tom

On 04/12/17 02:54, Casey Marshall wrote:

Tom,
With 2.2.6, I cannot reproduce any problems with deploying your charm. 
See https://paste.ubuntu.com/26109617/


Please send me more information about your installation:

- How you installed Juju (snap, deb from PPA, compiled from source, etc.)
- Platform information on the machine you're running the Juju client 
on, OS, etc. Is it on a physical host, in a VM, in a container?

- What cloud you're trying to deploy into

If you type `juju list-agreements`, does that show terms you've agreed to?

-Casey

On Sat, Dec 2, 2017 at 4:55 PM, Tom Barber <t...@spicule.co.uk 
<mailto:t...@spicule.co.uk>> wrote:


Just as a quick update, I get the same if I deploy the charm
directly and from the charm store ie not in a bundle.

But removing the terms in the metadata.yaml removes the error.

Tom


On 28/11/17 18:36, Stephen Downie wrote:

Thanks for looking into this Casey. The version of Juju I'm
running is 2.2.6-xenial-amd64


Spicule Ltd

Tel: 01603 327762



www.spicule.co.uk <http://www.spicule.co.uk>


On Tue, Nov 28, 2017 at 6:30 PM, Casey Marshall
<casey.marsh...@canonical.com
<mailto:casey.marsh...@canonical.com>> wrote:

On Tue, Nov 28, 2017 at 12:09 PM, Tom Barber
<t...@spicule.co.uk <mailto:t...@spicule.co.uk>> wrote:

hey Casey

if you have no models and try and deploy a bundle with
terms it shows you the deploy screen them hangs. if you
go back you see the model with 0 units deployed.

this is a local bundle we were testing, just exported
from the gui, Ste can provide it if you need it.


Thanks for clarifying. One last question, what version of
Juju was used on the command line when trying to deploy the
exported bundle?


Tom


On 28 Nov 2017 6:00 pm, "Casey Marshall"
<casey.marsh...@canonical.com
<mailto:casey.marsh...@canonical.com>> wrote:

On Tue, Nov 28, 2017 at 10:50 AM, Stephen Downie
<step...@spicule.co.uk
<mailto:step...@spicule.co.uk>> wrote:

Thanks. I have tried running juju agree
spiculecharms/pdi-terms/1 and it states terms
already agreed?

When trying to deploy in the GUI it returns the
error message cannot create bundle: already
exists. It appears that it creates the model but
does't actually deploy anything? I know I'm a bit
new to this but something seems a bit broken.


Is it possible that the model name in the GUI (the
drop down in the upper-left of the canvas) matched an
already-created model name? You might need to type in
a new model name there.

Or does this happen for new models with this bundle
no matter what?

Was this in the GUI in JAAS (jujucharms.com
<http://jujucharms.com>)? Did you try deploying a
bundle from the charmstore, or did you try importing
a bundle.yaml file?


Thanks all for your help.

Spicule Ltd

Tel: 01603 327762



www.spicule.co.uk <http://www.spicule.co.uk>


On Tue, Nov 28, 2017 at 12:33 PM, Tom Barber
<t...@spicule.co.uk <mailto:t...@spicule.co.uk>> wrote:

stupid question, but I assume the bundles
should handle t's better?

On 28 Nov 2017 12:29, "Ales Stimec"
<ales.sti...@canonical.com
<mailto:ales.sti...@canonical.com>> wrote:

Hi,

Could you please try
   juju agree spiculecharms/pdi-terms/1

This is these are the terms that require
agreement in ord

Re: Deploying a charm with t's & c's

[Tom Barber]

Just as a quick update, I get the same if I deploy the charm directly 
and from the charm store ie not in a bundle.


But removing the terms in the metadata.yaml removes the error.

Tom

On 28/11/17 18:36, Stephen Downie wrote:
Thanks for looking into this Casey. The version of Juju I'm running is 
2.2.6-xenial-amd64



Spicule Ltd

Tel: 01603 327762



www.spicule.co.uk <http://www.spicule.co.uk>


On Tue, Nov 28, 2017 at 6:30 PM, Casey Marshall 
<casey.marsh...@canonical.com <mailto:casey.marsh...@canonical.com>> 
wrote:


On Tue, Nov 28, 2017 at 12:09 PM, Tom Barber <t...@spicule.co.uk
<mailto:t...@spicule.co.uk>> wrote:

hey Casey

if you have no models and try and deploy a bundle with terms
it shows you the deploy screen them hangs. if you go back you
see the model with 0 units deployed.

this is a local bundle we were testing, just exported from the
gui, Ste can provide it if you need it.


Thanks for clarifying. One last question, what version of Juju was
used on the command line when trying to deploy the exported bundle?


Tom


On 28 Nov 2017 6:00 pm, "Casey Marshall"
<casey.marsh...@canonical.com
<mailto:casey.marsh...@canonical.com>> wrote:

On Tue, Nov 28, 2017 at 10:50 AM, Stephen Downie
<step...@spicule.co.uk <mailto:step...@spicule.co.uk>> wrote:

Thanks. I have tried running juju agree
spiculecharms/pdi-terms/1 and it states terms already
agreed?

When trying to deploy in the GUI it returns the error
message cannot create bundle: already exists. It
appears that it creates the model but does't actually
deploy anything? I know I'm a bit new to this but
something seems a bit broken.


Is it possible that the model name in the GUI (the drop
down in the upper-left of the canvas) matched an
already-created model name? You might need to type in a
new model name there.

Or does this happen for new models with this bundle no
matter what?

Was this in the GUI in JAAS (jujucharms.com
<http://jujucharms.com>)? Did you try deploying a bundle
from the charmstore, or did you try importing a
bundle.yaml file?


Thanks all for your help.

Spicule Ltd

Tel: 01603 327762



www.spicule.co.uk <http://www.spicule.co.uk>


On Tue, Nov 28, 2017 at 12:33 PM, Tom Barber
<t...@spicule.co.uk <mailto:t...@spicule.co.uk>> wrote:

stupid question, but I assume the bundles should
handle t's better?

On 28 Nov 2017 12:29, "Ales Stimec"
<ales.sti...@canonical.com
<mailto:ales.sti...@canonical.com>> wrote:

Hi,

Could you please try
   juju agree spiculecharms/pdi-terms/1

This is these are the terms that require
agreement in order to deploy
cs:~spiculecharms/pentaho-data-integration-45.
To get a list of terms i used:
   curl

"https://api.jujucharms.com/charmstore/v5/~spiculecharms/pentaho-data-integration-45/meta/any?include=id=terms

<https://api.jujucharms.com/charmstore/v5/%7Espiculecharms/pentaho-data-integration-45/meta/any?include=id=terms>"

Best regards,
    Ales Stimec

PS: fyi: the terms service issues short-lived
macaroons (auth tokens) that are valid for 5
minutes…




On 28 Nov 2017, at 12:59, John Meinel
<j...@arbash-meinel.com
<mailto:j...@arbash-meinel.com>> wrote:

Do you know what terms you need to accept?
You should be able to 'juju accept termname'.
The other thing to check is if your local
clock time is fairly accurate.
I believe we filed a bug recently that the
term server gives out temporary auth tokens
that are only valid for 1 minute. (and we end
up evaluating the time both locally and
remotely and should really only evaluate it
remotely).


John
=:->

On Nov 

Re: Getting the exposed ports

[Tom Barber]

So I did take a look at the iptables charm

https://api.jujucharms.com/charmstore/v5/~majduk/iptables-3/archive/hooks/relations/peer-discovery/peers.py

is sad on my setup.

unit-iptables-0: 22:08:53 DEBUG unit.iptables/0.install   File 
"/var/lib/juju/agents/unit-iptables-0/charm/hooks/relations/peer-discovery/peers.py", 
line 8, in 
unit-iptables-0: 22:08:53 DEBUG unit.iptables/0.install from 
charms.reactive.bus import State
unit-iptables-0: 22:08:53 DEBUG unit.iptables/0.install ImportError: 
cannot import name 'State'


I'm not sure whats changed in charms.reactive but I can't find the 
State. Also I dont' know where the upstream source is so if I do figure 
it out I can't submit a patch.


Cheers

Tom

On 01/12/17 16:58, Michał Ajduk wrote:

Hello,

You can take a look at iptables charm. It does the "easy part", that 
is admin defined ruleset.


I was actually thinking of making it also use the open ports. I'm 
pretty sure juju-info relation has the open ports data, but I can take 
a look.


BR,
Michal


01.12.2017 16:52 "Tom Barber" <t...@spicule.co.uk 
<mailto:t...@spicule.co.uk>> napisał(a):


Hello folks

I want to write a firewall charm for those deployments that aren't
in the cloud. The "easy" thing to do is provide a config block and
have admins write in rules and just apply them. I was wondering
though, if I wrote a subordinate charm on juju-info to attach to
anything, is there any mechanism for me to find the exposed port
of the parent charm? and whether its exposed or not?


Ta

Tom


-- 



Spicule Limited is registered in England & Wales. Company Number:
09954122. Registered office: First Floor, Telecom House, 125-135
Preston Road, Brighton, England, BN1 6AF. VAT No. 251478891.


All engagements are subject to Spicule Terms and Conditions of
Business. This email and its contents are intended solely for the
individual to whom it is addressed and may contain information
that is confidential, privileged or otherwise protected from
disclosure, distributing or copying. Any views or opinions
presented in this email are solely those of the author and do not
necessarily represent those of Spicule Limited. The company
accepts no liability for any damage caused by any virus
transmitted by this email. If you have received this message in
error, please notify us immediately by reply email before deleting
it from your system. Service of legal notice cannot be effected on
Spicule Limited by email.

-- 
Juju mailing list

Juju@lists.ubuntu.com <mailto:Juju@lists.ubuntu.com>
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
<https://lists.ubuntu.com/mailman/listinfo/juju>





--


Spicule Limited is registered in England & Wales. Company Number: 09954122. 
Registered office: First Floor, Telecom House, 125-135 Preston Road, 
Brighton, England, BN1 6AF. VAT No. 251478891.



All engagements are subject to Spicule Terms and Conditions of Business. 
This email and its contents are intended solely for the individual to whom 
it is addressed and may contain information that is confidential, 
privileged or otherwise protected from disclosure, distributing or copying. 
Any views or opinions presented in this email are solely those of the 
author and do not necessarily represent those of Spicule Limited. The 
company accepts no liability for any damage caused by any virus transmitted 
by this email. If you have received this message in error, please notify us 
immediately by reply email before deleting it from your system. Service of 
legal notice cannot be effected on Spicule Limited by email.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Getting the exposed ports

[Tom Barber]

Hello folks

I want to write a firewall charm for those deployments that aren't in 
the cloud. The "easy" thing to do is provide a config block and have 
admins write in rules and just apply them. I was wondering though, if I 
wrote a subordinate charm on juju-info to attach to anything, is there 
any mechanism for me to find the exposed port of the parent charm? and 
whether its exposed or not?



Ta

Tom


--


Spicule Limited is registered in England & Wales. Company Number: 09954122. 
Registered office: First Floor, Telecom House, 125-135 Preston Road, 
Brighton, England, BN1 6AF. VAT No. 251478891.



All engagements are subject to Spicule Terms and Conditions of Business. 
This email and its contents are intended solely for the individual to whom 
it is addressed and may contain information that is confidential, 
privileged or otherwise protected from disclosure, distributing or copying. 
Any views or opinions presented in this email are solely those of the 
author and do not necessarily represent those of Spicule Limited. The 
company accepts no liability for any damage caused by any virus transmitted 
by this email. If you have received this message in error, please notify us 
immediately by reply email before deleting it from your system. Service of 
legal notice cannot be effected on Spicule Limited by email.


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

Re: Deploying a charm with t's & c's

[Tom Barber]

hey Casey

if you have no models and try and deploy a bundle with terms it shows you
the deploy screen them hangs. if you go back you see the model with 0 units
deployed.

this is a local bundle we were testing, just exported from the gui, Ste can
provide it if you need it.

Tom

On 28 Nov 2017 6:00 pm, "Casey Marshall" <casey.marsh...@canonical.com>
wrote:

On Tue, Nov 28, 2017 at 10:50 AM, Stephen Downie <step...@spicule.co.uk>
wrote:

> Thanks. I have tried running juju agree spiculecharms/pdi-terms/1 and it
> states terms already agreed?
>
> When trying to deploy in the GUI it returns the error message cannot
> create bundle: already exists. It appears that it creates the model but
> does't actually deploy anything? I know I'm a bit new to this but something
> seems a bit broken.
>

Is it possible that the model name in the GUI (the drop down in the
upper-left of the canvas) matched an already-created model name? You might
need to type in a new model name there.

Or does this happen for new models with this bundle no matter what?

Was this in the GUI in JAAS (jujucharms.com)? Did you try deploying a
bundle from the charmstore, or did you try importing a bundle.yaml file?


>
> Thanks all for your help.
>
> Spicule Ltd
>
> Tel: 01603 327762
>
>
>
> www.spicule.co.uk
>
> On Tue, Nov 28, 2017 at 12:33 PM, Tom Barber <t...@spicule.co.uk> wrote:
>
>> stupid question, but I assume the bundles should handle t's better?
>>
>> On 28 Nov 2017 12:29, "Ales Stimec" <ales.sti...@canonical.com> wrote:
>>
>>> Hi,
>>>
>>> Could you please try
>>>juju agree spiculecharms/pdi-terms/1
>>>
>>> This is these are the terms that require agreement in order to deploy
>>> cs:~spiculecharms/pentaho-data-integration-45.
>>> To get a list of terms i used:
>>>curl "https://api.jujucharms.com/charmstore/v5/~spiculecharms/pen
>>> taho-data-integration-45/meta/any?include=id=terms"
>>>
>>> Best regards,
>>> Ales Stimec
>>>
>>> PS: fyi: the terms service issues short-lived macaroons (auth tokens)
>>> that are valid for 5 minutes…
>>>
>>>
>>>
>>> On 28 Nov 2017, at 12:59, John Meinel <j...@arbash-meinel.com> wrote:
>>>
>>> Do you know what terms you need to accept? You should be able to 'juju
>>> accept termname'.
>>> The other thing to check is if your local clock time is fairly accurate.
>>> I believe we filed a bug recently that the term server gives out
>>> temporary auth tokens that are only valid for 1 minute. (and we end up
>>> evaluating the time both locally and remotely and should really only
>>> evaluate it remotely).
>>>
>>>
>>> John
>>> =:->
>>>
>>> On Nov 28, 2017 15:49, "Stephen Downie" <step...@spicule.co.uk> wrote:
>>>
>>> Hi
>>>
>>> I am trying to deploy a bundle that has a charm that contains terms and
>>> conditions. I am getting the following error message
>>> https://gist.github.com/gizmo693/5a4fc5235da987a4f64e378e1850dd62
>>>
>>> Any help would be appreciated.
>>>
>>> Thanks
>>>
>>> Steve
>>>
>>> Spicule Ltd
>>> Tel: 01603 327762
>>>
>>>
>>> www.spicule.co.uk
>>>
>>> Spicule Limited is registered in England & Wales. Company Number:
>>> 09954122. Registered office: First Floor, Telecom House, 125-135
>>> Preston Road, Brighton, England, BN1 6AF
>>> <https://maps.google.com/?q=125-135+Preston+Road,+Brighton,+England,+BN1+6AF=gmail=g>.
>>> VAT No. 251478891.
>>>
>>>
>>> All engagements are subject to Spicule Terms and Conditions of Business.
>>> This email and its contents are intended solely for the individual to whom
>>> it is addressed and may contain information that is confidential,
>>> privileged or otherwise protected from disclosure, distributing or copying.
>>> Any views or opinions presented in this email are solely those of the
>>> author and do not necessarily represent those of Spicule Limited. The
>>> company accepts no liability for any damage caused by any virus transmitted
>>> by this email. If you have received this message in error, please notify us
>>> immediately by reply email before deleting it from your system. Service of
>>> legal notice cannot be effected on Spicule Limited by email.
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubunt

Re: Deploying a charm with t's & c's

[Tom Barber]

stupid question, but I assume the bundles should handle t's better?

On 28 Nov 2017 12:29, "Ales Stimec"  wrote:

> Hi,
>
> Could you please try
>juju agree spiculecharms/pdi-terms/1
>
> This is these are the terms that require agreement in order to deploy
> cs:~spiculecharms/pentaho-data-integration-45.
> To get a list of terms i used:
>curl "https://api.jujucharms.com/charmstore/v5/~spiculecharms/
> pentaho-data-integration-45/meta/any?include=id=terms"
>
> Best regards,
> Ales Stimec
>
> PS: fyi: the terms service issues short-lived macaroons (auth tokens) that
> are valid for 5 minutes…
>
>
>
> On 28 Nov 2017, at 12:59, John Meinel  wrote:
>
> Do you know what terms you need to accept? You should be able to 'juju
> accept termname'.
> The other thing to check is if your local clock time is fairly accurate.
> I believe we filed a bug recently that the term server gives out temporary
> auth tokens that are only valid for 1 minute. (and we end up evaluating the
> time both locally and remotely and should really only evaluate it remotely).
>
>
> John
> =:->
>
> On Nov 28, 2017 15:49, "Stephen Downie"  wrote:
>
> Hi
>
> I am trying to deploy a bundle that has a charm that contains terms and
> conditions. I am getting the following error message
> https://gist.github.com/gizmo693/5a4fc5235da987a4f64e378e1850dd62
>
> Any help would be appreciated.
>
> Thanks
>
> Steve
>
> Spicule Ltd
> Tel: 01603 327762
>
>
> www.spicule.co.uk
>
> Spicule Limited is registered in England & Wales. Company Number:
> 09954122. Registered office: First Floor, Telecom House, 125-135 Preston
> Road, Brighton, England, BN1 6AF. VAT No. 251478891.
>
>
> All engagements are subject to Spicule Terms and Conditions of Business.
> This email and its contents are intended solely for the individual to whom
> it is addressed and may contain information that is confidential,
> privileged or otherwise protected from disclosure, distributing or copying.
> Any views or opinions presented in this email are solely those of the
> author and do not necessarily represent those of Spicule Limited. The
> company accepts no liability for any damage caused by any virus transmitted
> by this email. If you have received this message in error, please notify us
> immediately by reply email before deleting it from your system. Service of
> legal notice cannot be effected on Spicule Limited by email.
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>

-- 


Spicule Limited is registered in England & Wales. Company Number: 09954122. 
Registered office: First Floor, Telecom House, 125-135 Preston Road, 
Brighton, England, BN1 6AF. VAT No. 251478891.


All engagements are subject to Spicule Terms and Conditions of Business. 
This email and its contents are intended solely for the individual to whom 
it is addressed and may contain information that is confidential, 
privileged or otherwise protected from disclosure, distributing or copying. 
Any views or opinions presented in this email are solely those of the 
author and do not necessarily represent those of Spicule Limited. The 
company accepts no liability for any damage caused by any virus transmitted 
by this email. If you have received this message in error, please notify us 
immediately by reply email before deleting it from your system. Service of 
legal notice cannot be effected on Spicule Limited by email.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Debug logs

[Tom Barber]

Maybe its just me, I dunno.

Has the amount of detail in debug-logs decreased?

I'm  not seeing failure causes for example:

2017-11-26 00:11:18 INFO juju.worker.uniter resolver.go:104 found queued
"install" hook
2017-11-26 00:12:26 ERROR juju.worker.uniter.operation runhook.go:107 hook
"install" failed: exit status 1
2017-11-26 00:12:26 INFO juju.worker.uniter resolver.go:100 awaiting error
resolution for "install" hook
2017-11-26 00:12:31 INFO juju.worker.uniter resolver.go:100 awaiting error
resolution for "install" hook
2017-11-26 00:12:32 ERROR juju.worker.uniter.operation runhook.go:107 hook
"install" failed: exit status 1
2017-11-26 00:12:32 INFO juju.worker.uniter resolver.go:100 awaiting error
resolution for "install" hook
2017-11-26 00:12:42 INFO juju.worker.uniter resolver.go:100 awaiting error
resolution for "install" hook
2017-11-26 00:12:43 ERROR juju.worker.uniter.operation runhook.go:107 hook
"install" failed: exit status 1
2017-11-26 00:12:43 INFO juju.worker.uniter resolver.go:100 awaiting error
resolution for "install" hook
2017-11-26 00:13:03 INFO juju.worker.uniter resolver.go:100 awaiting error
resolution for "install" hook
2017-11-26 00:13:05 ERROR juju.worker.uniter.operation runhook.go:107 hook
"install" failed: exit status 1
2017-11-26 00:13:05 INFO juju.worker.uniter resolver.go:100 awaiting error
resolution for "install" hook
2017-11-26 00:13:43 INFO juju.worker.uniter resolver.go:100 awaiting error
resolution for "install" hook
2017-11-26 00:13:44 ERROR juju.worker.uniter.operation runhook.go:107 hook
"install" failed: exit status 1
2017-11-26 00:13:44 INFO juju.worker.uniter resolver.go:100 awaiting error
resolution for "install" hook
2017-11-26 00:15:01 INFO juju.worker.uniter resolver.go:100 awaiting error
resolution for "install" hook
2017-11-26 00:15:02 ERROR juju.worker.uniter.operation runhook.go:107 hook
"install" failed: exit status 1
2017-11-26 00:15:02 INFO juju.worker.uniter resolver.go:100 awaiting error
resolution for "install" hook
2017-11-26 00:17:39 INFO juju.worker.uniter resolver.go:100 awaiting error
resolution for "install" hook
2017-11-26 00:17:40 ERROR juju.worker.uniter.operation runhook.go:107 hook
"install" failed: exit status 1
2017-11-26 00:17:40 INFO juju.worker.uniter resolver.go:100 awaiting error
resolution for "install" hook
2017-11-26 00:21:42 INFO juju.worker.uniter resolver.go:100 awaiting error
resolution for "install" hook
2017-11-26 00:22:40 INFO juju.worker.uniter resolver.go:100 awaiting error
resolution for "install" hook
2017-11-26 00:22:41 ERROR juju.worker.uniter.operation runhook.go:107 hook
"install" failed: exit status 1

-- 


Spicule Limited is registered in England & Wales. Company Number: 09954122. 
Registered office: First Floor, Telecom House, 125-135 Preston Road, 
Brighton, England, BN1 6AF. VAT No. 251478891.


All engagements are subject to Spicule Terms and Conditions of Business. 
This email and its contents are intended solely for the individual to whom 
it is addressed and may contain information that is confidential, 
privileged or otherwise protected from disclosure, distributing or copying. 
Any views or opinions presented in this email are solely those of the 
author and do not necessarily represent those of Spicule Limited. The 
company accepts no liability for any damage caused by any virus transmitted 
by this email. If you have received this message in error, please notify us 
immediately by reply email before deleting it from your system. Service of 
legal notice cannot be effected on Spicule Limited by email.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: using the juju client from jenkins

[Tom Barber]

I'm not sure if this is of any use:

https://github.com/spiculedata/circleci-juju/blob/master/charmlogin

I use `expect` to process a charm login for me.


On 22/11/17 13:01, James Beedy wrote:

Konstantinos,

Thanks for that. I need to get CI/CD setup for my charms, that will be 
very helpful to me very soon.


Possibly I didn't illuminate the issue I'm having correctly though.

1) I have a pdl-api charm, that manages the pdl-api.snap.
2) My CI/CD pipeline for the pdl-api has two steps; build, deploy.
    - The build job tests the code and builds the snap, then passes 
the built artifact to the deploy step.
    - The deploy step basically takes the built snap and attaches it 
to the pdl-api charm https://imgur.com/a/UiIg7


The issue at hand, is that my jenkins user token expires and I end up 
with a failing deploy job http://paste.ubuntu.com/26019762/ .


To remedy this, I always have to `juju ssh jenkins/0; sudo -ui 
jenkins; juju login`


Is this more clear?

Thanks





On Wed, Nov 22, 2017 at 2:17 AM, Konstantinos Tsakalozos 
> 
wrote:


Hi James,

We build our charms, push them to the store on the edge channel, and
then our tests run against what is on edge. With this approach the
team can sync on a specific build revision instead of each one
separately trying to rebuild the charm locally and reproduce any
unexpected behaviour. As soon as we are happy with a build we just
promote it to the next channel (beta,candidate or stable). You can
find our work here:
https://github.com/juju-solutions/kubernetes-jenkins/tree/master/charms


Cheers,
Konstantinos

On Wed, Nov 22, 2017 at 2:21 AM, James Beedy > wrote:
> I've a feeling that the majority of the CI/CD I've left in my
trails that
> attaches a resource from jenkins via juju bash cli are probably
not working.
> The latest CI/CD I've setup runs `juju attach` from jenkins, and
I have to
> login to the jenkins shell and su to the jenkins user and login
to be able
> to run my deploy step in jenkins.
>
> Is there a way that people are doing the jenkins<->juju dance
without
> lib-juju?
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com 
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju

>







--


Spicule Limited is registered in England & Wales. Company Number: 09954122. 
Registered office: First Floor, Telecom House, 125-135 Preston Road, 
Brighton, England, BN1 6AF. VAT No. 251478891.



All engagements are subject to Spicule Terms and Conditions of Business. 
This email and its contents are intended solely for the individual to whom 
it is addressed and may contain information that is confidential, 
privileged or otherwise protected from disclosure, distributing or copying. 
Any views or opinions presented in this email are solely those of the 
author and do not necessarily represent those of Spicule Limited. The 
company accepts no liability for any damage caused by any virus transmitted 
by this email. If you have received this message in error, please notify us 
immediately by reply email before deleting it from your system. Service of 
legal notice cannot be effected on Spicule Limited by email.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

JAAS confusion

[Tom Barber]

Hello folks

Couple of random questions:

juju destroy-model mymodel
WARNING! This command will destroy the "mymodel" model.
This includes all machines, applications, data and other resources.

Continue [y/N]? y
ERROR cannot connect to API: model "mymodel" has been removed from the
controller, run 'juju models' and switch to one of them.
There are 6 accessible models on controller "jaas".

juju models
Controller: jaas

Model  Cloud/Region   Status Machines  Cores  Access  Last
connection
mymodelaws/eu-west-1  available 5  9  -   never
connected



2 things in this output, firstly how do I delete the model that seems stuck?

secondly what is the 6 accessible models bit talking about?

Thanks

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

Re: Charm snap is now strictly confined

[Tom Barber]

good effort devs!

On 8 Sep 2017 7:42 pm, "Cory Johns"  wrote:

> Greetings,
>
> I just wanted to make a quick announcement that the charm snap is now
> strictly confined on the stable channel (rev 17).  This fixes issues like
> https://github.com/juju/charm-tools/issues/339 and
> https://github.com/juju/charm-tools/issues/319 and prevents similar
> issues from cropping up in the future.
>
> In general, this change should be pretty much transparent, with the one
> caveat being that you can only build charms from under your HOME directory.
>
> --
> Juju mailing list
> j...@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Jujucharms

[Tom Barber]

Sad times! Stick a quid in the meter!

On Sat, Sep 9, 2017 at 3:21 PM, John Meinel <j...@arbash-meinel.com> wrote:

> It appears to be a more general Canonical outage, as irc.canonical.com is
> also affected.
>
> John
> =:->
>
>
> On Sat, Sep 9, 2017 at 6:03 PM, Tom Barber <t...@spicule.co.uk> wrote:
>
>> Okay, own up, who killed Jujucharms.com whilst i'm trying to catch up on
>> work? :)
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Jujucharms

[Tom Barber]

Okay, own up, who killed Jujucharms.com whilst i'm trying to catch up on
work? :)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm snap is now strictly confined

[Tom Barber]

good effort devs!

On 8 Sep 2017 7:42 pm, "Cory Johns"  wrote:

> Greetings,
>
> I just wanted to make a quick announcement that the charm snap is now
> strictly confined on the stable channel (rev 17).  This fixes issues like
> https://github.com/juju/charm-tools/issues/339 and
> https://github.com/juju/charm-tools/issues/319 and prevents similar
> issues from cropping up in the future.
>
> In general, this change should be pretty much transparent, with the one
> caveat being that you can only build charms from under your HOME directory.
>
> --
> 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: How to deploy the same charm with different name？

[Tom Barber]

simply:

juju deploy [charm] newcharmname

is what you're after.

Tom

On Mon, Sep 4, 2017 at 8:49 PM, fengxia <fx...@lenovo.com> wrote:

> Hi Juju,
>
> Previously, I was able to define two charms in bundle, both have `charm`
> (the path to charm files) set to the same location, but with different
> names, and `juju deploy this-bundle` will create two applications.
>
> For example (bundle):
>
> Sevices:
>
>A:
>
>  charm: ./trusty/mycharm
>
> .
>
>B:
>
>   charm: ./trusty/mycharm
>
> Deploying this will create two applications, named "A" and "B".
>
> How to achieve this using two-step $ juju deploy [charm] commandline
> instead? On the second time Juju complained that application "mycharm"
> already exist.
>
>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794
> fx...@lenovo.com
>
> Lenovo.com
> Twitter | Facebook | Instagram | Blogs | Forums
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju
>



-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316 <+44%2056%200364%201316>
US: +18448141689 <(844)%20814-1689>

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

Re: How to quickly re-deploy the same charm

[Tom Barber]

Yeah you need to do juju resolved charmunit/0 --no-retry to get it out of
the error state so that the upgrade happens.

On Fri, Aug 18, 2017 at 2:32 PM, fengxia <fx...@lenovo.com> wrote:

> Hi Juju,
>
> So here is what I got:
>
> 1. juju status shows  `mycharm` is in an error state.
>
> 2. Fixed the bug and built a new version of the same application charm.
>
> 3. `juju upgrade-charm --path /path/to/mycharm mycharm
>
> It says `Added charm  local:trusty/mycharm to the model". But nothing
> happens from there.
>
> Did I miss a step somewhere?
>
> On 08/18/2017 09:07 AM, Tom Barber wrote:
>
> juju upgrade-charm is I suspect what you're looking for .
>
> Tom
>
>
> On Fri, Aug 18, 2017 at 1:58 PM, fengxia <fx...@lenovo.com> wrote:
>
>> Hi Juju,
>>
>> I'm testing a locally built charm using `localhost` (LXD) setup.
>> Everytime `juju deploy` will take a good 5-10 minutes just to download and
>> install python packages before the charm code runs.
>>
>> I'm wondering what's a good practice to cut down this in dev iteration?
>> So if I build a version 2 of the same charm, can I do `juju deploy
>> my-charm` again to cause an update/upgrade, so to save the initial install
>> time?
>>
>> Any advice?
>>
>> --
>> Feng xia
>> Engineer
>> Lenovo USA
>>
>> Phone: 5088011794
>> fx...@lenovo.com
>>
>> Lenovo.com
>> Twitter | Facebook | Instagram | Blogs | Forums
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>
>
>
> --
> Tom Barber
> CTO Spicule LTD
> t...@spicule.co.uk
>
> http://spicule.co.uk
>
> @spiculeim <http://twitter.com/spiculeim>
>
> Schedule a meeting with me <http://meetme.so/spicule>
>
> GB: +44(0)5603641316 <+44%2056%200364%201316>
> US: +18448141689 <(844)%20814-1689>
>
> <https://leanpub.com/juju-cookbook>
>
>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794 <(508)%20801-1794>fx...@lenovo.com
>   
> Lenovo.com
> Twitter | Facebook | Instagram | Blogs | Forums
>
>


-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689

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

Re: How to quickly re-deploy the same charm

[Tom Barber]

juju upgrade-charm is I suspect what you're looking for .

Tom


On Fri, Aug 18, 2017 at 1:58 PM, fengxia <fx...@lenovo.com> wrote:

> Hi Juju,
>
> I'm testing a locally built charm using `localhost` (LXD) setup. Everytime
> `juju deploy` will take a good 5-10 minutes just to download and install
> python packages before the charm code runs.
>
> I'm wondering what's a good practice to cut down this in dev iteration? So
> if I build a version 2 of the same charm, can I do `juju deploy my-charm`
> again to cause an update/upgrade, so to save the initial install time?
>
> Any advice?
>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794
> fx...@lenovo.com
>
> Lenovo.com
> Twitter | Facebook | Instagram | Blogs | Forums
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju
>



-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689

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

Re: juju application stuck, cannot remove/scale out

[Tom Barber]

Yeah but --no-retry will  mean the hook wont re-execute and will set itself
back to a happy state,  even if that doesn't reflect reality.

Tom

On Fri, Aug 4, 2017 at 2:48 PM, Patrizio Bassi <patrizio.ba...@gmail.com>
wrote:

> Unfortunately i cannot fix the issue because it looks like a charm problem
> https://paste.ubuntu.com/25240017/
>
> Patrizio
>
>
> 2017-08-04 15:43 GMT+02:00 Tom Barber <t...@spicule.co.uk>:
>
>> You need to mark it resolved and if that fails you can do juju resolved
>> designate/0 --no-retry
>>
>> Once its hooks have cleared out it will disappear.
>>
>> Tom
>>
>> On Fri, Aug 4, 2017 at 2:33 PM, Patrizio Bassi <patrizio.ba...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> i've deployed a designate charm with maas provider in a lxd container.
>>> when i tried to remove (juju remove-application designate) it i got the
>>> unit stuck with  hook failed: "update-status"
>>>
>>> Debugging with lxc info in the host machine i found the container is
>>> still alive and with running processes.
>>>
>>> now i cannot use add-unit nor remove it, it's just stuck. i rebooted the
>>> container, no way. I used juju resolved designate/0, no way.
>>>
>>> How to fix this kind of problem?
>>> Thank you
>>>
>>> Patrizio
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>>
>> --
>> Tom Barber
>> CTO Spicule LTD
>> t...@spicule.co.uk
>>
>> http://spicule.co.uk
>>
>> @spiculeim <http://twitter.com/spiculeim>
>>
>> Schedule a meeting with me <http://meetme.so/spicule>
>>
>> GB: +44(0)5603641316 <+44%2056%200364%201316>
>> US: +18448141689 <+1%20844-814-1689>
>>
>> <https://leanpub.com/juju-cookbook>
>>
>
>
>
>


-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689

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

Re: juju application stuck, cannot remove/scale out

[Tom Barber]

You need to mark it resolved and if that fails you can do juju resolved
designate/0 --no-retry

Once its hooks have cleared out it will disappear.

Tom

On Fri, Aug 4, 2017 at 2:33 PM, Patrizio Bassi <patrizio.ba...@gmail.com>
wrote:

> Hi,
>
> i've deployed a designate charm with maas provider in a lxd container.
> when i tried to remove (juju remove-application designate) it i got the
> unit stuck with  hook failed: "update-status"
>
> Debugging with lxc info in the host machine i found the container is still
> alive and with running processes.
>
> now i cannot use add-unit nor remove it, it's just stuck. i rebooted the
> container, no way. I used juju resolved designate/0, no way.
>
> How to fix this kind of problem?
> Thank you
>
> Patrizio
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>


-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689

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

Re: call for testing: relations across Juju models

[Tom Barber]

Thanks Rick!

We'll be testing this out next week for sure!

On 7 Jul 2017 6:37 pm, "Rick Harding"  wrote:

> As I noted in The Juju Show [1] this week I've put together a blog post
> around the cross model relations feature that folks can test out in Juju
> 2.2. Please test it out and provide your feedback.
>
> http://mitechie.com/blog/2017/7/7/call-for-testing-shared-
> services-with-juju
>
> Current known limitations:
> Only works in the same model
> You need to bootstrap with the feature flag to test it out
> Does not currently work with relations to subordinates. Work is in progress
>
> There's a lot of possibilities so we'd like to hear what you test out. I
> just noticed that Spicule folks are tinkering with an LDAP charm [2] and a
> single LDAP instance providing auth to an array of models is a very
> exciting possibility, for instance.
>
> Thanks everyone.
>
> Rick
>
> 1: https://www.youtube.com/watch?v=d_vMN_opVlA
> 2: https://twitter.com/stephenspicule/status/883350361305747456
>
> --
> 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: Juju vs Openshift

[Tom Barber]

Hey Giuseppe

Having worked in the data sector for a while now whilst keeping an eye on
container tech, for now at least I'd keep deploying data services to
baremetal for a number of reasons, docker container discovery for one. Juju
hadoop on services vs hadoop on containers is a bit of a no-brainer
currently. That said of course data on containers support well improve but
for now I'd stick to the basics.

My 2 cents.

Tom

On 27 Jun 2017 8:32 am, "Giuseppe Attardi"  wrote:

Some Italian public administration are considering purchasing cloud
services for Big Data analytics deployed on Openshift.
How this solution would compare with using a Kubernetes cluster deployed
through Juju?
More in general, what is the strategic outlook of container platforms vs
virtualization platforms?
Are the former ones going to overcome the latter?

--

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

CDK upgrade

[Tom Barber]

I'd just like to give a shout out to Chuck and Matt, for their CDK upgrade
path pattern, even the deb to snap migration path works amazingly. Real
quality work there and a pattern we should all be following in charm
development.

Cheers

Tom

-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689

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

Spicule and Big Data

[Tom Barber]

Hi folks

Bit of trumpet blowing but also just offering up more services for the
Hadoop stack on Juju. Our new main site for Spicule data in in production
but we have added a page to the main Spicule Site to start promoting our
supported Hadoop stuff on Juju/JAAS. http://spicule.co.uk/dataatscale.html

Still work in progress both in terms of what we are offering and supporting
and how we promote it but I figured it was worth putting out there.

Cheers

Tom

-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689

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

Re: [ANN] Kubernetes 1.6.3 snaps available in the edge channel for testing

[Tom Barber]

Good work Chuck!

We'll take them for a spin over at DARPA.

Tom

On Thu, May 11, 2017 at 4:34 PM, Charles Butler <
charles.but...@canonical.com> wrote:

> We’ve just published a new revision of the Kubernetes snaps in edge.
>
> This includes the latest upstream release of Kubernetes for 1.6.
>
>
> For those looking to upgrade from 1.6.2 or an earlier version of the snaps
> this can be performed with the charms:
>
>
> juju config kubernetes-master channel=1.6/edge
>
> juju config kubernetes-worker channel=1.6/edge
>
>
>
> We expect these snaps to be drop-in upgrades in the current charms. If you
> find bugs or issues we’re ready to receive bug reports at the issue
> tracker: https://github.com/juju-solutions/bundle-canonical-
> kubernetes/issues
>
>
> This is not recommended for production clusters until the snaps have been
> promoted to the stable channel, this is for early adopters seeking
> features/fixes in the latest releases of Kubernetes. A stable release
> communication will follow soon, and that will indicate the version has been
> verified to pass our internal testing and is ready for production usage.
>
>
> Finally, if you're operating Kubernetes or using Kubernetes feel free to
> reach out: kuberne...@ubuntu.com
>
>
> Thanks and all the best,
>
>
> - The Canonical distribution of Kubernetes team
>
>
> --
> Juju Charmer
> Canonical Group Ltd.
> Ubuntu - Linux for human beings | www.ubuntu.com
> conjure-up canonical-kubernetes | jujucharms.com
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>


-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689

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

Search results

[Tom Barber]

Hello folks

I know this comes up from time to time, and finding the right balance is
hard, but this just seems broken to me:

In the charm store I have a charm called gitlab-server and a bundle called
gitlab-ssl neither are promulgated I appreciate. I also understand that
you're trying to offer recommended apps other non recommended, but surely
it makes sense to do a wildcard search for stuff rather than hiding
everything other than the recommended charm? so at least users looking up
gitlab or whatever would get in affect gitlab* ?

Of course getting them recommended is also something you guys want to
happen and something a lot of the community charms are working towards, but
this seems unnecessarily restrictive.

-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689

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

Re: Proposing Alex Kavanagh for ~charmers

[Tom Barber]

Can you bring spring back? otherwise its a -1..

On Thu, Apr 27, 2017 at 10:44 AM, Alex Kavanagh <alex.kavan...@canonical.com
> wrote:

> Hi All
>
> Thanks for all of the +1's!  I hope I can live up to them! :)
>
> Cheers
> Alex.
>
>
> On Thu, Apr 27, 2017 at 8:40 AM, Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Unofficial +1
>>
>> 2017-04-26 11:52 GMT+02:00 James Page <james.p...@ubuntu.com>:
>>
>>> Hi Charmers
>>>
>>> I'd like to propose Alex (tinwood) for membership of charmers; he's
>>> worked extensively across the OpenStack charms, providing valuable reviews
>>> to the rest of the team, has been reviewing charm-helpers updates and has
>>> been instrumental in the OpenStack charms use of reactive and layers for
>>> building newer charms.
>>>
>>> He's also working as part of the team for Reactive 2.0.
>>>
>>> I think he'll be a valuable addition to the core charmers team!
>>>
>>> Cheers
>>>
>>> James
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
>
> --
> Alex Kavanagh - Software Engineer
> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>


-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689

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

Re: Gitlab & SSL

[Tom Barber]

Yeah thats the place, hadn't pushed it.

Still got some more work to clean up the config setting a bit, and me and
Chuck were mulling over exposing the CI and Docker Repo which I currently
don't do. One thing we'd like is Gitlab <-> EasyRSA connectivity and then
to K8S so you can setup a private docker repo and hook it into CDK on a
relation.

Anyway! Thats all down the line later this year I hope.

Tom

On Wed, Apr 26, 2017 at 4:54 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Awesome! Is the code of gitlab online somewhere? https://github.com/
> osbi/layer-gitlab seems to be outdated.
>
> 2017-04-26 14:19 GMT+02:00 Tom Barber <t...@spicule.co.uk>:
>
>> Hey folks
>>
>> After some prodding from Rick I updated my Gitlab charm and ensured it
>> worked with Tengu's fantastic new SSL termination proxy charm to provide
>> SSL encrypted Gitlab OOTB.
>>
>> The new charm now runs on Xenial and Trusty and provides Gitlab via the
>> omnibus repo. I have some more stuff down the line, but hopefully folks
>> find it useful.
>>
>> https://jujucharms.com/u/spiculecharms/gitlab-server
>> https://jujucharms.com/u/spiculecharms/gitlab-ssl
>>
>> Tom
>>
>> --
>> Tom Barber
>> CTO Spicule LTD
>> t...@spicule.co.uk
>>
>> http://spicule.co.uk
>>
>> @spiculeim <http://twitter.com/spiculeim>
>>
>> Schedule a meeting with me <http://meetme.so/spicule>
>>
>> GB: +44(0)5603641316 <+44%2056%200364%201316>
>> US: +18448141689 <+1%20844-814-1689>
>>
>> <https://leanpub.com/juju-cookbook>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>


-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689

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

Gitlab & SSL

[Tom Barber]

Hey folks

After some prodding from Rick I updated my Gitlab charm and ensured it
worked with Tengu's fantastic new SSL termination proxy charm to provide
SSL encrypted Gitlab OOTB.

The new charm now runs on Xenial and Trusty and provides Gitlab via the
omnibus repo. I have some more stuff down the line, but hopefully folks
find it useful.

https://jujucharms.com/u/spiculecharms/gitlab-server
https://jujucharms.com/u/spiculecharms/gitlab-ssl

Tom

-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689

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

Big Data, JAAS and Juju

[Tom Barber]

Hello folks,

I figured I'd spin a yarn before going home for the day about Juju and its
importance ot my company.

For those of you who don't know me my day job is a developer at NASA JPL
which is contractual and ongoing for the foreseeable future but clearly not
infinite (as much as I'd like it to be). To facilitate my involvement at
NASA I founded Spicule as a payment conduit and experimental business to
tinker with some ideas.

Anyway, that aside, as most of you who do know me will know, I've always
been a fan of Juju since Sam twisted my arm into writing some charm stuff 2
years ago and Jorge forced me (yes.. forced) to come to Gent 14 months ago.
My, and now our plan as I've been hiring a few folks dedicated to Juju
development and support over the last couple of months, has been to ramp up
the Juju stuff from June-ish onwards, and maybe before if we can get our
stuff together. Of course a few things have always caused us problems as
people wanting to make a living out of a fantastic platform like Juju,
monetization being pretty key. Me hiring people for a platform I've yet to
figure out how to leverage fully clearly exposes me to more risk, but risk
I feel is worth taking.

I know there are plans afoot to allow us to provide support through the
portal, and if someone needs some testers, or wants to explain it nicely so
we can figure out how best to support it please feel free to reach out. I'm
very much up for providing generic Big Data/Small Data services support
based on Juju charms, Juju charm development support and other stuff and
this is what we (Spicule) are working towards.

At the end of the day we all(the community at large) need to make some
money out of Juju, be it through development services, support services or
building products on top of Juju, so from the outside asking in, please let
us know what we can do to help facilitate that so we can all win.

Thanks

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

Matrix Testing Release

[Tom Barber]

Hi folks,

We're formulating some plans for big data solutions on JAAS coming in the
second half of 2017 assuming the support aspects etc can be ironed out
between now and then.

Anyway, when we were in Gent Pete gave a cool demo of the Matrix testing
solution which is idea for the stuff we're working on, whats the status of
that? Are we likely to see a release any time soon?

Thanks

Tom

-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689

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

Re: Can we do bundle within a bundle?

[Tom Barber]

Currently bundles are pretty dumb and nested bundles don't exist.

Tom

On 20 Apr 2017 20:29, "fengxia"  wrote:

> We have a design that calls for tree structure of entities, each will be
> mapped to a charm/bundle. So how to bundle a list of bundles?
>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794
> fx...@lenovo.com
>
> Lenovo.com
> Twitter | Facebook | Instagram | Blogs | Forums
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju deploy same application twice, failed "application already exist"

[Tom Barber]

Sorry, yeah didn't hit reply all! :)

Yeah, deploy a service once, add unit for more capacity or HA generally.

On Thu, Apr 20, 2017 at 1:36 PM, fengxia <fx...@lenovo.com> wrote:

> I c. So I should have used add-unit command instead of "deploy". Is that
> right?
>
> On 04/20/2017 08:34 AM, Tom Barber wrote:
>
> You add new "units" so you can run n units of a charm which then can use
> the internal peer relation to deal with inter-app communications.
>
> Tom
>
> On Thu, Apr 20, 2017 at 1:32 PM, fengxia <fx...@lenovo.com> wrote:
>
>> Hi,
>>
>> I have developed a charm called "test". Using command line to deploy from
>> local repo:
>>
>> $ juju deploy $JUJU_REPOSITORY/trusty/test
>>
>> First one went well. Issuing this command again will give error:
>>
>> 08:28:49 ERROR cmd supercommand.go:460 cannot add application "test":
>> application already exists
>>
>> Must be missing something. How do you achieve HA then if one cant install
>> multiple instances of a charm?
>>
>> --
>> Feng xia
>> Engineer
>> Lenovo USA
>>
>> Phone: 5088011794
>> fx...@lenovo.com
>>
>> Lenovo.com
>> Twitter | Facebook | Instagram | Blogs | Forums
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>
>
>
> --
> Tom Barber
> CTO Spicule LTD
> t...@spicule.co.uk
>
> http://spicule.co.uk
>
> @spiculeim <http://twitter.com/spiculeim>
>
> Schedule a meeting with me <http://meetme.so/spicule>
>
> GB: +44(0)5603641316 <+44%2056%200364%201316>
> US: +18448141689 <(844)%20814-1689>
>
> <https://leanpub.com/juju-cookbook>
>
>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794 <(508)%20801-1794>fx...@lenovo.com
>   
> Lenovo.com
> Twitter | Facebook | Instagram | Blogs | Forums
>
>


-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689

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

Thank you!

[Tom Barber]

I'll probably get whipped for doing this as its been playing on my mind and
I feel it needs doing.

Hopefully those who have left the company in the last few weeks haven't
completely left this list, I'd just like to send out a heartfelt thank you
on behalf of the community and juju users, to the people with whom I've
worked with over the past 18 months and to anyone I haven't, who have put
in blood sweat and tears at Canonical to create Juju it is a fantastic
platform and I hope wherever you all end up next our paths cross again
because you are all a great bunch of people.

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

Re: Juju Snap Changes

[Tom Barber]

p to share will also find it
>>>> much easier. By default, running snapcraft on the juju tree will build a
>>>> snap using your local tree and will bundle the needed agent. The
>>>> snapcraft.yaml also points out how easily you can grab a specific branch,
>>>> commit or tag to snap up. Sharing your own version of the juju client with
>>>> the world is as simple as "snapcraft, snapcraft release".
>>>>
>>>> You'll find the snap related things in the snap folder in the juju git
>>>> tree. As always PRs welcome!
>>>>
>>>> Nicholas
>>>>
>>>> --
>>>> Juju mailing list
>>>> Juju@lists.ubuntu.com
>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>> an/listinfo/juju
>>>>
>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>


-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689

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

Re: Nagios charm maintenance

[Tom Barber]

yeah it's maintained by (I think) Stuart Bishop

On 21 Feb 2017 20:48, "Sandor Zeestraten"  wrote:

> Hey Juju folks,
>
> We've been running into some issues (especially http://pad.lv/1605733)
> when using the promulgated Nagios charm for various deployments and would
> like to contribute back some fixes.
>
> The bug tracker for the charm/nagios-charmers seems pretty dead so I was
> wondering if anybody knew the status of the Nagios charm and if/who is
> maintaining it?
>
>
> P.S. Even the Canonical Bootstack Squad seems to have hit by the bug
> mentioned above (http://lists.openstack.org/pi
> permail/openstack-dev/2017-January/110567.html)
>
> Thanks
> --
> Sandor Zeestraten
>
> --
> 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: All our Charms became hidden because we promulgated some

[Tom Barber]

I acutally started writing my own crawler and search engine for
JujuCharms.com because stuff just goes missing, Merlijn maybe we should
team up! :)

On Fri, Feb 17, 2017 at 12:48 PM, Rick Harding <rick.hard...@canonical.com>
wrote:

> Merlijn, you're correct that when you search for a solution we prefer and
> promote the promulgated charms in place of the community ones.
>
> You can find the list of charms for a user directly by clicking on the
> user name in that list or going to the user pages which have a /u vs the /q
> for query.
>
> https://jujucharms.com/u/tengu-team/
> https://jujucharms.com/u/tengu-bot
>
> I do agree that the search results in this case, where you're searching
> for a user vs a charm/solution isn't helpful and we should link to the
> users in the search results to help you more directly get you to the
> /u/ url from those search results.
>
> Hopefully that helps until we can address exposing users more directly in
> the search results.
>
> On Fri, Feb 17, 2017 at 7:41 AM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Hi all
>>
>>
>> Just stumbled on a serious issue. Until recently, all our charms where
>> visible when searching for our team name in the charm store. Now, only our
>> promulgated charms show up in the search result. Our colleagues use the
>> search function to find our charms but they can't find them anymore.
>>
>> Query to username with promulgated charms: https://jujucharms.
>> com/q/tengu-team
>> Query to username without promulgated charms: https://jujucharms.
>> com/q/tengu-bot
>>
>> As you can see in both queries, either the "recommended" or the
>> "community" charms show up, they don't show both.
>>
>> This is a serious issue because *this makes it impossible to view/use
>> our charms in the Juju UI*. The jujucharms.com storefront has a "user"
>> page where we can see all our charms, but this page doesn't exist in the
>> Juju UI. https://jujucharms.com/u/tengu-team/
>>
>> Is it possible to temporarily un-promulgate the openvpn and eclipse-che
>> charms until this bug is fixed? This is really an issue since our
>> colleagues can't find our charms anymore.
>>
>>
>>
>> Kind regards
>> Merlijn
>> --
>> 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
>
>


-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689

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

Re: Simplestreams and juju 2.x on openstack

[Tom Barber]

in doing that it breaks juju tab complete by the way.

I'll file some issues later if they don't already exist.

Tom

On 11 Feb 2017 10:36, "Tom Barber" <t...@spicule.co.uk> wrote:

So my way around this because i can't snap install juju is to apt install
juju now it returns.

Tom

On Sat, Feb 11, 2017 at 8:29 AM, Tom Barber <t...@spicule.co.uk> wrote:

> Weird. I have a new ec2 node and just snap installed conjure up and used
> the supplied juju.
>
> Tom
>
> On 11 Feb 2017 05:27, "Curtis Hovey-Canonical" <cur...@canonical.com>
> wrote:
>
>>
>>
>> On Fri, Feb 10, 2017 at 8:04 PM, Tom Barber <t...@spicule.co.uk> wrote:
>>
>>> If I want to bootstrap openstack how do I deal with simple streams?
>>>
>>> The docs point to https://jujucharms.com/docs/stable/howto-privatecloud
>>> but in 2.1RC1 `juju metadata` isn't valid.
>>>
>>
>> Are you using a deb package, a snap, the MacOS client, the window's
>> installer?
>>
>> The windows installer does not provide the metadata plugin. All other
>> packages/snaps/downloads do.
>>
>> The juju metadata works for me using either the snap or the deb on a
>> pristine host. The juju-metadata plugin is included in the osx download and
>> it gives me the same results as the Ubuntu metadata plugins.
>>
>>
>> --
>> Curtis Hovey
>> Canonical Cloud Development and Operations
>> http://launchpad.net/~sinzui
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>


-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316 <+44%2056%200364%201316>
US: +18448141689 <(844)%20814-1689>

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

Simplestreams and juju 2.x on openstack

[Tom Barber]

If I want to bootstrap openstack how do I deal with simple streams?

The docs point to https://jujucharms.com/docs/stable/howto-privatecloud but
in 2.1RC1 `juju metadata` isn't valid.

Thanks

Tom

-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689

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

Re: Can't push to my own team

[Tom Barber]

Thanks Ryan

Just tried it,  same error.

bugg@tom-laptop2:~/Projects/charms/builds/apache-solr$ charm whoami
User: spicule
Group membership: apachefoundation, apachesoftwarefoundation,
charm-contributors, containers

For whatever reason, it refuses to see the spicule team.


On Tue, Feb 7, 2017 at 12:25 AM, Ryan Beisner <ryan.beis...@canonical.com>
wrote:

> Hi Tom,
>
> On a rare occasion, I've had to use a slightly larger hammer than
> logout/login, which is to remove (or rename) the following files:
> ~/.go-cookies
> ~/.local/share/juju/store-usso-token
>
> That should force a fresh re-auth.
>
> Cheers,
>
> Ryan
>
>
>
> On Mon, Feb 6, 2017 at 5:38 PM, Tom Barber <t...@spicule.co.uk> wrote:
>
>> Hi folks
>>
>> For whatever reason
>>
>> charm whoami
>>
>> has decided it wont see my own membership of my own LP team even though
>> LP lists me as the owner:
>> https://launchpad.net/~spiculecharms/+members
>>
>> This prevents me pushing charms to the charm store for a reason I can't
>> fathom.
>>
>> I did some work with Cory and did the usual logout and in on
>> jujucharms.com and charm login, but none of them brought my group
>> membership back.
>>
>> So where have I messed up?
>>
>>
>>
>> --
>> Tom Barber
>> CTO Spicule LTD
>> t...@spicule.co.uk
>>
>> http://spicule.co.uk
>>
>> @spiculeim <http://twitter.com/spiculeim>
>>
>> Schedule a meeting with me <http://meetme.so/spicule>
>>
>> GB: +44(0)5603641316 <+44%2056%200364%201316>
>> US: +18448141689 <(844)%20814-1689>
>>
>> <https://leanpub.com/juju-cookbook>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>


-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689

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

Re: Kubernetes icon

[Tom Barber]

whilst we're on it

Why when you click spark do you end up at:
https://jujucharms.com/u/asanjar/spark/ and not cs:apache-spark or whatever
the mainline one is?

:)

Tom

On Mon, Jan 16, 2017 at 11:20 AM, John Meinel <j...@arbash-meinel.com>
wrote:

> Also, if you click the link, it tells you 404, maybe you want something
> else. It looks like it switched from being called "kubernetes" to being
> called "kubernetes-core", and the quick link didn't get updated.
>
> John
> =:->
>
>
> On Mon, Jan 16, 2017 at 3:17 PM, Anthony Dillon <
> anthony.dil...@canonical.com> wrote:
>
>> Thanks Tom,
>>
>> A fix for the broken link has landed a few days ago. Therefore will be
>> fixed with the next release.
>>
>> All the best,
>> Ant.
>>
>> On Mon, 16 Jan 2017 at 10:40 Tom Barber <t...@spicule.co.uk> wrote:
>>
>>> Canonical-ers,
>>>
>>> Has anyone clocked the k8s icon in the search box on jujucharms.com has
>>> been broken for about 2 months?
>>>
>>> Tom
>>>
>>> --
>>> Tom Barber
>>> CTO Spicule LTD
>>> t...@spicule.co.uk
>>>
>>> http://spicule.co.uk
>>>
>>> @spiculeim <http://twitter.com/spiculeim>
>>>
>>> Schedule a meeting with me <http://meetme.so/spicule>
>>>
>>> GB: +44(0)5603641316 <+44%2056%200364%201316>
>>> US: +18448141689 <(844)%20814-1689>
>>>
>>> <https://leanpub.com/juju-cookbook>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>


-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689

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

Kubernetes icon

[Tom Barber]

Canonical-ers,

Has anyone clocked the k8s icon in the search box on jujucharms.com has
been broken for about 2 months?

Tom

-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689

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

Re: Kubernetes Provider

[Tom Barber]

Same question got asked yesterday(lxd on kub). Marks answer was it's not
roadmapped but make it great and someone will make it happen.

On 3 Jan 2017 17:18, "James Beedy"  wrote:

> Is there any work currently being done out there for a kub provider? Has
> anyone looked into this yet?
> --
> 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: Getting access to config in actions

[Tom Barber]

Thanks Marco I'll have a prod about.

On Thu, Dec 29, 2016 at 5:02 PM, Marco Ceppi <marco.ce...@canonical.com>
wrote:

> Hook config is only setable by operators, not charms. If the-crawldb-uri
> isn't a config option specified in config.yaml and a value set by running
> `juju set` then the behavior you described is expected.
>
> I'd recommend using the kv module in charm-helpers to persist data between
> hooks. https://pythonhosted.org/charmhelpers/api/charmhelpers.
> core.unitdata.html
>
> Marco
>
> On Thu, Dec 29, 2016, 11:54 AM Tom Barber <t...@spicule.co.uk> wrote:
>
>> Not sure if I'm doing something stupid here or not.
>>
>> If I do something like:
>>
>>
>>   config = hookenv.config()
>>   config['the-crawldb-uri'] = 'test'# s.connection_string()
>>   print("set value is" +config['the-crawldb-uri'])
>>
>> in a reactive python charm, I want to be able to access that value in an
>> action which I seem to fail miserably on, anything config related like:
>>
>> juju run --unit sparkler/0 "config-get the-crawldb-uri"
>> or
>>
>> from charmhelpers.core import hookenv
>>
>> def main():
>> out = hookenv.config('the-crawldb-uri')
>> print("uri is "+out)
>>
>> just returns null. But if I manually set a value in a config block and
>> call config-get it returns the value, so how do I bridge that gap?
>>
>>
>>
>>
>> --
>> Tom Barber
>> CTO Spicule LTD
>> t...@spicule.co.uk
>>
>> http://spicule.co.uk
>>
>> @spiculeim <http://twitter.com/spiculeim>
>>
>> Schedule a meeting with me <http://meetme.so/spicule>
>>
>> GB: +44(0)5603641316 <+44%2056%200364%201316>
>> US: +18448141689 <(844)%20814-1689>
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>> mailman/listinfo/juju
>>
>


-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Getting access to config in actions

[Tom Barber]

Not sure if I'm doing something stupid here or not.

If I do something like:


  config = hookenv.config()
  config['the-crawldb-uri'] = 'test'# s.connection_string()
  print("set value is" +config['the-crawldb-uri'])

in a reactive python charm, I want to be able to access that value in an
action which I seem to fail miserably on, anything config related like:

juju run --unit sparkler/0 "config-get the-crawldb-uri"
or

from charmhelpers.core import hookenv

def main():
out = hookenv.config('the-crawldb-uri')
print("uri is "+out)

just returns null. But if I manually set a value in a config block and call
config-get it returns the value, so how do I bridge that gap?




-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim <http://twitter.com/spiculeim>

Schedule a meeting with me <http://meetme.so/spicule>

GB: +44(0)5603641316
US: +18448141689
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Upgrading multiseries Charm

[Tom Barber]

I have to say, I update local multiseries charms all the time and do see
that, so its certainly a bit odd.

On Thu, Dec 8, 2016 at 7:46 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Ok.
>
> And what about deployment of a multiseries charm? It seems to me that it
> should use the `default-series` of the model if the charm supports it. The
> order in `metadata.yaml` should only be used as a last resort..
>
> 2016-12-08 14:41 GMT-05:00 Rick Harding <rick.hard...@canonical.com>:
>
>> Oops sorry. It's what I get for replying while out. So the series in
>> metadata.yaml is ordered by preferred series. However, you're completely
>> correct that upgrade should not be attempting to upgrade across series with
>> an upgrade charm. We'll look into this and file a bug as soon as we
>> replicate.
>>
>> On Thu, Dec 8, 2016, 8:37 PM Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> That seems like strange behavior. I would expect that the following for
>>> multiseries charms:
>>>
>>> - For upgrading, use the series of the deployed application. If that
>>> series is not supported by the "new" charm, throw an error. The error can
>>> be overridden with `--force-series`. (as stated in the help docs.)
>>> - For deploying, use the `default-series` (This is NOT the case, and this
>>> is definitely a bug according to the docs
>>> <https://jujucharms.com/docs/2.0/models-config#list-of-model-keys>.)
>>>
>>>
>>> In general, for multiseries charms, the following order seems the most
>>> logical to me:
>>> Application to upgrade > default-series > order of series in
>>> metadata.yaml
>>>
>>>
>>> Also note that it's not possible to specify a series manually with
>>> `upgrade-charm`. The command doesn't recognize the `--series` flag.
>>>
>>> 2016-12-08 14:20 GMT-05:00 Rick Harding <rick.hard...@canonical.com>:
>>>
>>> Trusty is listed first. Order counts for the series list.
>>>
>>> On Thu, Dec 8, 2016, 6:25 PM Merlijn Sebrechts <
>>> merlijn.sebrec...@gmail.com> wrote:
>>>
>>> Hi
>>>
>>>
>>> I'm having trouble upgrading a multiseries charm.
>>>
>>>
>>> merlijn@travers:~$ juju status
>>> ModelController  Cloud/Region  Version
>>> merlijntest  sojobo  tengumaas 2.0.1
>>>
>>> App  Version  Status  Scale  CharmStore   Rev  OS  Notes
>>> openvpn   active  1  openvpn  jujucharms4  ubuntu
>>>
>>> UnitWorkload  Agent  Machine  Public address   PortsMessage
>>> openvpn/1*  activeidle   10   193.190.127.152  443/tcp  Ready
>>>
>>> Machine  StateDNS  Inst id  Series  AZ
>>> 10   started  193.190.127.152  4y3h7y   xenial  default
>>>
>>> merlijn@travers:~$ juju upgrade-charm openvpn --path
>>> $JUJU_REPOSITORY/builds/openvpn
>>> Added charm "local:trusty/openvpn-16" to the model.
>>> ERROR cannot upgrade application "openvpn" to charm
>>> "local:trusty/openvpn-16": cannot change an application's series
>>>
>>>
>>> Metadata.yaml:
>>>
>>> "series": ["trusty", "xenial"]
>>>
>>>
>>> I have no idea why he thinks I want to upgrade to trusty...
>>>
>>>
>>>
>>> Kind regards
>>> Merlijn
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>


-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

GB: +44(0)5603641316
US: +18448141689
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Upgrading multiseries Charm

[Tom Barber]

eh? you've lost me entirety

On 8 Dec 2016 19:20, "Rick Harding"  wrote:

> Trusty is listed first. Order counts for the series list.
>
> On Thu, Dec 8, 2016, 6:25 PM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Hi
>>
>>
>> I'm having trouble upgrading a multiseries charm.
>>
>>
>> merlijn@travers:~$ juju status
>> ModelController  Cloud/Region  Version
>> merlijntest  sojobo  tengumaas 2.0.1
>>
>> App  Version  Status  Scale  CharmStore   Rev  OS  Notes
>> openvpn   active  1  openvpn  jujucharms4  ubuntu
>>
>> UnitWorkload  Agent  Machine  Public address   PortsMessage
>> openvpn/1*  activeidle   10   193.190.127.152  443/tcp  Ready
>>
>> Machine  StateDNS  Inst id  Series  AZ
>> 10   started  193.190.127.152  4y3h7y   xenial  default
>>
>> merlijn@travers:~$ juju upgrade-charm openvpn --path
>> $JUJU_REPOSITORY/builds/openvpn
>> Added charm "local:trusty/openvpn-16" to the model.
>> ERROR cannot upgrade application "openvpn" to charm
>> "local:trusty/openvpn-16": cannot change an application's series
>>
>>
>> Metadata.yaml:
>>
>> "series": ["trusty", "xenial"]
>>
>>
>> I have no idea why he thinks I want to upgrade to trusty...
>>
>>
>>
>> Kind regards
>> Merlijn
>> --
>> 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: Juju & Mesos

[Tom Barber]

Okay, it transpires some of my Java guys also know C  who knew.

Anyway, they have been tasked with adding LXC/LXD support to Apache Mesos
which we'll push upstream assuming they want it. My plan is to then extend
Marathon to support LXD deployments and from that we'll then build a Juju
provider for Juju 2 to do juju deploy to Mesos. who knows what pitfalls
lie ahead but work has begun!.

Tom

On Fri, Nov 18, 2016 at 3:31 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> 2016-11-18 15:43 GMT+01:00 Tom Barber <t...@spicule.co.uk>:
>
>> You mention stateless, thats fine, but for example, if you have sessions
>> in a web app, you'd need to share the sessions etc, so autoscaling isn't
>> really any different to juju add-unit except you've got some stuff to
>> monitor load and do it without user intervention. Also you'll find the flip
>> side to the autoscaling argument where nodes could shutdown mid flow or
>> ditch sessions etc, so whilst Im sure in a lot of places it works great,
>> you still have to create containers that work properly in a scaling
>> environment, which is exactly the same as when you design charms :)
>>
>>
> Yes! Kubernetes autoscaling only works for stateless services. These
> services should connect to an external datastore if they want stuff like
> sessions.
>
> Applications that aren't "cloud-native" can't be autoscaled by Kubernetes
> because they require more than "spin up another service and connect it to
> the load balancer and the datastore". They need more complex configuration;
> configuration that Juju is great at! Kubernetes is great at scheduling,
> Juju is great at orchestration. Hence Juju + K8s = goodness.
>
>
>> I agree with the image stuff to some extent, certainly I've used that as
>> a selling point, the flip side of course is, do you run apt-get update when
>> you start a container? Maybe, but most people won't, what about the latest
>> security flaws in applications that will go unpatched? It also makes for
>> complacency .
>>
>>
> The sane way to use Docker is to build the image as part of a CI/CD
> pipeline. Dev triggers a rebuild when code changes, ops triggers a rebuild
> to fix security issues. After a rebuild, the ci system tests the image
> heavily. If all tests succeed, the image gets deployed to production and
> you are 100% sure that all prod images will be 100% what you just tested.
> Reproducability so that wat runs in production is exactly what is tested.
>
> Although many people think that Docker means "what the dev runs on his
> machine is what runs in production" which is obviously a bad idea and no
> technology will fix that.
>
> Of course I agree, plenty of large businesses do run their stuff in
>> docker, I use docker in production, I'm not saying don't use docker :) I'm
>> just saying that in reality its not the panacea a lot of people who want to
>> do high volume scale out apps think it is, not without writing a lot of
>> code around it for your own solution :)
>>
>> On Fri, Nov 18, 2016 at 2:34 PM, Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> I'm mostly working with researchers and people developing early
>>> prototypes. I can't blame them for using technologies that aren't
>>> production ready. That said, I attended pragmatic docker days a while back
>>> and there were some companies, like Yelp, who found a good way to run
>>> Docker in production so it is possible, given you have a boatload of good
>>> ops people.
>>>
>>> Big Data Europe <https://www.big-data-europe.eu/> seems to be going
>>> towards Docker containers for scalable Hadoop setups
>>> <https://www.big-data-europe.eu/scalable-sparkhdfs-workbench-using-docker/>.
>>> Not that it's a production ready setup, but with a name like that and H2020
>>> funding, we (big data researchers) can't really ignore them...
>>>
>>> Juju is awesome for us (big data researchers) because we have a bunch of
>>> short-lived projects that use Hadoop etc. in a bunch of different setups,
>>> and
>>>
>>>1. we don't want to be writing a new wrapper around the Hadoop chef
>>>cookbook for every project;
>>>2. we don't want to be creating a new "Hadoop + X" Docker container
>>>for every setup.
>>>
>>> However, we can't ignore the advantages of Docker vs Juju:
>>>
>>>1. image-based so the same setup is 100% reproducible if you have
>>>the image;
>>>2. auto scaling and failure recovery.
>>>
>>> 

Re: Juju & Mesos

[Tom Barber]

You mention stateless, thats fine, but for example, if you have sessions in
a web app, you'd need to share the sessions etc, so autoscaling isn't
really any different to juju add-unit except you've got some stuff to
monitor load and do it without user intervention. Also you'll find the flip
side to the autoscaling argument where nodes could shutdown mid flow or
ditch sessions etc, so whilst Im sure in a lot of places it works great,
you still have to create containers that work properly in a scaling
environment, which is exactly the same as when you design charms :)

I agree with the image stuff to some extent, certainly I've used that as a
selling point, the flip side of course is, do you run apt-get update when
you start a container? Maybe, but most people won't, what about the latest
security flaws in applications that will go unpatched? It also makes for
complacency .

Of course I agree, plenty of large businesses do run their stuff in docker,
I use docker in production, I'm not saying don't use docker :) I'm just
saying that in reality its not the panacea a lot of people who want to do
high volume scale out apps think it is, not without writing a lot of code
around it for your own solution :)

On Fri, Nov 18, 2016 at 2:34 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> I'm mostly working with researchers and people developing early
> prototypes. I can't blame them for using technologies that aren't
> production ready. That said, I attended pragmatic docker days a while back
> and there were some companies, like Yelp, who found a good way to run
> Docker in production so it is possible, given you have a boatload of good
> ops people.
>
> Big Data Europe <https://www.big-data-europe.eu/> seems to be going
> towards Docker containers for scalable Hadoop setups
> <https://www.big-data-europe.eu/scalable-sparkhdfs-workbench-using-docker/>.
> Not that it's a production ready setup, but with a name like that and H2020
> funding, we (big data researchers) can't really ignore them...
>
> Juju is awesome for us (big data researchers) because we have a bunch of
> short-lived projects that use Hadoop etc. in a bunch of different setups,
> and
>
>1. we don't want to be writing a new wrapper around the Hadoop chef
>cookbook for every project;
>2. we don't want to be creating a new "Hadoop + X" Docker container
>for every setup.
>
> However, we can't ignore the advantages of Docker vs Juju:
>
>1. image-based so the same setup is 100% reproducible if you have the
>image;
>2. auto scaling and failure recovery.
>
> So we want the stateless, auto-scalable, auto-recoverable images from
> Docker and we want Juju's relations and automatic configuration. So how to
> we get docker containers that can be configured at run-time by Juju? Ben is
> working on something to configure containers
> <https://github.com/bcsaller/layercake>, but afaik, no integration with
> Juju planned.
>
> PS: We're interested in Mesos but, as always, our time-to-put-into-it is
> limited..
>
>
>
> 2016-11-18 12:27 GMT+01:00 Tom Barber <t...@spicule.co.uk>:
>
>> I'll fork this so we're not hijacking another thread.
>>
>> Mesos runs Mesos tasks via frameworks or Docker/Rocket containers
>> currently. Annoyingly they used to have a scriptable container endpoint I
>> was hoping to knock up a POC against but they removed it, and my C is
>> woeful so implementing it will take some time. I also asked on the Mesos
>> mailing lists and they couldn't grok the use case, apparently docker does
>> everything anyone needs ;)
>>
>> When I was at the Pentaho meetup last week, there's already a bunch of
>> data folk who run DC/OS or Mesos to manage their workloads which sorta
>> validated my use case as prior to that it was only theoretical.
>>
>> There are certainly a bunch of useful docker containers, I wouldn't deny
>> that for a second, but the docker reality in production is often a lot like
>> the Big Data stuff a few years back, it works but does it work well enough.
>> In some places certainly, but in others not so much. We make a lot of use
>> of Docker recently on some NASA projects, but I'm under no illusions that
>> in reality Juju running containers would be a much improved plan, but they
>> already have Mesos etc running so why upset the apple cart? Similarly at
>> ApacheCon we had developers praising Docker and Systems Administrators
>> saying its the bane of their life.
>>
>> That said, you don't really see people spin up a scalable hadoop setup in
>> Docker because it would be annoying to maintain, but you could easily do
>> that in Juju on whatever, or Puppet etc. Of course you can do it

Re: Juju & Mesos

[Tom Barber]

Oh also, if you ran your workloads on Mesos, you could mix LXC and Docker.
I guess people could add LXC support to K8S for the same outcome, either
way having a provider that could cope with that would be awesome.

On Fri, Nov 18, 2016 at 11:27 AM, Tom Barber <t...@spicule.co.uk> wrote:

> I'll fork this so we're not hijacking another thread.
>
> Mesos runs Mesos tasks via frameworks or Docker/Rocket containers
> currently. Annoyingly they used to have a scriptable container endpoint I
> was hoping to knock up a POC against but they removed it, and my C is
> woeful so implementing it will take some time. I also asked on the Mesos
> mailing lists and they couldn't grok the use case, apparently docker does
> everything anyone needs ;)
>
> When I was at the Pentaho meetup last week, there's already a bunch of
> data folk who run DC/OS or Mesos to manage their workloads which sorta
> validated my use case as prior to that it was only theoretical.
>
> There are certainly a bunch of useful docker containers, I wouldn't deny
> that for a second, but the docker reality in production is often a lot like
> the Big Data stuff a few years back, it works but does it work well enough.
> In some places certainly, but in others not so much. We make a lot of use
> of Docker recently on some NASA projects, but I'm under no illusions that
> in reality Juju running containers would be a much improved plan, but they
> already have Mesos etc running so why upset the apple cart? Similarly at
> ApacheCon we had developers praising Docker and Systems Administrators
> saying its the bane of their life.
>
> That said, you don't really see people spin up a scalable hadoop setup in
> Docker because it would be annoying to maintain, but you could easily do
> that in Juju on whatever, or Puppet etc. Of course you can do it, and it
> will become more common over time especially with k8s auto scaling etc for
> sure.
>
> Who said Mesos or DC/OS providers and charms wouldn't get official
> support? That said currently we're just lacking bandwidth to build them(I
> speak entirely as an impartial observer I have no real idea if they'd get
> Canonical support, but why not?) ;)
>
> Tom
>
> On Fri, Nov 18, 2016 at 9:59 AM, Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Wait, wouldn't this require juju to have an "mesos" provider, so juju can
>> request lxc containers from mesos? I've heard something like this mentioned
>> at the Summit, will this become a reality? [that would be awesome!]
>>
>> We want support for Docker containers because:
>>  - A lot devs we work with create their prototypes in docker
>>  - There are a bunch of useful docker containers with stuff that isn't
>> charmed yet
>>
>> We want Kubernetes because:
>>  - Auto scaling
>>  - Auto failure recovery
>>  - It has a future beyond Docker
>>  - The Charms are officially supported by Canonical (hence Kubernetes >
>> Mesos)
>>
>>
>> 2016-11-18 10:41 GMT+01:00 Tom Barber <t...@spicule.co.uk>:
>>
>>> What you want Merlijn is LXC on Apache Mesos so you can provision a
>>> Mesos cluster on MAAS and then provision Juju Charms into LXC on the
>>> infinitely scalable cluster! Docker is cool but until it releases the
>>> proper orchestration stuff, it comes a poor second to deploying workloads
>>> with Juju ;)
>>>
>>> That's not a slight at the great work Adam, Chuck and co are doing, but
>>> feedback I got from people at the Pentaho User meetup last weekend and
>>> ApacheCon this week who all get 'stuck' with Docker once the convenience
>>> factor has gone away. Anyway, I digress Amazing getting proper Docker
>>> running on LXD as well.
>>>
>>> Tom
>>>
>>>
>>>


-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

GB: +44(0)5603641316
US: +18448141689
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Juju & Mesos

[Tom Barber]

I'll fork this so we're not hijacking another thread.

Mesos runs Mesos tasks via frameworks or Docker/Rocket containers
currently. Annoyingly they used to have a scriptable container endpoint I
was hoping to knock up a POC against but they removed it, and my C is
woeful so implementing it will take some time. I also asked on the Mesos
mailing lists and they couldn't grok the use case, apparently docker does
everything anyone needs ;)

When I was at the Pentaho meetup last week, there's already a bunch of data
folk who run DC/OS or Mesos to manage their workloads which sorta validated
my use case as prior to that it was only theoretical.

There are certainly a bunch of useful docker containers, I wouldn't deny
that for a second, but the docker reality in production is often a lot like
the Big Data stuff a few years back, it works but does it work well enough.
In some places certainly, but in others not so much. We make a lot of use
of Docker recently on some NASA projects, but I'm under no illusions that
in reality Juju running containers would be a much improved plan, but they
already have Mesos etc running so why upset the apple cart? Similarly at
ApacheCon we had developers praising Docker and Systems Administrators
saying its the bane of their life.

That said, you don't really see people spin up a scalable hadoop setup in
Docker because it would be annoying to maintain, but you could easily do
that in Juju on whatever, or Puppet etc. Of course you can do it, and it
will become more common over time especially with k8s auto scaling etc for
sure.

Who said Mesos or DC/OS providers and charms wouldn't get official support?
That said currently we're just lacking bandwidth to build them(I speak
entirely as an impartial observer I have no real idea if they'd get
Canonical support, but why not?) ;)

Tom

On Fri, Nov 18, 2016 at 9:59 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Wait, wouldn't this require juju to have an "mesos" provider, so juju can
> request lxc containers from mesos? I've heard something like this mentioned
> at the Summit, will this become a reality? [that would be awesome!]
>
> We want support for Docker containers because:
>  - A lot devs we work with create their prototypes in docker
>  - There are a bunch of useful docker containers with stuff that isn't
> charmed yet
>
> We want Kubernetes because:
>  - Auto scaling
>  - Auto failure recovery
>  - It has a future beyond Docker
>  - The Charms are officially supported by Canonical (hence Kubernetes >
> Mesos)
>
>
> 2016-11-18 10:41 GMT+01:00 Tom Barber <t...@spicule.co.uk>:
>
>> What you want Merlijn is LXC on Apache Mesos so you can provision a Mesos
>> cluster on MAAS and then provision Juju Charms into LXC on the infinitely
>> scalable cluster! Docker is cool but until it releases the proper
>> orchestration stuff, it comes a poor second to deploying workloads with
>> Juju ;)
>>
>> That's not a slight at the great work Adam, Chuck and co are doing, but
>> feedback I got from people at the Pentaho User meetup last weekend and
>> ApacheCon this week who all get 'stuck' with Docker once the convenience
>> factor has gone away. Anyway, I digress Amazing getting proper Docker
>> running on LXD as well.
>>
>> Tom
>>
>>
>>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: conjure-up Canonical Kubernetes in LXD

[Tom Barber]

What you want Merlijn is LXC on Apache Mesos so you can provision a Mesos
cluster on MAAS and then provision Juju Charms into LXC on the infinitely
scalable cluster! Docker is cool but until it releases the proper
orchestration stuff, it comes a poor second to deploying workloads with
Juju ;)

That's not a slight at the great work Adam, Chuck and co are doing, but
feedback I got from people at the Pentaho User meetup last weekend and
ApacheCon this week who all get 'stuck' with Docker once the convenience
factor has gone away. Anyway, I digress Amazing getting proper Docker
running on LXD as well.

Tom

On Fri, Nov 18, 2016 at 9:35 AM, Mark Shuttleworth <m...@ubuntu.com> wrote:

> On 18/11/16 09:29, Merlijn Sebrechts wrote:
> > Awesome! Does this mean that running a Kubernetes cluster in LXD
> > containers on physical MAAS machines will also work?
>
> Hehe, good question :)
>
> You would need to do some very careful network jiggling to line things
> up across a cluster, but it would be possible. And we'll make it
> out-of-the-box easy over the next six months.
>
> Mark
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>



-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

GB: +44(0)5603641316
US: +18448141689
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Removing the single point of failure

[Tom Barber]

Thanks for the update Marco.

just to make sure people understand is inference in emails is awful. I'm
not freaking out or complaining about the outage this stuff happens, more
just offering mirror support etc should it be seen as a good course of
minimising outage.

Tom

On 12 Nov 2016 17:19, "Marco Ceppi" <marco.ce...@canonical.com> wrote:

> Hey everyone,
>
> We're aware of the outage and working to bring the service back online.
> This is unfortunate, but we're in the process of getting the
> interfaces.juju.solutions site, folded into the charm store properly. This
> service has done it's job in providing the initial indexing but as we see
> today it's become integral to the operation of charm authorship and should
> be as robust as the charm store itself.
>
> To address concerns about "what if". Juju, the interfaces site, the charm
> layers, are all open source projects. While some items aren't directly
> configurable if we ever did enter a period where Canonical wasn't directly
> maintaining infrastructure for Juju and Charms the community could uphold
> these projects and elect to run them directly. Juju is a key platform to
> Canonical just as it is to you all. While outages like this may occur, we
> are iterating quickly to make sure projects like the interfaces site are
> folded into jujucharms.com and served with the same level SLA and HA as
> you've come to expect.
>
> Marco
>
> On Sat, Nov 12, 2016 at 10:44 AM Tom Barber <t...@spicule.co.uk> wrote:
>
>> I don't really think Mark is going to do one, my point is that for
>> platforms like this to survive if they depend on central services for
>> build/running etc, the services shouldn't just be maintained by a single
>> entity.
>>
>> HA sure will solve some issues but I also think that distributing
>> ownership also mitigates risk.
>>
>> On 12 Nov 2016 16:39, "James Beedy" <jamesbe...@gmail.com> wrote:
>>
>> Here's something thats been troubling me for a while, Canonical are the
>> single point of failure with juju. For example, this morning
>> interfaces.juju.solutions appears to be offline, thats not the end of the
>> world but of course I can't download layers from it.
>>
>> I entirely second this. Interfaces.juju.solutions needs to have some kind
>> of uptime guarantee, and probably need each component deployed in
>> HA/federated to ensure the uptime.
>>
>> Companies/people are building infrastructure around the charm store,
>> interfaces.juju.solutions, and juju itself, what happens when 100 entities
>> realize that their CI (or any critical infrastructure) has been down for an
>> amount of time? For many, this could stunt development and increase budget
>> expenditures.
>>
>>
>> Similarly, if Mark for whatever reason decided he couldn't be bothered
>> with
>> Juju any more and went and did something else, the users would be without
>> resource that is vital to people building stuff.
>>
>>
>> I have to disagree with you here. Mark is an amazing driver for these
>> technologies and technology communities, but they exist outside of, and
>> disparate of Mark and Canonical. While the world (as well as these
>> technologies) would undoubtedly not be same if not for Mark's
>> contribution(s), I think the idea here is that the majority of the software
>> in Canonical stack has enough wind under it to survive in the wild.
>>
>> Does mirroring capabilities exist for other people to mirror
>> interfaces.juju.solutions and can you tell juju to use another portal?
>> That
>> way, much like maven central, those of us with bandwidth could mirror
>> resources that are vital for smooth running of Juju operations.
>>
>> True, mirroring would be huge, but shouldn't be a solution . We
>> should deploy the site across multiple az/regions if you ask me :-)
>>
>>
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>> 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: Removing the single point of failure

[Tom Barber]

I don't really think Mark is going to do one, my point is that for
platforms like this to survive if they depend on central services for
build/running etc, the services shouldn't just be maintained by a single
entity.

HA sure will solve some issues but I also think that distributing ownership
also mitigates risk.

On 12 Nov 2016 16:39, "James Beedy"  wrote:

> Here's something thats been troubling me for a while, Canonical are the
> single point of failure with juju. For example, this morning
> interfaces.juju.solutions appears to be offline, thats not the end of the
> world but of course I can't download layers from it.
>
> I entirely second this. Interfaces.juju.solutions needs to have some kind
> of uptime guarantee, and probably need each component deployed in
> HA/federated to ensure the uptime.
>
> Companies/people are building infrastructure around the charm store,
> interfaces.juju.solutions, and juju itself, what happens when 100 entities
> realize that their CI (or any critical infrastructure) has been down for an
> amount of time? For many, this could stunt development and increase budget
> expenditures.
>
>
> Similarly, if Mark for whatever reason decided he couldn't be bothered with
> Juju any more and went and did something else, the users would be without
> resource that is vital to people building stuff.
>
>
> I have to disagree with you here. Mark is an amazing driver for these
> technologies and technology communities, but they exist outside of, and
> disparate of Mark and Canonical. While the world (as well as these
> technologies) would undoubtedly not be same if not for Mark's
> contribution(s), I think the idea here is that the majority of the software
> in Canonical stack has enough wind under it to survive in the wild.
>
> Does mirroring capabilities exist for other people to mirror
> interfaces.juju.solutions and can you tell juju to use another portal? That
> way, much like maven central, those of us with bandwidth could mirror
> resources that are vital for smooth running of Juju operations.
>
> True, mirroring would be huge, but shouldn't be a solution . We should
> deploy the site across multiple az/regions if you ask me :-)
>
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Removing the single point of failure

[Tom Barber]

Here's something thats been troubling me for a while, Canonical are the
single point of failure with juju. For example, this morning
interfaces.juju.solutions appears to be offline, thats not the end of the
world but of course I can't download layers from it.

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

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

-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

GB: +44(0)5603641316
US: +18448141689
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: How to reproduce the same build output binaries?

[Tom Barber]

I made the comparison yesterday of interfaces.juju.solutions performing a
similar role to maven central and providing artifact versions to releases
that ask for that release.

On 4 Nov 2016 08:12, "Konstantinos Tsakalozos" 
wrote:

> Indeed, layer and interface versioning should please some release
> managers.
>
> Thanks,
> Konstantinos
>
> On Thu, Nov 3, 2016 at 5:53 PM, Ryan Beisner 
> wrote:
>
>> As far as I know, there is no notion of a stable Layer or a stable
>> Interface.  That makes it difficult to carry any layered charm as "stable,"
>> and quite awkward to cherry-pick and backport fixes to stable charms which
>> depend on Layers and Interfaces.
>>
>> As you mention, you could synthesize stability (or point-in-time) by
>> branching, forking repos, but I think Layers and Interfaces should
>> ultimately grow proper versioning semantics.
>>
>> Cheers,
>>
>> Ryan
>>
>>
>> On Thu, Nov 3, 2016 at 4:31 AM, Konstantinos Tsakalozos <
>> kos.tsakalo...@canonical.com> wrote:
>>
>>> Hi everyone,
>>>
>>> This is probably a question on best practises.
>>>
>>> A reasonable ask for a build process is to be able to reproduce the same
>>> output artifacts from a certain point in time. For example, I would like to
>>> be able to rebuild the same charm I build 10 minutes, or a week or a month
>>> ago. I can think of a way to do that but it involves forking the layers
>>> used and getting them locally before charm build. Is there a better way?
>>> What would you do to accommodate this requirement?
>>>
>>> Thanks,
>>> Konstantinos
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Jenkins plugin to upload charm to store?

[Tom Barber]

I'm pretty sure you can write that in 4 lines of bash at the end of the
build/test process! ;)

Sure you could write a plugin, but is it worth the effort I guess?

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 2 November 2016 at 11:01, Konstantinos Tsakalozos <
kos.tsakalo...@canonical.com> wrote:

> Hi everyone,
>
> After a successful build and (bundle)test of a charm I would like the
> output charm to be automatically uploaded to the store (edge channel for
> now). Is there a Jenkins plugin to ease the interaction with the Juju store
> (login/push/grant/release)?
>
> Thanks,
> Konstantinos
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [ANN] Updated Python Juju Client

[Tom Barber]

solicit, not illicit... unless the client is illegal?! ;)

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 1 November 2016 at 13:49, Tim Van Steenburgh <
tim.van.steenbu...@canonical.com> wrote:

> Hi everyone,
>
> We've been working on a new python client for Juju. It's still in
> development,
> but we wanted to share the first bits to illicit feedback:
> https://github.com/juju/python-libjuju
>
> Features of this library include:
>
>  * fully asynchronous - uses asyncio and async/await features of python 3.5
>  * websocket-level bindings are programmatically generated (indirectly)
> from the
>Juju golang code, ensuring full api coverage
>  * provides an OO layer which encapsulates much of the websocket api and
>provides familiar nouns and verbs (e.g. Model.deploy(),
> Application.add_unit(),
>etc.)
>
> Caveats:
>
>  * Juju 2+ only. Juju 1 support may be added in the future.
>  * Requires Python 3.5+
>  * Currently async-only. A synchronous wrapper will be provided in the
> future.
>
> If you want to try it out, take a look at the examples/ directory.
> https://github.com/juju/python-libjuju/blob/master/examples/unitrun.py is
> a
> fairly simple one that deploys a unit, runs a command on that unit, waits
> for
> and prints the results, then exits.
>
> Any and all comments, questions, and contributions are welcomed.
>
> Thanks,
>
> Tim
>
> --
> 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

Thank You!

[Tom Barber]

Hi Folks

I was meaning to write this last week but the Hilton made me loose the will
to live...

Just a quick note to say thanks to all the Canonical staff who worked so
hard prior to and during the summit in Pasadena.

It was a great pleasure to be a part of such an event where you guys work
so hard to ensure everyone feels part of the community and a larger thing,
rather than an us and them feeling.

Of course its a two way thing and some of you I'm sure would say "it
wouldn't be the same with out you guys turning up" which I guess is true,
but the platform that Canonical provides as a way to interact with
developers and knowledge experts is way better than any other commercial
scale open source project I've had the pleasure to deal with. So keep it up!

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

LDAP no op charm

[Tom Barber]

Okay so I discussed this with a few folk in Pasadena but I think its worth
documenting on the list to find out if something exists in secret, or if
there is any technical reason why I shouldn't write this.

Taking some inspiration  from  the Nagios External Master charm, it strikes
me as a good idea to have an LDAP interface and LDAP no op charm that can
allow charms to connect to external  LDAP  sources with minimal effort.

I have a long term goal to charm up openldap or whatever but in the short
term, it also strikes me that a lot of implementing companies would already
have an AD server or OpenLDAP server running somewhere that they wouldn't
want to migrate which is completely understandable. So an LDAP charm that
just tells charms the useful information like url, port, ssl, basedn,
search mask etc would be a good way to let Saiku, Gitlab, Hadoop, HTTPD etc
hook up to corporate LDAP servers to provide proper user management.
Similarly, if I was looking to setup a scalable PAAS/SAAS setup I would
want to centralise my stuff instead of having a bunch of disparate
applications.

Comments and suggestions please.

Tom
--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Proposal: display-name for charm metadata

[Tom Barber]

Yeah sounds reasonable but I would be wary of over engineering.

Tom

On 24 Sep 2016 14:59, "José Antonio Rey"  wrote:

> As long as it's an optional field, I would say this is one worth having.
> Makes it easy to follow naming guidelines.
>
> However, it would be nice for charm names to not be case sensitive. That
> way, one would be able to deploy `juju deploy mysql` or `juju deploy MySQL`
> without troubles, since when one sees the display name, its first intuition
> would be to do the latter.
>
> Jose
>
> On Sat, Sep 24, 2016, 08:51 Marco Ceppi  wrote:
>
>> Hey everyone,
>>
>> I know we're rocking towards 2.0 but this is a problem I've seen voiced a
>> few times now. To date, the `name` field in charm has always been
>> [a-z-0-9_-] where you can't end with `-#`. This makes sense, simple flat
>> names that are all lowercase make it easy to do `juju deploy wordpress`
>> instead of following branding guidelines of `juju deploy WordPress`.
>>
>> However, a lot of applications have very specific branding guidelines for
>> how their display name should be represented. Just a few for example:
>>
>> - WordPress
>> - NS1
>> - MySQL
>> - PostgreSQL
>>
>> Today, in the charmstore each is rendered as:
>>
>> - Wordpress
>> - Ns1
>> - Mysql
>> - Postgresql
>>
>> Very rarely do the display names in the charm store and the intended
>> branding of application align. I'd like to propose an optional field in the
>> charm metadata, `display-name` which would allow slightly more control over
>> charmstore display:
>>
>> ```
>> name: ns1
>> display-name: NS1
>> ```
>>
>> ```
>> name: mysql
>> display-name: MySQL
>> ```
>>
>> etc. This would lead to the store and other places across the Juju Charms
>> properties which referenced the Application, instead of the deployment
>> instructions, to use the display-name field (see attached).
>>
>> Curious opinions on this, repercussions of adding metadata fields, esp
>> for older versions of Juju, and if this is worth pursing.
>> --
>> 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: How to offer debugging help for stuck controller

[Tom Barber]

Thanks chaps, looks it, if I can get the logs I'll add them to the ticket.

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart
<http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
goal, but you can always help by sponsoring the project
<http://www.meteorite.bi/products/saiku/sponsorship>)

On 20 September 2016 at 20:15, Gregory Lutostanski <
gregory.lutostan...@canonical.com> wrote:

> In this case I think the bug in particular is: https://bugs.launchpad.net/
> juju/+bug/1566426
>
> On Tue, Sep 20, 2016 at 1:53 PM, Casey Marshall <
> casey.marsh...@canonical.com> wrote:
>
>> Hi Tom,
>> Sorry to hear you're having trouble.. I think there might be something
>> interesting in the controller logs that could help us fix it.
>>
>> If you can ssh into the controller machine, could you tar up the logs in
>> /var/log/juju and attach to a Launchpad bug (
>> https://bugs.launchpad.net/juju/+filebug)?
>>
>> Thanks,
>> Casey
>>
>> On Tue, Sep 20, 2016 at 12:23 PM, Tom Barber <t...@analytical-labs.com>
>> wrote:
>>
>>> Hi folks
>>>
>>> I have a controller on CDP thats stuck with 4 running units and 8
>>> pending.
>>>
>>> I can't destroy it or kill it, which strikes me as a bug but I don't
>>> know what I can provide to help you guys fathom it out.
>>>
>>> Obviously its still running as I can't kill it, so let me know what I
>>> can offer up to help you resolve it.
>>>
>>> Tom
>>> --
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
>>> goal, but you can always help by sponsoring the project
>>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

How to offer debugging help for stuck controller

[Tom Barber]

Hi folks

I have a controller on CDP thats stuck with 4 running units and 8 pending.

I can't destroy it or kill it, which strikes me as a bug but I don't know
what I can provide to help you guys fathom it out.

Obviously its still running as I can't kill it, so let me know what I can
offer up to help you resolve it.

Tom
--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju client now works properly on all Linuxes

[Tom Barber]

Indeed ramp up the american Marco ramp it up! ;)

On a more mundane note, that is very good news.

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 16 September 2016 at 04:21, Marco Ceppi 
wrote:

> This is FANTASTIC news for those using the Snap!
>
> On Thu, Sep 15, 2016 at 10:53 PM Rick Harding 
> wrote:
>
>> Thanks Menno, this is great stuff.
>>
>> On Thu, Sep 15, 2016, 10:35 PM Menno Smits 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> This is just a quick heads up about an improvement that will be in Juju
>>> 2.0 rc1.
>>>
>>> The Juju client has never really worked on flavours of Linux which we
>>> hadn't explicitly added support for (i.e. Ubuntu and Centos). This has now
>>> been fixed: the client will work on any Linux distribution. This has been
>>> tested with Fedora, Debian and Arch.
>>>
>>> Additionally, when using local Juju binaries (i.e. a juju and jujud
>>> which you've built yourself or someone has sent you), checks have been
>>> relaxed allowing a Juju client running on any Linux flavour to bootstrap a
>>> controller running any of the supported Ubuntu series. Previously it wasn't
>>> possible for a client not running a non-Ubuntu distribution to bootstrap a
>>> Juju controller using local Juju binaries.
>>>
>>> Please ask if anything about this is unclear.
>>>
>>> - 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
>>
>
> --
> 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: Deploying Xenial charms in LXD? Read this

[Tom Barber]

Yeah I hit something like this on EC2 last night.

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 8 September 2016 at 14:28, Andrew Wilkins 
wrote:

> On Thu, Sep 8, 2016 at 9:23 PM Marco Ceppi 
> wrote:
>
>> Hey everyone,
>>
>> An issue was identified late yesterday for those deploying Xenial charms
>> to either the LXD provider or LXD instances in a cloud.
>>
>> The symptoms for this manifest as the LXD machine running is in a running
>> state (and has an IP address assigned) but the agent does not start. This
>> leaves the workload permanently stuck in a "Waiting for agent to
>> initialize" state. This problem originates from a problem in cloud-init and
>> systemd, being triggered by an update to the snapd package for xenial.
>>
>
> FYI this is not LXD-specific. I've just now seen the same thing happen on
> Azure.
>
> Thanks to James Beedy, from the community, for posting this workaround
>> which appears to be working consistently for the moment:
>>
>> juju set-model-config enable-os-refresh-update=false
>> juju set-model-config enable-os-upgrade=false
>>
>>
>> This should bypass the section of the cloud-init process that's causing
>> the hang at the moment. For those interested in tracking the bugs I believe
>> these are the two related ones for this problem:
>>
>> - https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1621229
>> - https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1576692
>>
>> I'll make sure to post an update when this has been resolved.
>>
>> Thanks,
>> Marco Ceppi
>> --
>> canonical-juju mailing list
>> canonical-j...@lists.canonical.com
>> Modify settings or unsubscribe at: https://lists.canonical.com/
>> mailman/listinfo/canonical-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: kill-controller, unregister, destroy-controller

[Tom Barber]

If you have models it just doesn't work. so it's actually more "life
support" than slow death

On 1 Sep 2016 15:05, "Marco Ceppi"  wrote:

> On Thu, Sep 1, 2016 at 9:59 AM Mark Ramm-Christensen (Canonical.com) <
> mark.ramm-christen...@canonical.com> wrote:
>
>> I believe keeping the --destroy-all-models flag is helpful in keeping
>> you from accidentally destroying a controller that is hosting important
>> models for someone without thinking.
>>
>
> What happens if I destroy-controller without that flag? Do I have to go
> into my cloud portal to kill those instances? Is there any way to recover
> from that to get juju reconnected? If not, it's just a slower death.
>
>
>> On Thu, Sep 1, 2016 at 3:40 PM, Marco Ceppi 
>> wrote:
>>
>>> Hey everyone,
>>>
>>> I know we've had discussions about this over the past few months, but it
>>> seems we have three commands that overlap pretty aggressively.
>>>
>>> Using Juju beta16, and trying to 'destroy' a controller it looks like
>>> this now:
>>>
>>> ```
>>> root@ubuntu:~# juju help destroy-controller
>>> Usage: juju destroy-controller [options] 
>>>
>>> ...
>>>
>>> Details:
>>> All models (initial model plus all workload/hosted) associated with the
>>> controller will first need to be destroyed, either in advance, or by
>>> specifying `--destroy-all-models`.
>>>
>>> Examples:
>>> juju destroy-controller --destroy-all-models mycontroller
>>>
>>> See also:
>>> kill-controller
>>> unregister
>>> ```
>>>
>>> When would you ever want to destroy-controller and not
>>> destroy-all-models? I have to specify that flag everytime, it seems it
>>> should just be the default behavior. Kill-controller seems to do what
>>> destroy-controller --destroy-all-models does but more aggressively?
>>>
>>> Finally, unregister and destroy-controller (without
>>> --destroy-all-models) does the same thing. Can we consider dropping the -
>>> very long winded almost always required - flag for destroy-controller?
>>>
>>> Finally, there used to be a pretty good amount of feedback during
>>> destroy-controller, while it was rolling text, I at least knew what was
>>> happening. Now it's virtually silent. Given it runs for quite a long time,
>>> can we get some form of feedback to the user back into the command?
>>>
>>> ```
>>> root@ubuntu:~# juju destroy-controller --destroy-all-models cabs
>>> WARNING! This command will destroy the "cabs" controller.
>>> This includes all machines, applications, data and other resources.
>>>
>>> Continue? (y/N):y
>>> ERROR failed to destroy controller "cabs"
>>>
>>> If the controller is unusable, then you may run
>>>
>>> juju kill-controller
>>>
>>> to forcibly destroy the controller. Upon doing so, review
>>> your cloud provider console for any resources that need
>>> to be cleaned up.
>>>
>>> ERROR cannot connect to API: unable to connect to API: websocket.Dial
>>> wss://10.0.0.4:17070/api: dial tcp 10.0.0.4:17070: getsockopt: no route
>>> to host
>>> root@ubuntu:~# juju kill-controller cabs
>>> WARNING! This command will destroy the "cabs" controller.
>>> This includes all machines, applications, data and other resources.
>>>
>>> Continue? (y/N):y
>>> Unable to open API: open connection timed out
>>> Unable to connect to the API server. Destroying through provider.
>>> ERROR listing resource groups: azure.ServicePrincipalToken#Refresh:
>>> Failure sending request for Service Principal 
>>> 83d638b0-841c-4bd1-9e7c-868cae3393f4:
>>> StatusCode=0 -- Original Error: http: nil Request.URL
>>> root@ubuntu:~# juju bootstrap cabs azure
>>> ERROR controller "cabs" already exists
>>> ```
>>>
>>> Marco
>>>
>>> --
>>> Juju-dev mailing list
>>> juju-...@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>>> mailman/listinfo/juju-dev
>>>
>>>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Supported LXD Providers

[Tom Barber]

Didn't know about AWS routing, interesting Rick! Although James is using
AWS afaik so maybe its regressed there.

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart
<http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
goal, but you can always help by sponsoring the project
<http://www.meteorite.bi/products/saiku/sponsorship>)

On 23 August 2016 at 14:45, Rick Harding <rick.hard...@canonical.com> wrote:

> That looks like something interesting. :)
>
> Yes, the engineering team is working on adapting the Fan to public clouds
> as a first go at making sure containers can be routable ootb when using
> Juju. We'll just recently had a sprint scoping it out and see this as the
> solution to the problem your running into.
>
> As you note, in cases where the containers can get dhcp addresses on the
> same network as the hosts, it's not an issue. OpenStack (depending on
> config) and MAAS work this way and aren't an issue.
>
> At one point we had lxc container networking in AWS. I'm just
> bootstrapping to verify that this is still working properly in the latest
> 2.0 code and if not will file a bug that we've regressed in this.
>
> tl;dr
> containers should work with routing ootb on MAAS, OpenStack, and AWS. The
> team's working on leveraging the Fan for public clouds and other
> situations.
>
> On Tue, Aug 23, 2016 at 9:26 AM Tom Barber <t...@analytical-labs.com>
> wrote:
>
>> Possibly something like... https://wiki.ubuntu.com/FanNetworking ? :)
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
>> goal, but you can always help by sponsoring the project
>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>
>> On 23 August 2016 at 14:23, James Beedy <jamesbe...@gmail.com> wrote:
>>
>>> Mark,
>>>
>>> Thanks for the reply! Just to make sure I'm picking up what you are
>>> laying down, are you implying that Juju will soon support host <-> host
>>> container networking by supplying its own provider agnostic network fabric?
>>>
>>> ~James
>>>
>>> On Aug 23, 2016, at 4:29 AM, Mark Shuttleworth <m...@ubuntu.com> wrote:
>>>
>>>
>>> LXC/LXD should work everywhere, but *networking* to those containers is
>>> tricky. There is a dedicated team working on that problem, and we expect to
>>> ahve the ability to make and use LXC containers universally, soon.
>>>
>>> The remaining constraint will be that some charms try to modify their
>>> guest kernel, and that of course will be prevented in a container.
>>>
>>> Mark
>>>
>>> On 22/08/16 22:03, James Beedy wrote:
>>>
>>> Team,
>>>
>>> Question: What providers can Juju deploy LXD to?
>>>
>>> Answer: All of them.
>>>
>>> Question: What providers support Juju deployed LXD (juju deploy
>>>  --to lxd:0)?
>>>
>>> Answer: MAAS
>>>
>>>
>>> Problem: Juju can deploy LXD to all of the providers, but Juju can
>>> **REALLY** only provision LXD on MAAS. I get the impression that Juju is
>>> broken when I deploy applications to lxd on any provider other than MAAS.
>>>
>>> Proposed Solution: Disable `juju deploy  --to lxd:0` on
>>> providers which it is not supported.
>>>
>>>
>>> Thoughts?
>>>
>>>
>>>
>>>
>>> --
>>> 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: Supported LXD Providers

[Tom Barber]

Yeah I know what you're getting at James. I've certainly discussed it with
a few of the developers when LXD Local first came out, although I forget
who now.

I guess what we're after is similar to Docker networking via Swam and their
overlay net. Which I believe is similar to Canonical Fan Network In Swam of
course you can define a bunch of containers and tell them to deploy across
a bunch of hosts and the overlay network takes care of it all, which of
course is currently inoperable in LXD via Juju.

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart
<http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
goal, but you can always help by sponsoring the project
<http://www.meteorite.bi/products/saiku/sponsorship>)

On 23 August 2016 at 14:33, James Beedy <jamesbe...@gmail.com> wrote:

> Tom,
>
> I think what I'm looking for here is consistency. Even using the lxd
> provider, you can't 'juju deploy myapp0 --to lxd:0' and 'juju deploy myapp1
> --to lxd:1'; myapp0 and myapp1 will never be able to talk because the live
> on their respective host only subnet on each host. I think this would be a
> great place to make use of L3 tunnels to get from host to host. Hopefully
> this is what mark was hinting at :)
>
> On Aug 23, 2016, at 4:32 AM, Tom Barber <t...@analytical-labs.com> wrote:
>
> James is also missing LXD Local :) Saves my dev cycles all the time and of
> course networking isn't an issue. I also use LXD remotely but I just run a
> cmd that forwards the ports I want to the host via IPTables so they are
> exposed to the wide world. Of course its a manual step, but I find it very
> useful.
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
> goal, but you can always help by sponsoring the project
> <http://www.meteorite.bi/products/saiku/sponsorship>)
>
> On 23 August 2016 at 12:29, Mark Shuttleworth <m...@ubuntu.com> wrote:
>
>>
>> LXC/LXD should work everywhere, but *networking* to those containers is
>> tricky. There is a dedicated team working on that problem, and we expect to
>> ahve the ability to make and use LXC containers universally, soon.
>>
>> The remaining constraint will be that some charms try to modify their
>> guest kernel, and that of course will be prevented in a container.
>>
>> Mark
>>
>>
>> On 22/08/16 22:03, James Beedy wrote:
>>
>> Team,
>>
>> Question: What providers can Juju deploy LXD to?
>>
>> Answer: All of them.
>>
>> Question: What providers support Juju deployed LXD (juju deploy
>>  --to lxd:0)?
>>
>> Answer: MAAS
>>
>>
>> Problem: Juju can deploy LXD to all of the providers, but Juju can
>> **REALLY** only provision LXD on MAAS. I get the impression that Juju is
>> broken when I deploy applications to lxd on any provider other than MAAS.
>>
>> Proposed Solution: Disable `juju deploy  --to lxd:0` on
>> providers which it is not supported.
>>
>>
>> Thoughts?
>>
>>
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Supported LXD Providers

[Tom Barber]

Possibly something like... https://wiki.ubuntu.com/FanNetworking ? :)

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 23 August 2016 at 14:23, James Beedy  wrote:

> Mark,
>
> Thanks for the reply! Just to make sure I'm picking up what you are laying
> down, are you implying that Juju will soon support host <-> host container
> networking by supplying its own provider agnostic network fabric?
>
> ~James
>
> On Aug 23, 2016, at 4:29 AM, Mark Shuttleworth  wrote:
>
>
> LXC/LXD should work everywhere, but *networking* to those containers is
> tricky. There is a dedicated team working on that problem, and we expect to
> ahve the ability to make and use LXC containers universally, soon.
>
> The remaining constraint will be that some charms try to modify their
> guest kernel, and that of course will be prevented in a container.
>
> Mark
>
> On 22/08/16 22:03, James Beedy wrote:
>
> Team,
>
> Question: What providers can Juju deploy LXD to?
>
> Answer: All of them.
>
> Question: What providers support Juju deployed LXD (juju deploy
>  --to lxd:0)?
>
> Answer: MAAS
>
>
> Problem: Juju can deploy LXD to all of the providers, but Juju can
> **REALLY** only provision LXD on MAAS. I get the impression that Juju is
> broken when I deploy applications to lxd on any provider other than MAAS.
>
> Proposed Solution: Disable `juju deploy  --to lxd:0` on
> providers which it is not supported.
>
>
> Thoughts?
>
>
>
>
> --
> 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: Juju as a snap

[Tom Barber]

I saw you guys discussing this on #juju the other day, great stuff! For
those of us interested, is the snap source in a repo somewhere we can take
a peak at?

Cheers

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 2 August 2016 at 22:00, Nicholas Skaggs 
wrote:

> The Juju client has been snappified and pushed to the juju store. Note for
> now it's just an amd64 build.
>
> snap install juju --beta --devmode
>
> The beta channel contains the latest beta, 2.0-beta13. This is a sneak
> preview of further builds, including the latest crack available in the edge
> channel as development happens.
>
> Note, that you will need to use juju add-credential to re-add your
> credentials for the snap -- credentials are not shared with the debian
> package. Also, should you have the debian package (from the archive or ppa)
> installed, it has priority in PATH for 'juju'. Uninstall the package, or
> run the snap directly by calling /snap/bin/juju.
>
> Feedback is welcome and appreciated! If you are running ubuntu 16.04 you
> already have snappy installed. Give it a try!
>
> Nicholas
>
>
> --
> 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: Apache Aria

[Tom Barber]

Thanks Nicolas, thats a really interesting plan!

Looking forward to find out more.

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart
<http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
goal, but you can always help by sponsoring the project
<http://www.meteorite.bi/products/saiku/sponsorship>)

On 28 July 2016 at 05:11, Nicolas Lemieux <nicolas.lemi...@canonical.com>
wrote:

> +Arthur from Gigaspaces(newly subscribed to jujulist) can provide more
> details on Aria and the potential of a juju plugin.
>
> There is also upcoming workshop regarding integration between
> http://getcloudify.org/ (as an NFV orchestrator) leveraging TOSCA for
> Topology and Workflow management with Juju charms as potential node types
> to help service orchestration(something also in scope in the
> https://www.open-o.org/ community).
>
> Nic
>
> P.S. Gigaspaces is now part of CPP..!
>
> On Jul 26, 2016, at 7:19 AM, Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
> Any idea what an integration would look like? Juju supporting TOSCA
> models? Aria driving Juju (like it does with Chef)? or something else?
>
> 2016-07-26 14:07 GMT+02:00 Nicolas Thomas <nicolas.tho...@canonical.com>:
>
>> Thanks for sharing.
>>
>> It is heavily pushed by Cloudify and we have discussions on-going for
>> integrating with them.
>>
>> I did not know they pushed for being an Apache project very useful
>> piece of information.
>>
>> Hope this helps,
>>
>>
>>
>> On Tue, Jul 26, 2016 at 11:55 AM, Merlijn Sebrechts
>> <merlijn.sebrec...@gmail.com> wrote:
>> > Thanks for sending this! I knew it existed, but I didn't know it is in
>> > Apache Incubating.
>> >
>> > 2016-07-22 20:21 GMT+02:00 Tom Barber <t...@analytical-labs.com>:
>> >>
>> >> Dunno if it's of any interest to the juju developers but this landed
>> >> recently https://wiki.apache.org/incubator/AriaProposal
>> >>
>> >> Tom
>> >>
>> >>
>> >> --
>> >> 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
>> >
>>
>>
>>
>> --
>> Best Regards,
>>Nicolas Thomas
>> http://insights.ubuntu.com/?p=889
>> EMEA Solution Architect  Canonical
>> GPG FPR: D592 4185 F099 9031 6590 6292 492F C740 F03A 7EB9
>>
>
> --
> 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

Apache Aria

[Tom Barber]

Dunno if it's of any interest to the juju developers but this landed
recently https://wiki.apache.org/incubator/AriaProposal

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

Juju & DC/OS @ Mesosphere Europe

[Tom Barber]

Just a heads up folks. I'll be presenting: Flexibility across the cloud -
Managing and scaling your High Availability DC/OS cluster using Juju. At
Mesosphere Europe in Amsterdam on the 31st August. If anyone is attending
or thinking about it, let me know!

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm push crashes when uploading big charms

[Tom Barber]

Okay bzip -9'ed it, down to 760mb and tried to attach it via my server in a
data centre... same failure.

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart
<http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
goal, but you can always help by sponsoring the project
<http://www.meteorite.bi/products/saiku/sponsorship>)

On 19 July 2016 at 07:51, Tom Barber <t...@analytical-labs.com> wrote:

> Yeah, but in life, i can ftp/sftp/http upload a file to a.n.other service
> without a timeout irrespective of size. Clearly it will take a long time on
> crappy FTTC ADSL but it does work and doesn't timeout :)
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
> goal, but you can always help by sponsoring the project
> <http://www.meteorite.bi/products/saiku/sponsorship>)
>
> On 19 July 2016 at 07:49, José Antonio Rey <j...@ubuntu.com> wrote:
>
>> Oh! Huh. Then maybe it is a size constraint :)
>>
>> On Tue, Jul 19, 2016, 01:48 Tom Barber <t...@analytical-labs.com> wrote:
>>
>>> Yeah, but you could also argue this hotel wifi is a lot quicker than my
>>> home wifi, so it still seems a bit flawed if you need to push from fast
>>> pipes! Anyway I shall try and find out.
>>>
>>> Tom
>>>
>>> --
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
>>> goal, but you can always help by sponsoring the project
>>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>>
>>> On 19 July 2016 at 07:45, José Antonio Rey <j...@ubuntu.com> wrote:
>>>
>>>> Hotel wifi may be the problem. Maybe try uploading it to a server with
>>>> a fast upload speed, and then pusing from that server instead?
>>>>
>>>> On 07/19/2016 01:33 AM, Tom Barber wrote:
>>>>
>>>>> 825mb on hotel wifi Rick, I'll squash it further  and try again on data
>>>>> centre pipes.
>>>>>
>>>>> Tom
>>>>>
>>>>> --
>>>>>
>>>>> Director Meteorite.bi - Saiku Analytics Founder
>>>>> Tel: +44(0)5603641316
>>>>>
>>>>> (Thanks to the Saiku community we reached our Kickstart
>>>>> <
>>>>> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/
>>>>> >
>>>>> goal, but you can always help by sponsoring the project
>>>>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>>>>
>>>>> On 19 July 2016 at 01:06, Rick Harding <rick.hard...@canonical.com
>>>>> <mailto:rick.hard...@canonical.com>> wrote:
>>>>>
>>>>> How big/long to upload was your resource Tom? I know the team
>>>>> bumped
>>>>> it while they get some better insight into tracking/quota'ing sizes
>>>>> and I'm curious where you got denied.
>>>>>
>>>>>
>>>>> On Mon, Jul 18, 2016, 5:53 PM Tom Barber <t...@analytical-labs.com
>>>>> <mailto:t...@analytical-labs.com>> wrote:
>>>>>
>>>>> Awww Merlijn
>>>>>
>>>>> You got my hopes up then I got the same error as usual
>>>>> *sadface*
>>>>>
>>>>> Tom
>>>>>
>>>>> --
>>>>>
>>>>> Director Meteorite.bi - Saiku Analytics Founder
>>>>> Tel: +44(0)5603641316 <tel:%2B44%280%295603641316>
>>>>>
>>>>> (Thanks to the Saiku community we reached our Kickstart
>>>>> <
>>>>> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/
>>>>> >
>>>>> goal, but you can always help by sponsoring the project
>>>>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>>>>

Re: Charm push crashes when uploading big charms

[Tom Barber]

Yeah, but in life, i can ftp/sftp/http upload a file to a.n.other service
without a timeout irrespective of size. Clearly it will take a long time on
crappy FTTC ADSL but it does work and doesn't timeout :)

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart
<http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
goal, but you can always help by sponsoring the project
<http://www.meteorite.bi/products/saiku/sponsorship>)

On 19 July 2016 at 07:49, José Antonio Rey <j...@ubuntu.com> wrote:

> Oh! Huh. Then maybe it is a size constraint :)
>
> On Tue, Jul 19, 2016, 01:48 Tom Barber <t...@analytical-labs.com> wrote:
>
>> Yeah, but you could also argue this hotel wifi is a lot quicker than my
>> home wifi, so it still seems a bit flawed if you need to push from fast
>> pipes! Anyway I shall try and find out.
>>
>> Tom
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
>> goal, but you can always help by sponsoring the project
>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>
>> On 19 July 2016 at 07:45, José Antonio Rey <j...@ubuntu.com> wrote:
>>
>>> Hotel wifi may be the problem. Maybe try uploading it to a server with a
>>> fast upload speed, and then pusing from that server instead?
>>>
>>> On 07/19/2016 01:33 AM, Tom Barber wrote:
>>>
>>>> 825mb on hotel wifi Rick, I'll squash it further  and try again on data
>>>> centre pipes.
>>>>
>>>> Tom
>>>>
>>>> --
>>>>
>>>> Director Meteorite.bi - Saiku Analytics Founder
>>>> Tel: +44(0)5603641316
>>>>
>>>> (Thanks to the Saiku community we reached our Kickstart
>>>> <
>>>> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/
>>>> >
>>>> goal, but you can always help by sponsoring the project
>>>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>>>
>>>> On 19 July 2016 at 01:06, Rick Harding <rick.hard...@canonical.com
>>>> <mailto:rick.hard...@canonical.com>> wrote:
>>>>
>>>> How big/long to upload was your resource Tom? I know the team bumped
>>>> it while they get some better insight into tracking/quota'ing sizes
>>>> and I'm curious where you got denied.
>>>>
>>>>
>>>> On Mon, Jul 18, 2016, 5:53 PM Tom Barber <t...@analytical-labs.com
>>>> <mailto:t...@analytical-labs.com>> wrote:
>>>>
>>>> Awww Merlijn
>>>>
>>>> You got my hopes up then I got the same error as usual
>>>> *sadface*
>>>>
>>>> Tom
>>>>
>>>> --
>>>>
>>>> Director Meteorite.bi - Saiku Analytics Founder
>>>> Tel: +44(0)5603641316 <tel:%2B44%280%295603641316>
>>>>
>>>> (Thanks to the Saiku community we reached our Kickstart
>>>> <
>>>> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/
>>>> >
>>>> goal, but you can always help by sponsoring the project
>>>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>>>
>>>> On 18 July 2016 at 14:39, Tom Barber <t...@analytical-labs.com
>>>> <mailto:t...@analytical-labs.com>> wrote:
>>>>
>>>> Cool thanks, I'll check it shortly.
>>>>
>>>> Tom
>>>>
>>>> --
>>>>
>>>> Director Meteorite.bi - Saiku Analytics Founder
>>>> Tel: +44(0)5603641316 <tel:%2B44%280%295603641316>
>>>>
>>>> (Thanks to the Saiku community we reached our Kickstart
>>>> <
>>>> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/
>>>> >
>>>> goal, but you can always help by sponsoring the project
>>>> <http://www.meteorite.bi/produ

Re: Charm push crashes when uploading big charms

[Tom Barber]

Yeah, but you could also argue this hotel wifi is a lot quicker than my
home wifi, so it still seems a bit flawed if you need to push from fast
pipes! Anyway I shall try and find out.

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart
<http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
goal, but you can always help by sponsoring the project
<http://www.meteorite.bi/products/saiku/sponsorship>)

On 19 July 2016 at 07:45, José Antonio Rey <j...@ubuntu.com> wrote:

> Hotel wifi may be the problem. Maybe try uploading it to a server with a
> fast upload speed, and then pusing from that server instead?
>
> On 07/19/2016 01:33 AM, Tom Barber wrote:
>
>> 825mb on hotel wifi Rick, I'll squash it further  and try again on data
>> centre pipes.
>>
>> Tom
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> <
>> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/
>> >
>> goal, but you can always help by sponsoring the project
>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>
>> On 19 July 2016 at 01:06, Rick Harding <rick.hard...@canonical.com
>> <mailto:rick.hard...@canonical.com>> wrote:
>>
>> How big/long to upload was your resource Tom? I know the team bumped
>> it while they get some better insight into tracking/quota'ing sizes
>> and I'm curious where you got denied.
>>
>>
>> On Mon, Jul 18, 2016, 5:53 PM Tom Barber <t...@analytical-labs.com
>> <mailto:t...@analytical-labs.com>> wrote:
>>
>> Awww Merlijn
>>
>> You got my hopes up then I got the same error as usual
>> *sadface*
>>
>> Tom
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316 <tel:%2B44%280%295603641316>
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> <
>> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/
>> >
>> goal, but you can always help by sponsoring the project
>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>
>> On 18 July 2016 at 14:39, Tom Barber <t...@analytical-labs.com
>> <mailto:t...@analytical-labs.com>> wrote:
>>
>> Cool thanks, I'll check it shortly.
>>
>> Tom
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316 <tel:%2B44%280%295603641316>
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> <
>> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/
>> >
>> goal, but you can always help by sponsoring the project
>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>
>> On 18 July 2016 at 14:37, Merlijn Sebrechts
>> <merlijn.sebrec...@gmail.com
>> <mailto:merlijn.sebrec...@gmail.com>> wrote:
>>
>> Hi Jay
>>
>>
>> I'm able to push a 270 mb large Charm now. This was not
>> possible before, so it seems the issue is fixed for me.
>> I've added Tom in cc so he can check too. He was having
>> the same issue if I'm not mistaken. I'll come back to
>> you if the issue magically reappears.. :)
>>
>>
>>
>> Kind regards
>> Merlijn
>>
>>
>> 2016-07-08 21:04 GMT+02:00 Jay Wren
>> <jay.w...@canonical.com <mailto:jay.w...@canonical.com>>:
>>
>> We have made a configuration change which should
>> impact this. If you are able to try again, please do
>> so.
>>
>> Also, we are continuing to track this issue and add
>> monitoring and instrumentation around this area of
>> the charmstore to be better able to respond to such
>> issues in the future.
>>
>> Thanks,
>>  

Re: Charm push crashes when uploading big charms

[Tom Barber]

825mb on hotel wifi Rick, I'll squash it further  and try again on data
centre pipes.

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart
<http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
goal, but you can always help by sponsoring the project
<http://www.meteorite.bi/products/saiku/sponsorship>)

On 19 July 2016 at 01:06, Rick Harding <rick.hard...@canonical.com> wrote:

> How big/long to upload was your resource Tom? I know the team bumped it
> while they get some better insight into tracking/quota'ing sizes and I'm
> curious where you got denied.
>
> On Mon, Jul 18, 2016, 5:53 PM Tom Barber <t...@analytical-labs.com> wrote:
>
>> Awww Merlijn
>>
>> You got my hopes up then I got the same error as usual *sadface*
>>
>> Tom
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
>> goal, but you can always help by sponsoring the project
>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>
>> On 18 July 2016 at 14:39, Tom Barber <t...@analytical-labs.com> wrote:
>>
>>> Cool thanks, I'll check it shortly.
>>>
>>> Tom
>>>
>>> --
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
>>> goal, but you can always help by sponsoring the project
>>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>>
>>> On 18 July 2016 at 14:37, Merlijn Sebrechts <merlijn.sebrec...@gmail.com
>>> > wrote:
>>>
>>>> Hi Jay
>>>>
>>>>
>>>> I'm able to push a 270 mb large Charm now. This was not possible
>>>> before, so it seems the issue is fixed for me. I've added Tom in cc so he
>>>> can check too. He was having the same issue if I'm not mistaken. I'll come
>>>> back to you if the issue magically reappears.. :)
>>>>
>>>>
>>>>
>>>> Kind regards
>>>> Merlijn
>>>>
>>>>
>>>> 2016-07-08 21:04 GMT+02:00 Jay Wren <jay.w...@canonical.com>:
>>>>
>>>>> We have made a configuration change which should impact this. If you
>>>>> are able to try again, please do so.
>>>>>
>>>>> Also, we are continuing to track this issue and add monitoring and
>>>>> instrumentation around this area of the charmstore to be better able to
>>>>> respond to such issues in the future.
>>>>>
>>>>> Thanks,
>>>>> --
>>>>> Jay
>>>>>
>>>>>
>>>>> On Wed, Jun 22, 2016 at 10:30 AM, Stuart Bishop <
>>>>> stuart.bis...@canonical.com> wrote:
>>>>>
>>>>>> On 21 June 2016 at 02:40, Jay Wren <jay.w...@canonical.com> wrote:
>>>>>> > Thanks for the further testing.
>>>>>> >
>>>>>> > Now I'm questioning how in the world I was able to see the same
>>>>>> error.
>>>>>> >
>>>>>> > I will continue my testing to attempt to reproduce the error.
>>>>>> >
>>>>>> > Also, the Apache Timeout 300 should behave exactly as Mark said.
>>>>>> I'm still
>>>>>> > trying to find what is causing this failure.
>>>>>>
>>>>>> The error from the bug report originates from Squid, which is probably
>>>>>> buffering the upload. The timeout might happen between Squid and
>>>>>> Apache if it takes to long to upload and there is no keep-alive
>>>>>> mechanism in place.
>>>>>>
>>>>>> --
>>>>>> Stuart Bishop <stuart.bis...@canonical.com>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm push crashes when uploading big charms

[Tom Barber]

Awww Merlijn

You got my hopes up then I got the same error as usual *sadface*

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart
<http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
goal, but you can always help by sponsoring the project
<http://www.meteorite.bi/products/saiku/sponsorship>)

On 18 July 2016 at 14:39, Tom Barber <t...@analytical-labs.com> wrote:

> Cool thanks, I'll check it shortly.
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
> goal, but you can always help by sponsoring the project
> <http://www.meteorite.bi/products/saiku/sponsorship>)
>
> On 18 July 2016 at 14:37, Merlijn Sebrechts <merlijn.sebrec...@gmail.com>
> wrote:
>
>> Hi Jay
>>
>>
>> I'm able to push a 270 mb large Charm now. This was not possible before,
>> so it seems the issue is fixed for me. I've added Tom in cc so he can check
>> too. He was having the same issue if I'm not mistaken. I'll come back to
>> you if the issue magically reappears.. :)
>>
>>
>>
>> Kind regards
>> Merlijn
>>
>>
>> 2016-07-08 21:04 GMT+02:00 Jay Wren <jay.w...@canonical.com>:
>>
>>> We have made a configuration change which should impact this. If you are
>>> able to try again, please do so.
>>>
>>> Also, we are continuing to track this issue and add monitoring and
>>> instrumentation around this area of the charmstore to be better able to
>>> respond to such issues in the future.
>>>
>>> Thanks,
>>> --
>>> Jay
>>>
>>>
>>> On Wed, Jun 22, 2016 at 10:30 AM, Stuart Bishop <
>>> stuart.bis...@canonical.com> wrote:
>>>
>>>> On 21 June 2016 at 02:40, Jay Wren <jay.w...@canonical.com> wrote:
>>>> > Thanks for the further testing.
>>>> >
>>>> > Now I'm questioning how in the world I was able to see the same error.
>>>> >
>>>> > I will continue my testing to attempt to reproduce the error.
>>>> >
>>>> > Also, the Apache Timeout 300 should behave exactly as Mark said. I'm
>>>> still
>>>> > trying to find what is causing this failure.
>>>>
>>>> The error from the bug report originates from Squid, which is probably
>>>> buffering the upload. The timeout might happen between Squid and
>>>> Apache if it takes to long to upload and there is no keep-alive
>>>> mechanism in place.
>>>>
>>>> --
>>>> Stuart Bishop <stuart.bis...@canonical.com>
>>>>
>>>
>>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm push crashes when uploading big charms

[Tom Barber]

Cool thanks, I'll check it shortly.

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 18 July 2016 at 14:37, Merlijn Sebrechts 
wrote:

> Hi Jay
>
>
> I'm able to push a 270 mb large Charm now. This was not possible before,
> so it seems the issue is fixed for me. I've added Tom in cc so he can check
> too. He was having the same issue if I'm not mistaken. I'll come back to
> you if the issue magically reappears.. :)
>
>
>
> Kind regards
> Merlijn
>
>
> 2016-07-08 21:04 GMT+02:00 Jay Wren :
>
>> We have made a configuration change which should impact this. If you are
>> able to try again, please do so.
>>
>> Also, we are continuing to track this issue and add monitoring and
>> instrumentation around this area of the charmstore to be better able to
>> respond to such issues in the future.
>>
>> Thanks,
>> --
>> Jay
>>
>>
>> On Wed, Jun 22, 2016 at 10:30 AM, Stuart Bishop <
>> stuart.bis...@canonical.com> wrote:
>>
>>> On 21 June 2016 at 02:40, Jay Wren  wrote:
>>> > Thanks for the further testing.
>>> >
>>> > Now I'm questioning how in the world I was able to see the same error.
>>> >
>>> > I will continue my testing to attempt to reproduce the error.
>>> >
>>> > Also, the Apache Timeout 300 should behave exactly as Mark said. I'm
>>> still
>>> > trying to find what is causing this failure.
>>>
>>> The error from the bug report originates from Squid, which is probably
>>> buffering the upload. The timeout might happen between Squid and
>>> Apache if it takes to long to upload and there is no keep-alive
>>> mechanism in place.
>>>
>>> --
>>> Stuart Bishop 
>>>
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.0-beta12 ETA

[Tom Barber]

Thanks Cheryl, looking forward to it!

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 6 July 2016 at 20:51, Cheryl Jennings 
wrote:

> Hi Everyone,
>
> Due to the US holidays and with much of the team at core and networking
> sprints, we will be releasing 2.0-beta12 next week.  There are currently 6
> assigned critical bugs [0] that need to be addressed for the next beta.
>
> This next beta is targeted to replace the out of date beta7 current
> uploaded into Xenial. We are moving the date out to allow developers time
> to fix these critical issues and make sure that beta12 is backported into
> Xenial allowing more users to test and beat on Juju 2.0.
>
> Thanks!
> -Cheryl
>
> [0]  https://bugs.launchpad.net/juju-core/+milestone/2.0-beta12
>
> --
> 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: Post resource error

[Tom Barber]

Thanks Cory

after I posted it we picked it up on IRC and got pointed to the same
conclusion so I reverted to serving from my own webserver for now.

Tom
On 6 Jul 2016 18:26, "Cory Johns" <cory.jo...@canonical.com> wrote:

> Tom,
>
> Sorry for delayed response, but that looks like the exact same error that
> Merlijn was getting and opened
> https://bugs.launchpad.net/ubuntu/+source/charm/+bug/1592822 regarding.
> You should add the size and timing info for your case to the bug report as
> well.
>
> I should also note that even if the push tells you that the resource
> exists, `charm show cs:~spicule/wily/dcos-master resources` says it doesn't.
>
> On Mon, Jun 27, 2016 at 5:43 AM, Tom Barber <t...@analytical-labs.com>
> wrote:
>
>> I have no idea what this means and when I try and submit it again it
>> tells me the resource exists but:
>>
>> bugg@tomsdevbox:~/charms/wily/dcos-master$ charm push .
>> cs:~spicule/wily/dcos-master --resource
>> software=~/Projects/dcos-master/bootstrap.tar.gz
>> ERROR cannot post archive: cannot unmarshal error response "> html PUBLIC \"-//W3C//DTD HTML 4.01//EN\" \"
>> http://www.w3.org/TR/html4/strict.dtd\;>\n\n> http-equiv=\"Content-Type\" content=\"text/html;
>> charset=utf-8\">\nERROR: The requested URL could not be
>> retrieved\n<!-- \n Internal Error: Missing
>> Template MGR_INDEX\n\nbody\n:lang(fa) { direction: rtl; font-size: 100%;
>> font-family: Tahoma, Roya, sans-serif; float: right; }\n:lang(he) {
>> direction: rtl; }\n -->\n> id=ERR_ZERO_SIZE_OBJECT>\n\nERROR\nThe
>> requested URL could not be retrieved\n\n\n\n> id=\"content\">\nThe following error was encountered while trying to
>> retrieve the URL: > http://api.jujucharms.com/v5/~spicule/wily/dcos-master/archive?\;>
>> http://api.jujucharms.com/v5/~spicule/wily/dcos-master/archive?\n\n> id=\"error\">\nZero Sized Reply\n\n\nSquid
>> did not receive any data for this request.\n\nYour cache
>> administrator is mailto:webmaster?subject=Ca ... [3524 bytes
>> omitted]": invalid character '<' looking for beginning of value
>>
>> Tom
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
>> goal, but you can always help by sponsoring the project
>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>
>> --
>> 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

Post resource error

[Tom Barber]

I have no idea what this means and when I try and submit it again it tells
me the resource exists but:

bugg@tomsdevbox:~/charms/wily/dcos-master$ charm push .
cs:~spicule/wily/dcos-master --resource
software=~/Projects/dcos-master/bootstrap.tar.gz
ERROR cannot post archive: cannot unmarshal error response "http://www.w3.org/TR/html4/strict.dtd\;>\n\n\nERROR: The requested URL could not be
retrieved\n\n\n\nERROR\nThe
requested URL could not be retrieved\n\n\n\n\nThe following error was encountered while trying to
retrieve the URL: http://api.jujucharms.com/v5/~spicule/wily/dcos-master/archive?\;>
http://api.jujucharms.com/v5/~spicule/wily/dcos-master/archive?\n\n\nZero Sized Reply\n\n\nSquid
did not receive any data for this request.\n\nYour cache
administrator is mailto:webmaster?subject=Ca ... [3524 bytes
omitted]": invalid character '<' looking for beginning of value

Tom
--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm push crashes when uploading big charms

[Tom Barber]

If I had to upload 270mb from my home I'd be waiting 3 weeks. what's
the timeout set to? ;)
On 20 Jun 2016 19:30, "Merlijn Sebrechts" 
wrote:

> Thanks for the explanation, Jay.
>
> I did some further testing. Charm upload fails for a 270MB Charm both from
> my home, my work and our datacenter.
>
>- The datacenter is connected directly to Belnet (upload bandwith
>~300Mbit/s).
>- My upload bandwidth at home is ~ 3 Mbps (speedtest.net) although
>during upload, system monitor shows ~400KiB/s.
>
> This causes me to think there is more at play here then large file + slow
> internet... Let me know if I can help to further debug this problem.
>
>
> As an aside; I don't consider 270MB to be that large. Some examples:
>
>
>- Kubernetes is ~1G
>- Ubuntu docker base image is ~200MB
>
>
> I think this is stuff we should be able to handle...
>
> 2016-06-20 18:41 GMT+02:00 Jay Wren :
>
>> Yes, files are broken up into many TCP packets, and they are all
>> transmitted over a single TCP connection. TCP is a complex protocol which
>> is well documented, so I'll not repeat that here. If you want lots of
>> details, wikipedia is not bad:
>> https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Protocol_operation
>>
>> In the abstract, when you connect to a server using TCP it is identified
>> by a 4-tuple of source address, source port, target ip address, target
>> port. These connections consume server resources and indeed a connection
>> exhaustion is a popular denial of service attack.
>>
>> You are getting a tcp timeout due to of file size because the time it
>> takes to send the entire content is longer than the TCP connection timeout.
>>
>> Yes, the resource upload command to charmstore will also be affected by
>> this. Luckily, resources also have the ability to be uploaded specifically
>> to a model, which might have greater network data rates from the resource
>> uploader.
>>
>> --
>> Jay
>>
>>
>> On Mon, Jun 20, 2016 at 7:04 PM, Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> Thanks for looking into this! I'll try the compression and see if that
>>> works.
>>>
>>> Just curious; why does filesize affect tcp connection timeout? Aren't
>>> the files broken up into a bunch of smaller tcp packets? Filesize should
>>> only affect the number of tcp packets, not the size of the tcp packets? So
>>> getting a tcp timeout because of filesize seems strange to me... Any idea
>>> what exactly goes wrong here?
>>>
>>> Also, now that I think of it, the resource upload command might also be
>>> affected by this, if it uses the same library and similar backend
>>> infrastructure? I'll test this out.
>>>
>>>
>>> Op maandag 20 juni 2016 heeft Jay Wren  het
>>> volgende geschreven:
>>> > Hello Merlijn,
>>> > I can replicate the problem and I can work around it by using a faster
>>> internet connection.
>>> > At some point, tcp connections have to time out. I can only replicate
>>> the issue when that timeout is reached. If you have the means to relocate
>>> to a faster internet connection temporarily for pushing to charmstore,
>>> please do. You might also try recompressing any items in the charm using a
>>> higher compression level. xz -9 instead of gzip -3 or whatever things may
>>> be using now.
>>> > We are aware this is a poor longterm solution. We are investigating
>>> better solutions for uploads. As you've mentioned, resources will also help
>>> the situation.
>>> > I am sorry that I do not have a better solution.
>>> > --
>>> > Jay
>>> > On Fri, Jun 17, 2016 at 4:29 PM, Rick Harding <
>>> rick.hard...@canonical.com> wrote:
>>> >>
>>> >> Merlijn, thanks. I'm going to bet there's an issue with http request
>>> sizes for the charmstore that the charm command talks do as we've got some
>>> layers (Apache, Squid) in front of the actual application. The team is
>>> looking into it. Thanks for giving us the heads up.
>>> >> On Wed, Jun 15, 2016 at 10:28 AM Merlijn Sebrechts <
>>> merlijn.sebrec...@gmail.com> wrote:
>>> >>>
>>> >>> Hi all
>>> >>>
>>> >>> I've hit a roadblock in setting up my CI pipeline. I have a charm
>>> with a Java sdk blob of ~200MB. Pushing this charm to the store causes the
>>> tool to crash. I put a bug report here:
>>> https://bugs.launchpad.net/juju/+bug/1592822
>>> >>> Juju resources would fix my problem, but then I'd need to move to
>>> Juju 2.0 and I'm not ready to do that yet.
>>> >>>
>>> >>>
>>> >>> Kind regards
>>> >>> Merlijn Sebrechts
>>> >>> --
>>> >>> 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:
> 

Re: Question for cosmetic and understandability of breadcrumbs in github

[Tom Barber]

Another thing to bear in mind, as its a pain point at the ASF, git tags
aren't immutable, so you really want to tie you commit to a tag (for ease
of digestion) and a SHA hash for immutability.

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 16 June 2016 at 23:54, Ryan Beisner  wrote:

> Git tagging is certainly helpful to developers, so a big +1 to that for
> git-based projects.
>
> I think there is also a definite need to tie a specific charm store charm
> revision to its exact place and "time" of origin.  Charms which are pushed
> into the charm store (and the deployed charms) are a bit mysterious in
> terms of source code origin and revision level.  The two relevant `charm
> set` tagging mechanisms (homepage and bugs-url) are helpful, and we do
> populate that info.  But to get the granularity of identification for our
> desired level of support, some other "thing" is necessary.
>
> This week, we started injecting repo-info files [1] into OpenStack charms
> [2] just ahead of the push and publish automation in our git/gerrit CI
> pipeline.  The repo-info file will only ever exist in pushed charms, never
> in the charm source code repos.  From the user and support perspective,
> this ensures that the code origin and revision info is in the user's
> possession at all times, and that it flows through and exists on-disk in
> all units in the deployed models.  Many moons later, if a bug is raised or
> a support call comes in, there will be a way to know exactly what charm
> code is in play, down to the repo and commit hash level.
>
> Combining both a git tag breadcrumb and a repo-info breadcrumb would
> really squash the code origin mystery from any vantage point.  I'm not
> certain we can tag commits via the upstream OpenStack cgit:gerrit workflow,
> but we'll look into it.
>
> On another plane:  I've seen some charm metadata buckets which appear to
> accept arbitrary data bits.  It may be useful to also stash repo/commit
> type of info there, but I've not explored that much at all.
>
> [1]
> https://api.jujucharms.com/charmstore/v5/~openstack-charmers-next/xenial/neutron-gateway/archive/repo-info
> [2]
> https://jujucharms.com/u/openstack-charmers-next/neutron-gateway/xenial
>
> Cheers!
>
> Ryan
>
>
> On Thu, Jun 16, 2016 at 4:42 PM, David Britton <
> david.brit...@canonical.com> wrote:
>
>> We are planning a tag for every push for the landscape-server and client
>> charms, and bundles.  +1 on it being mentioned as a best practice (the same
>> type of thing as when you release a version of any other software!).
>> Though, I would recommend using the full charm store identifier eg:
>> 'cs:~user/charm-3'.  Basically, the full standard out of the charm push
>> operation.
>>
>> I also like the repo-info for traceability the other way around.  They
>> solve a similar problem but depending on where you are looking are both
>> useful.
>>
>> On Thu, Jun 16, 2016 at 2:54 PM, Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> Yep, seems like something useful!
>>>
>>> 2016-06-16 22:48 GMT+02:00 Charles Butler 
>>> :
>>>
 I was actually talking to beisner about this in Irc and the open
 stackers are putting a report in their artifacts with the repository
 information.


 https://api.jujucharms.com/charmstore/v5/~openstack-charmers-next/xenial/neutron-gateway/archive/repo-info

 I think I like this better.

 We are generating a manifest of the other layers but I'm not certain we
 are storing any commit hash info in that manifest. I don't think we are.

 But it would give me a nice trail to follow.

 On Thu, Jun 16, 2016 at 4:42 PM Merlijn Sebrechts <
 merlijn.sebrec...@gmail.com> wrote:

> Well, Charles, I must admit that I'm a bit lost. There's some lingo in
> this email I don't quite understand, and it's quite late on my side of the
> globe ;)
>
> What I understand you want: You have a Github repo that contains the
> top layer of a Charm. Each tag in that repo corresponds to the revision of
> the charm build from that layer. Is this correct?
>
> This would allow you to see what Charm corresponds to what layer
> version.
>
> I don't quite understand how this would solve your kubernetes problem.
> Don't you want this information about every layer instead of just the top
> one? Is this something 'charm build' would be able to do automatically? It
> gets the layers from a repo so it might be able to put that info
> (repo/commit) in a log somewhere?
>
> 2016-06-16 19:51 GMT+02:00 Charles Butler <
> 

Re: Is svg.juju.solutions down?

[Tom Barber]

You know what you need... multi cloud controllers! ;)

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 14 June 2016 at 20:33, Marco Ceppi  wrote:

> Hi Merlijn,
>
> Sorry for the outage. Apparently the cloud is an ephemeral world. We
> deploy svg.juju.solutions from the charm store
> https://jujucharms.com/u/marcoceppi/charm-svg/3 but the cloud it was on
> decided to turn off all the instances. I've redeployed it and it's back up
> now.
>
> I'll work on deploying it across a few regions and get a loadbalancer in
> place to prevent this in the future. `juju add-unit` :)
>
> Marco
>
> On Tue, Jun 14, 2016 at 12:15 PM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Is svg.juju.solutions down? The "download svg" part of
>> cloud-weather-report seems to be timing out.
>>
>
> --
> 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 charm/platform support

[Tom Barber]

Another thing:

Puppet make it very easy to find out how to get platform support:
https://puppet.com/support-services, you guys dont.

Plus another thought I had the other day for a feature would be a way in
metadata.yaml or something to toggle a "supported charm" setting.

So, for example I have DC/OS, Saiku etc, and I'd quite like to offer
commercial support for the software even if I don't charge for the software
itself. Now, of course I could add some stuff to Readme.md etc to indicate
I am happy to do consultancy and support around my charms. But it would be
very cool to be able to toggle a setting for a charm, so that the charm
store user can click a button and instantly get in contact with me to
discuss it, rather than having to grep my contact details from a Readme
file.

>From a commercial perspective it would be a good way to open a dialogue
with users and the potential to up sell more services to the users at the
same time.
--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Missing "solutions" on website

[Tom Barber]

Alright folks,

Just one for the marketing people more than anyone else.

I was perusing the PuppetLabs website the other day as they do similar
stuff and I was curious to know how they positioned themselves more than
anything else.

I couldn't help but notice when comparing jujucharms.com and puppet.com
that whilst you guys do a decent job of explaining how the tech works, to
the drive by visitors and people wondering how juju compares to the likes
of puppet and chef etc, you don't have a solutions page, or obvious link
through at the top to juju big data.

I can't help but feel that those people who don't know juju would struggle
to know if it would help solve their problems or not. You know, stuff like,
"I need a way to deploy and maintain my databases", or "I need a sane way
to manage my internal applications", "Can I easily spin up a massive CI
testing cluster?" which puppet seems to answer in seconds by hovering over
their solutions tab.

Anyway, my 2 cents.

Tom
--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Apache Drill Charm

[Tom Barber]

Hi folks:

http://spicule.co.uk/2016/06/02/apache-drill-juju.html

I've not slept enough due to ill kids and travel, so it might be complete
nonsense, but here is a brain dump about some of Drills bits and pieces.

The charm works well enough for basic use and you can certainly connect it
to a bunch of stuff, but I need to add a load more config/relation/action
stuff to solve the automation aspect.

Anyway, fill ya boots.

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart
<http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
goal, but you can always help by sponsoring the project
<http://www.meteorite.bi/products/saiku/sponsorship>)

On 1 June 2016 at 13:47, Merlijn Sebrechts <merlijn.sebrec...@gmail.com>
wrote:

> Yeah, we should see if we can do the same with YARN...
>
> 2016-06-01 14:42 GMT+02:00 Marco Ceppi <marco.ce...@canonical.com>:
>
>> +1 to using % logic to make it scale across any sized instance. Awesome
>> stuff!
>>
>> On Wed, Jun 1, 2016 at 6:28 AM Tom Barber <t...@analytical-labs.com>
>> wrote:
>>
>>> Okay latest "stable" build has RAM config options.
>>>
>>> Drill ships with defaults of 8GB and 3GB but I didn't want it to die on
>>> EC2 Large etc boxes that dont have that much. So I added a bit of logic,
>>> you can (I hope) add XXG and it will use that fixed amount, or you can, as
>>> it ships, tell it you want XX% MAX and XX% Heap and it will try and figure
>>> that out and stand you up a drill box.
>>>
>>>
>>> Tom
>>>
>>> --
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
>>> goal, but you can always help by sponsoring the project
>>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>>
>>> On 1 June 2016 at 00:50, Tom Barber <t...@analytical-labs.com> wrote:
>>>
>>>> Oh, also currently the RAM is clamped down real low
>>>> in /opt/drill/conf/drill-env.sh I will set it back to some sane defaults
>>>> tomorrow as soon as I put the RAM limits into the config options, just ran
>>>> out of time this evening!
>>>>
>>>> --
>>>>
>>>> Director Meteorite.bi - Saiku Analytics Founder
>>>> Tel: +44(0)5603641316
>>>>
>>>> (Thanks to the Saiku community we reached our Kickstart
>>>> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
>>>> goal, but you can always help by sponsoring the project
>>>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>>>
>>>> On 31 May 2016 at 23:50, Tom Barber <t...@analytical-labs.com> wrote:
>>>>
>>>>> Here we are then, for Merlijn and anyone else interested in SQL
>>>>> interfaces to big data/NOSQL stuff.
>>>>>
>>>>> This is less than a days effort, so its patchy at best:
>>>>>
>>>>> https://jujucharms.com/u/spicule/drillbit
>>>>>
>>>>> For those of you who don't know Apache Drill, it will let you run SQL
>>>>> querys over, CSV/JSON data, MongoDB, HBase, Parquet files etc in a number
>>>>> of different locations. Basically its a great way for analysts who use
>>>>> "traditional" SQL tools to leverage data stored within NOSQL solutions.
>>>>>
>>>>> Getting something like this into the CS has been high on my list of
>>>>> priorities for Saiku Analytics as it suddenly offers up loads of new
>>>>> connection prospects(of course I can do this manually in the past, but 
>>>>> this
>>>>> is what Juju is for, right?)
>>>>>
>>>>> You need to deploy a ZK node (or 3) and connect it to that and OpenJDK
>>>>> to run it. Currently its relations-lite, the only one in there is a 
>>>>> MongoDB
>>>>> test relation that will connect Drill to your MongoDB cluster if you run
>>>>> one, but there will be actions and relations coming shortly for other
>>>>> stuff. Also its missing a fat load of config options, again, coming soon.
>>>>> You can set all of this stuff pretty simply though and the

Re: Installing JUJU 2.0 as non-root user

[Tom Barber]

Hi Anita

Make sure you can run lxd images as your user.  When you install lxd you
need to fully logout or su to create a new shell for that user so the lxd
group is picked up.

Tom
On 2 Jun 2016 11:46 a.m., "Anita Nayak1"  wrote:

> Hi All,
>
> We are trying to install JUJU 2.0 by following URL :
> https://jujucharms.com/docs/devel/getting-started
>
> While installing as non-root user, we got permission denied error for the
> following commands:
>
> juju bootstrap lxd-test lxd
> juju list-controllers
>
> charm@c277-pkvm-vm62:~$ juju bootstrap lxd-test lxd
> ERROR invalid config: can't connect to the local LXD server: Permisson
> denied, are you in the lxd group?
>
> Please configure LXD by running:
> $ newgrp lxd
> $ lxd init
>
> charm@c277-pkvm-vm62:~$ newgrp lxd
> Password:
> newgrp: failed to crypt password with previous salt: Invalid argument
>
> The above commands work with "sudo".
>
> However while installing as root user, the above command executions are
> successful.
>
> Can you please confirm that whether JUJU 2.0 can be installed as a root
> user only? If it can be installed as a non-root user, then please let us
> know how to resolve the above mentioned errors.
>
> Thanks & Regards,
> Anita.
>
> --
> 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